Windowsイベントログ監視のnodataによるトリガー復旧条件の動作について
Windowsイベントログ監視にてトリガーの復旧条件にnodataを利用しています。
１つのアイテムに対して、2つのトリガーをログのレベルごとに作成しています。
動作させると2つのトリガーが交互に復旧するというよく解らない動作になり、
解決方法を検討しており、解る方がいらっしゃいましたら、ご教授願えないでしょうか。
＜環境＞
-------------------------------------------------------------------------------------------------------------------------------------
Zabbixサーバ：CentOS 7.4.1708、Zabbix 3.4.8
Zabbixエージェント：Win2016 std、Zabbix 3.4.8(x64 agent)
■アイテム
eventlog[Application,,"Warning|Error|Critical",,,,skip]
■トリガー
＜トリガーA(エラー)＞※エラー用
障害条件式：{Template:eventlog[Application,,"Warning|Error|Critical",,,,skip].logseverity()}=4
復旧条件式：{Template:eventlog[Application,,"Warning|Error|Critical",,,,skip].nodata(120)}=1
深刻度：重度の障害
障害イベント生成モード：複数
正常時のイベントクローズ：すべての障害
＜トリガーB(警告)＞※警告用
障害条件式：{Template:eventlog[Application,,"Warning|Error|Critical",,,,skip].logseverity()}=2
復旧条件式：{Template:eventlog[Application,,"Warning|Error|Critical",,,,skip].nodata(120)}=1
深刻度：警告
障害イベント生成モード：複数
正常時のイベントクローズ：すべての障害
-------------------------------------------------------------------------------------------------------------------------------------
＜解決したいこと＞
動作させると以下の様に2つのトリガーが交互に復旧するというよく解らない動作になります。
期待値としては、両方のトリガーがそれぞれ120秒後に自動で復旧させたいのですが、
回避方法が解る方いますでしょうか。
※もちろん120秒間に障害条件式にマッチするログが無いことは前提です。
１．eventcreateコマンドで警告とエラーのイベントログを出力
２．トリガーA(エラー)、トリガーB(警告)が障害となる
３．2分後にトリガーB(警告)が復旧する
４．トリガーA(エラー)は復旧しない(※10分以上経過しても)
５．もう一度、eventcreateコマンドで警告とエラーのイベントログを出力
６．トリガーA(エラー)、トリガーB(警告)が障害となる
７．2分後にトリガーA(エラー)が復旧する
８．トリガーB(警告)は復旧しない(※10分以上経過しても)
９．さらに、eventcreateコマンドで警告だけ(トリガーB用)イベントログを出力
１０．トリガーB(警告)が障害となる
１１．トリガーB(警告)は復旧しない(※10分以上経過しても)
＜参考にした投稿＞
http://www.zabbix.jp/node/3895
http://www.zabbix.jp/node/3725
karna - 投稿数: 60
自分だったら、アイテムの時点でWarning と Error を分けてしまいますが、そうした場合の挙動はどうでしょうか?
例
アイテムA: eventlog[Application,,Error,,,,skip]
アイテムB: eventlog[Application,,Warning,,,,skip]
tsukune - 投稿数: 6
karnaさん返信ありがとうございます。
アイテムを別けてみました。。。結果、nodataで復旧条件がまったく動かなくなりました。
んー。復旧条件にnodataはまだ使えないのだろうか。
過去の投稿にある様な回避方法を行うことで、復旧する様にはなりましたが、
今度は、1回のイベントログで2回トリガーが動いてしまいます。
({Template:eventlog[System,,"Warning",,,,skip].logseverity()}=2) and ({Template:eventlog[System,,"Warning",,,,skip].nodata(60)}=0)
なんでもいいから自動復旧させるなら、nodataなどは使わない方がいいんですかね。
もう少し何かできないか検証はしてみます。。。
tsukune - 投稿数: 6
自己レス
アイテムの更新間隔が30sにしているのが原因かな。
以下の例の様に、nodeta(60)だと2回トリガーが動くってことですかね。
eventlogにskipを付けてるので、2回目は過去分として無視される認識でしたが、、、、何でだろう
01:00:00 --> アイテム取得
01:00:15 ★エラー発生
01:00:30 --> アイテム取得(logseverity()=2とnodata(60)=0にマッチして障害)
01:00:45
01:01:00 --> アイテム取得(logseverity()=2とnodata(60)=0にマッチして障害？？？)
01:01:15
01:01:30 --> アイテム取得(logseverity()=2にマッチ、nodata(60)=0にアンマッチで復旧)
01:01:45
01:02:00
nodataを復旧条件にする件は、イベントログでなく、テキストのログ監視でも
試しましたがダメですね。
yk_taiko - 投稿数: 184
nodata など時間系のトリガー関数を使うと、
「アイテム取得時」以外に
毎分「0秒」と「30秒」にもトリガー判定するようになりますよ。
- https://www.zabbix.com/documentation/3.4/manual/config/triggers
- https://www.zabbix.com/documentation/2.2/jp/manual/config/triggers (日本語)
karna - 投稿数: 60
nodataを使用すると、アイテムの更新間隔に関係なく、30秒ごとにトリガーが判定されます。
そのため、イベントを継続して生成させると、30秒ごとに障害が発生します。
あと、nodataによる判定感覚ですが、「アイテム取得時」と、「（最後に取得した時から）30秒ごと」となります。
今回の例ですと、毎分0秒、30秒ですが、何かのタイミングでアイテム取得が1秒遅れたとすると、
毎分1秒、31秒の判定になります。
以前は、ログ監視＋イベントの継続生成＋復旧判定 の組み合わせは、相性が悪く、一筋縄ではいきませんでしたが、
Ver.3.4のようですので、復旧条件式を使用された方がよいかもしれません。