同じアクションが繰り返される場合、エスカレーションされない場合がある
【環境】CentOS6.6
zabbix 2.4.3
今回、１分間に２０回程度、同じアクションが起動されたのですが、アクションのエスカレーション機能で、２つ目
のステップに進む場合と、進まない場合が発生しております。
アクションの設定および、エスカレーション（ステップ）の設定条件は下の【アクションの設定概要】の通りです。
次のステップが開始される前に、同じアクション（別のイベントID）が実行される場合、前のアクションの次のステップ
は実行されずに、次のアクションの実行で上書きされ、停止されてしまう場合があるのでしょうか？
※以下の画像を添付しますのでよろしくお願い致します。
「event.png」イベント履歴画面
⇒「コメントあり」の欄で「いいえ」となっているイベントが次のステップに進むべきところ進まずに終わっているものです
「action.png」アクションの設定画面
⇒２ステップ目の内容を表示させております他ステップもユーザ以外は同じ設定です
【アクションの設定概要】
特定のサーバ名がエラーログに存在する場合、アクションにて、そのサーバ担当者にエラーを通知するスクリプトを
実行する設定にしています。
（アクションはサーバ名ごとに作成しており、同じサーバでエラーが発生した場合は同じアクションが実行されます）
また、このアクションのエスカレーション機能を使って、300秒間隔でステップを定義し、それぞれのステップで同じ
通知スクリプトを起動し別担当者へエラー通知を行う設定を行っております。
しかし、障害対応コメントが入力されると次のステップへは進まないように
アクションの実行条件に「障害対応＝コメントなし」
を設定しております。
■Zabbixのドキュメントで以下の記述がありますが、これが上書きしていると言う内容で解釈していいものか分かりませんでした。
URL⇒https://www.zabbix.com/documentation/2.0/jp/manual/config/notifications/action/escalations
【Zabbixドキュメント抜粋】
＞＞異なるエスカレーションが近い期間で連続していたりオーバーラップしている場合は、それぞれの新しいエスカレーションが
＞＞前のエスカレーションにとってかわって実行されますが、最新のエスカレーションのステップは常に前のエスカレーション上
＞＞で実行されます。トリガーの障害の評価「毎に」生成されるイベントで実行されるアクションでは、このふるまいは妥当です。
以上、よろしくお願い致します。
- event.png (419.07 KB)
- action.png (309.34 KB)
TNK - 投稿数: 4671
どのようにしてアクションが実行されていないと確認されましたか？
アクションに登録したメディア等で送付された結果のみを確認され
たのであれば、ZabbixのWebインターフェース上のイベントの詳細
も確認してみてください。
アクションから各ステップでのメディアの呼び出しが実行されてい
たりしませんか？
利用されているのが、貼られた画像から勝手に予想させていただく
とTwilioなどを利用されているのではないでしょうか？
その場合、そのTwilioの呼び出しのスクリプトそれぞれがちゃんと
実行されているかを確認してみてください。
短時間に複数回呼び出せないような制限があったりしませんか？
misaki - 投稿数: 69
TNKさん
ありがとうございます。
＞どのようにしてアクションが実行されていないと確認されましたか？
イベントの詳細でステップ１のみ実行されていることを確認しました。
ステップ２の実行は記載されていませんでした。
＞アクションから各ステップでのメディアの呼び出しが実行されてい
＞たりしませんか？
上の通り、ステップ自体実行されていませんでしたので、スクリプトの
呼び出し自体ありませんでした。
ご想像の通りTwilioをスクリプトでコールしています。
以上のことから、ステップ２が実行されるまでの時間に、同じトリガが起動
されたことで同じトリガで起動したアクションが前回のアクションを上書き
して以降のステップが取り消されたのかと想像しています。
お忙しいところ申し訳ございませんが、ここのところの動作がどうなるのか
原因を知りたいと思いますのでお知恵をお貸しください。
よろしくお願い致します。
TNK - 投稿数: 4671
同様のエスカレーションされるような設定を同じような間隔となる
よう設定してみましたが、そのような現象は確認できませんでした。
Zabbixサーバのログに何か出力されていませんか？
misaki - 投稿数: 69
TNKさん
お忙しいところありがとうございます。
サーバーが客先にあるためにサーバーのログは確認できておりませんので、可能で
あれば確認してみたいと思います。
以下、２点確認させてください。
（１）TNKさんの同様の設定では、１分間に複数の同じトリガーにてアクションが
複数同時に実行されてもすべてエスカレーションが最後まで実行されたので
しょうか？
当方の今回の事象では、エスカレーションする場合としない場合と入り乱れて
おりましたので、必ずエスカレーションしない状況ではありませんでした。
（２）Zabbixドキュメントに記載のある以下の内容について、新しいエスカレーション
が前のエスカレーションにとってかわって実行されますとの記載は今回の現象と
は無関係な事象の説明になるのでしょうか？
【Zabbixドキュメント抜粋】URL⇒https://www.zabbix.com/documentation/2.0/jp/manual/config/notifications/action/escalations
＞＞異なるエスカレーションが近い期間で連続していたりオーバーラップしている場合は、それぞれの新しいエスカレーションが
＞＞前のエスカレーションにとってかわって実行されますが、最新のエスカレーションのステップは常に前のエスカレーション上
＞＞で実行されます。トリガーの障害の評価「毎に」生成されるイベントで実行されるアクションでは、このふるまいは妥当です。
TNK - 投稿数: 4671
処理されました。
これは、同じイベント処理内での話です。
別のトリガーで発生したイベントは、別のイベントとして処理が行
われるので、他のイベント処理には影響を与えないはずです。
なので、何らかの要因で特定のイベント処理に問題が発生した可能
性を予想してログを確認して欲しいと書かせて頂きました。
misaki - 投稿数: 69
TNKさん
ありがとうございます。
サーバーのログをまずは確認してみます。
misaki - 投稿数: 69
「zabbix_server.log」を確認しましたが、この症状が出ているアクションが実行されている時間帯には何もログが
出ていませんでした。
ちなみに「DebugLevel=3」です。
＝＝以下がその対象時間帯のログです＝＝
2360:20150810:203603.942 executing housekeeper
2360:20150810:203604.548 housekeeper [deleted 261 hist/trends, 0 items, 0 events, 0 sessions, 0 alarms, 0 audit items in 0.605386 sec, idle 1 hour(s)]
2360:20150810:213604.849 executing housekeeper
2360:20150810:213605.400 housekeeper [deleted 260 hist/trends, 0 items, 0 events, 0 sessions, 0 alarms, 0 audit items in 0.550078 sec, idle 1 hour(s)]
2360:20150810:223605.700 executing housekeeper
2360:20150810:223606.133 housekeeper [deleted 260 hist/trends, 0 items, 0 events, 0 sessions, 0 alarms, 0 audit items in 0.432417 sec, idle 1 hour(s)]
2360:20150810:233606.432 executing housekeeper
2360:20150810:233606.833 housekeeper [deleted 261 hist/trends, 0 items, 0 events, 0 sessions, 0 alarms, 0 audit items in 0.400618 sec, idle 1 hour(s)]
TNK - 投稿数: 4671
特にログにエラーが出力されていないのであれば、SQL実行関連で
エラーが発生していたわけではなさそうですね。
特にエラーが発生していないのであれば、Zabbix自体の問題もある
かもしれません。
2.4.3と古いバージョンを利用されているようですので、2.4.6への
バージョンアップで改善するかもしれません。
ちなみに、Twilioの通知用スクリプトの実行はどのくらいの時間が
かかるのかお教え頂けませんか？
特に普段実行していて最長何秒程度かかる場合があるのかが気
になっています。
misaki - 投稿数: 69
TNKさん
バージョンアップも含めて検討したいと思いますが、まず応急処置として以下のようなnodataを使って、
障害状態を一定時間（エスカレーションが最後まで実行される時間）保持するようにできないか検討中です。
以下のようなトリガーの設定で考え方は合ってますでしょうか？
現在は、指定している文字列以外をトラッパーで受けると障害状態が正常状態に戻ってしまう（戻したくない
けど戻ってしまう）ので、他の文字列を受けてもnodataで指定した期間障害状態を維持し、その間にエスカレ
ーションを最後まで実行させたい。
※質問に貼り付けたevent.pngを見て頂くと分かりますが、次の同じイベントが発生したとき障害の継続時間が
ほとんど”０”で終わっていますので、これを継続させたいと考えました。
ちょっと質問内容が別スレッドを立てるべき内容になってくるかもしれませんがよろしくお願いします。
（要件１）現在のトリガは、トラッパーで受けた文字列に特定の文字列があった場合、障害発生とみなしアク
ションの実行がされるようにしています。
（要件２）エスカレーションを５分間隔で４回繰り返す場合、最後の４ステップ目が１５分後となりますので、
２０分間障害状態を維持したいと考えます。
＜現在のトリガー設定＞
{サーバ名:xxx.trapper.iregexp(mojiretu)}=1
＜新たな対策版トリガー設定＞
({サーバ名::xxx.trapper.nodata(1200)}=0)&({サーバ名:xxx.trapper.iregexp(mojiretu)}=1)
misaki - 投稿数: 69
TNKさん
nodateを使ってみましたが、期待する動作を得ることが出来ませんでした。
また、テスト環境にて、前のトリガーのステップ継続中に、同じトリガーにヒットするイベントを
発生させたところ、やはり前のイベントの「障害中」の継続時間が終了し、実行されていたそれ以降
のステップは実行されず終了してしまいます。
バージョンの問題か確認するために、2.4.6へのバージョンアップを検討いたします。