いつもお世話になっております。
http://www.zabbix.jp/node/2692 上記に近いと思いますが、もっとスマートなやり方があればご教授お願いできればと思います。
やりたいことは1つのzabbixで複数のサービスを監視しております。 そのサービスごとにアラートメールの送信先を別々にできるでしょうか?という質問になります。
トリガーが発生してアクションを実行する際、送信先としては、 障害が発生したホストに対するアクセス権限(読み込み、読み書 き)が必要ですので、トリガーが発生しても権限のないユーザに は送られません。
これを利用して、送信先別のアクションを作成しておけば、トリ ガーが発生しても、関係のないホストに関する情報は送らないこ とができます。
つまり、ホストまたはホストグループに対するアクセス権限をき ちんと設定していれば、アクセス可能なホストのみに対するメー ル通知などを実現することができます。
ただし、機能的に実現できたとしても、どのアクションがどのホ ストグループに対するものであるかがアクションを見ただけでは わかりませんので、管理性が低下してしまうことが懸念されます。
なるほどです。ありがとうございます。
ホストグループに対する権限での動作を確認してみます。
管理性という意味では、私の質問の内容に貼ったURLのように、 トリガの命名規則で管理させてもいいかなと感じました。
以前、トリガーで切り分けと書いていましたが、改めて考えてみる と、複数のサービスとはいえ、同じような監視を行うのであれば、 共通の監視テンプレートを作成することも多いかと思います。
そうすると、共通の監視テンプレート内のトリガー名を、サービス ごとにカスタマイズすることができないので、トリガー名で切り分 けや振り分けは適していないかもしれません。
先ほど、アクションの管理性の話を書かせて頂きましたが、アクシ ョンの名称の命名規則を定めたり、アクセス権限が正しく設定され ていれば必要はありませんが、アクションの条件にサービスごとの ホストグループであることを付加しておくと、各アクションがどの サービス用のものであるかを判別しやすいのではないかと思います。
そうですね。まさに仰る通りで共通するテンプレートが多くあります。 統合の意味だとそこが大きいメリットでもありますので。
権限を分ける形で検証進めてみます。
グループごとにAdminユーザーと一般ユーザーを作り、 全グループに所属する特権Adminユーザーを作ることにしました。
アラートのメールはグループAのものはグループAのAdminに飛んできます。 グループBはグループBのAdminに飛んできます。 特権Adminユーザーは全てのグループのアラートが飛んでくる状態としました。 なので特権Adminの送信先MLはプラットフォームインフラ管理者 グループごとのAdminの送信先MLはそのグループの管理者を入れることとしました。
想定したようにアラートは飛んでおり、マルチテナントプラットフォームのようになってきました。
あとはグループ共通のテンプレート(例えばLinux_OSのようなLinuxで共通した監視項目用のテンプレート)がどこのグループでも編集できてしまうのですが、 これは仕方ないでしょうか? できればカスタマイズしてほしくないテンプレートを読み込み権限のみにするなどができればいいのですが。
アカウント名 maco
本名 上原 誠
ホームページ http://ameblo.jp/pioho07/
Facebook http://www.facebook.com/home.php#!/makoto.uehara.39
Zabbix関連
TNK - 投稿数: 4769
トリガーが発生してアクションを実行する際、送信先としては、
障害が発生したホストに対するアクセス権限(読み込み、読み書
き)が必要ですので、トリガーが発生しても権限のないユーザに
は送られません。
これを利用して、送信先別のアクションを作成しておけば、トリ
ガーが発生しても、関係のないホストに関する情報は送らないこ
とができます。
つまり、ホストまたはホストグループに対するアクセス権限をき
ちんと設定していれば、アクセス可能なホストのみに対するメー
ル通知などを実現することができます。
ただし、機能的に実現できたとしても、どのアクションがどのホ
ストグループに対するものであるかがアクションを見ただけでは
わかりませんので、管理性が低下してしまうことが懸念されます。
maco - 投稿数: 32
なるほどです。ありがとうございます。
ホストグループに対する権限での動作を確認してみます。
管理性という意味では、私の質問の内容に貼ったURLのように、
トリガの命名規則で管理させてもいいかなと感じました。
TNK - 投稿数: 4769
以前、トリガーで切り分けと書いていましたが、改めて考えてみる
と、複数のサービスとはいえ、同じような監視を行うのであれば、
共通の監視テンプレートを作成することも多いかと思います。
そうすると、共通の監視テンプレート内のトリガー名を、サービス
ごとにカスタマイズすることができないので、トリガー名で切り分
けや振り分けは適していないかもしれません。
先ほど、アクションの管理性の話を書かせて頂きましたが、アクシ
ョンの名称の命名規則を定めたり、アクセス権限が正しく設定され
ていれば必要はありませんが、アクションの条件にサービスごとの
ホストグループであることを付加しておくと、各アクションがどの
サービス用のものであるかを判別しやすいのではないかと思います。
maco - 投稿数: 32
そうですね。まさに仰る通りで共通するテンプレートが多くあります。
統合の意味だとそこが大きいメリットでもありますので。
権限を分ける形で検証進めてみます。
maco - 投稿数: 32
グループごとにAdminユーザーと一般ユーザーを作り、
全グループに所属する特権Adminユーザーを作ることにしました。
アラートのメールはグループAのものはグループAのAdminに飛んできます。
グループBはグループBのAdminに飛んできます。
特権Adminユーザーは全てのグループのアラートが飛んでくる状態としました。
なので特権Adminの送信先MLはプラットフォームインフラ管理者
グループごとのAdminの送信先MLはそのグループの管理者を入れることとしました。
想定したようにアラートは飛んでおり、マルチテナントプラットフォームのようになってきました。
あとはグループ共通のテンプレート(例えばLinux_OSのようなLinuxで共通した監視項目用のテンプレート)がどこのグループでも編集できてしまうのですが、
これは仕方ないでしょうか?
できればカスタマイズしてほしくないテンプレートを読み込み権限のみにするなどができればいいのですが。