こんなトリガー
があるとして、
mongodを落としてみる
# /etc/init.d/mongod stop Stopping mongod: [ OK ]
当然障害になる
通常は、アラートをメールで受け取るなりしてmongodを起動して復旧。なんですが(まあなんで落ちたのかは別途調査するとして・・・)
自動再起動アクションを設定
トリガーに対応したリモートコマンドを設定しておくと、障害時に特定のコマンドを発行することが出来ます。
ちなみに、リモートコマンドが実行できるようにzabbix-agentを設定していることが前提です。
また、zabbixユーザーでzabbix-agentを起動しているときは、sudoをパスワード無しで実行できる権限がzabbixユーザーに必要になりますね。
zabbix_agentd.confに
EnableRemoteCommands=1 AllowRoot=1
などとしてあれば問題なく実行できると思います。余程の事情がない限り、できればzabbixユーザーでagentを起動してくほうが安全かとは思いますが・・まあケースバイケースで。
アクションを設定してみる
[設定] - [アクション]メニューから
アクションの作成(イベントソース:トリガー)を押す。
アクションの実行条件に、トリガーを登録
アクションの実行内容に、ターゲットホスト(ホストグループも設定可能)と実行したいリモートコマンドを設定。
メールも送る
アクションは複数登録できるので、リモートコマンドを実行したあと、担当者にメールする設定も入れました。
mongodを落としてみる
トリガーが発生しました。
リモートコマンドが走って、メールが送信されました。
より実戦的に
アクションを設定したからといって完全に安心は出来ないので、実戦上はトリガーの実行条件を
・トリガーの値 = "障害" を条件に加え ・リカバリメッセージにチェックを行う
上記を行っておくことで、次回のアクションで障害から復帰した場合、リカバリメールが来るようになるので設定しておくといいですね。
アクション タブ
アクションの実行条件
こんなかんじにしておくと
再度mongodを落とす
# /etc/init.d/mongod stop
障害発生。
障害メールが来て、すぐに復帰メールが来た。
イベントログを見てみると
障害発生でメール送信とリモートコマンドの実行を行ったログと
次のチェック(今回の場合は30秒後)で復旧を確認してメール送信
ここまで自動で行われていることがわかります。
対応方法が決まっているトリガーについては強力な機能
通常のZabbix運用で一番多いのは、一定以上のレベルの障害発生時(例えば「重度の障害」以上とか)でメールを送信する、または障害レベルによってメールの宛先を変えるなどの運用だと思います。
この運用に加えて、今回のようにデーモンの存在チェックを行って、トリガーが発生したら自動的に再起動するなどの細かなアクションを別途登録していくことによってかなりの対応労力を軽減できると思います。
既に通知とリカバリを設定して運用中の場合
なお、今回は説明の都合で
・トリガー発生でメール通知 ・リモートコマンドの実行 ・リカバリメールの送信
までを一つのアクションで行いましたが、既に一定以上のレベルのトリガーによるメールの送信と再チェック時のリカバリメール送信を既に行っている場合は、単純に特定のトリガーをターゲットにしたリモートコマンドの登録だけを行えば、障害通知とリカバリ通知は既存の仕組みがカバーするのでリモートコマンドの実行許可さえ入れればすぐに実戦投入できますね。

改訂版 Zabbix統合監視実践入門 ~障害通知、傾向分析、可視化による省力運用 (Software Design plus)
- 作者: 寺島広大
- 出版社/メーカー: 技術評論社
- 発売日: 2014/06/17
- メディア: 大型本
- この商品を含むブログ (1件) を見る

Zabbix統合監視徹底活用 ~複雑化・大規模化するインフラの一元管理 (Software Design plus)
- 作者: TIS株式会社,池田大輔
- 出版社/メーカー: 技術評論社
- 発売日: 2014/02/07
- メディア: 大型本
- この商品を含むブログ (4件) を見る

Zabbix統合監視「実践」入門 ~障害通知、傾向分析、可視化による省力運用 (Software Design plusシリーズ)
- 作者: 寺島広大
- 出版社/メーカー: 技術評論社
- 発売日: 2010/04/08
- メディア: 大型本
- 購入: 1人 クリック: 76回
- この商品を含むブログ (14件) を見る