エスカレーションを有効にした場合の挙動に関して
はじめまして。よろしくお願い申し上げます。
現在、下記の設定でアラートメールを飛ばす設定にしております。
・｢アクションの設定｣で｢エスカレーションを有効｣に設定。(｢期間｣は｢3600｣を設定)
・｢アクションのコンディション｣で｢トリガーの深刻度 >= "重度の障害"｣に設定
・｢アクションのオペレーション｣で｢ステップ｣を｢開始:1｣｢終了:0｣｢期間:0｣に設定。
この設定で、｢重度の障害｣が発生した場合、アラートメールが送信され、障害が改善されない限りは3600秒ごとにアラートメールが繰り返し送信されるようになりました。
また、障害が復旧すれば、｢OK｣のメールが一通だけ送信されます。
しかし、デフォルトで含まれている｢Template_Linux｣というテンプレートの｢Server {HOSTNAME} is unreachable｣というトリガーに関してのみ、障害復旧メールが｢一通だけ｣ではなく、エスカレーションで設定した3600秒ごとに延々と送信され続けるという現象が発生しております。(他のトリガーに関してはこういった現象は発生しておりません)
メールの内容は下記になります。
Server (ホスト名) is unreachable: OK
Last value: Up (0)
※(ホスト名)の部分は実際のホスト名が入ります。
｢Template_Linux｣というテンプレートの｢Server {HOSTNAME} is unreachable｣というトリガーの条件式は下記になります。
{Template_Linux:status.last(0)}=2
同様な現象に関して心当たりのある方がいらっしゃいましたら、
お力添え頂けますと幸いです。よろしくお願い申し上げます。
kodai - 投稿数: 1341
実際にstatusアイテムとエスカレーションを組み合わせて使ったことはないのですが、statusのキーは他のものと違って特殊な動きをします。
具体的には、statusキーはエージェントと通信を行っているわけではなく、Zabbixサーバの内部で計算した結果(他のアイテムが通信できているかどうか)を返すようになっています。
おそらくはそのためにエスカレーションにもあまり適さない動作をしているのだと思います。
statusキー自体は今後廃止される方向で検討されていますし、動きも分かりにくいので、agent.pingやicmppingを使われる方が確実だと思います。
poly_soft - 投稿数: 3
kodai様
ご返信ありがとうございました。ご提案頂いた｢agent.ping｣を使用する方式に変更して対応してみたいと思います。
poly_soft - 投稿数: 3
解決しました。原因としてはどうやら｢アクションのコンディション｣の設定に問題があったようです。
アクションのコンディションに関しては｢トリガーの深刻度 >= "重度の障害"｣しか指定していなかったのですが、AND条件で｢トリガーの値 = "障害"｣を指定する必要があったようです。
# ちなみに｢Server {HOSTNAME} is unreachable｣というトリガーでしか
# 問題が発生していないと記載していましたが、
# 他のトリガーでも問題が発生していました。失礼いたしました。
ということで｢エスカレーションを有効｣に設定する場合、
｢トリガーの値 = "障害"｣をコンディションに(AND条件で)追加しないと、
ステータスが｢OK｣のメールも延々と送信され続けてしまう、
ということになるようです。
以上です。