ログ監視における通知の重複について
Zabbix3.4を利用し、ログ監視を行っております。
ログにエラーメッセージが出力された場合、全てメールで通知するようにしたいと考えております。
トリガーの設定は以下の通りです。
条件式:{server01:log[/var/log/somelog].regexp(@error)}=1 and {server01:log[/var/log/somelog].nodata(30)}=0
正常イベントの生成:条件式
障害イベント生成モード:複数
正常時のイベントクローズ:全ての障害
上記の設定でエラーメッセージが出力され、その後ログへの書き込みがない場合、同様のメール通知が2通届きます。
何方かおわかりでしたらその理由を教えていただけますでしょうか。
※アイテムの更新間隔(現在60sにしております)に依存しているのではないかと思っておりましたが、ログの2通目のメールが届くのはいつも10秒後ぐらいです。
よろしくお願いいたします。
TNK - 投稿数: 4755
アイテムのタイムスタンプと通知されるタイミングのタイムスタン
プを比較してみてください。
恐らく、nodata()を使用しているのが原因だと思います。
sh_sh - 投稿数: 5
TNK さん
ご返信をありがとうございます。
アイテムのタイムスタンプを確認する場所がわかりませんでしたが、ログを確認した結果を記載いたします。
Zabbixサーバログの出力レベルを4にし、監視対象サーバのログに1つのエラーメッセージを出力し、Zabbixサーバログの内容が以下の通りです。
※ログ中の「In evaluate_function」でトリガーの条件式に一致しているかのチェックが始まっていると認識しましたが、合っていますでしょうか。理解不足で申し訳ございません。
・Zabbixサーバでagentからログのエラーメッセージを受け取り(17:38:25)、その後すぐにチェックが始まり、1つ目の通知が発報されました。
・その後、17:38:30にチェックが開始され、2つ目の通知が発報されています。
・次のチェックが17:39:00に始まり、通知が発報されませんでした。
上記から、agentから何らかの値を受信すると正常性のチェックが走り、その後定期的なチェックが実行されるため、障害イベント生成モードを「複数」にすると通知が重複してしまうという理解でよろしいでしょうか。
Yasumi - 投稿数: 380
これはnodataが原因ですね。nodataを使用する理由にもよりますが、
障害イベント生成モードを「複数」ではなく「単一」にするのが良いと思います。
ただし「単一」にした場合、アイテムとnodataの設定をしっかり考慮していないと
ログが継続出力された場合にトリガーがnodataによって復旧せず、
障害の継続に気づけないケースがあるのでご注意を。
TNK - 投稿数: 4755
「単一」にした場合、sh_shさんの「ログにエラーメッセージが出
力された場合、全てメールで通知するようにしたい」という目的が
満たせなくなると思います。
Yasumi - 投稿数: 380
本当ですね。指摘の通りです。
検知したエラーログを全てメール通知する場合は「複数」です。
sh_sh - 投稿数: 5
Yasumi さん
ご返信をありがとうございます。
nodata()を使用する理由は以下の通りです。
@errorと一致する文字列が出力されればを通知する設定にしておりますが、@errorと一致する文字列を含むメッセージの内容が異なっております。連続でエラーメッセージが出力されてもなるべく漏れなくアラートが発報されるために障害イベント生成モードを「複数」にし、ログにメッセージが出力されなければ通知を止めるようにnodata()を使用しております。
メッセージ内容ごとにトリガーを分け、[単一]にすれば要件を満たすことができることは理解しておりますが、メッセージ内容が結構異なっており、対応が難しいです。。
Yasumi - 投稿数: 380
なるほど。だいたい認識しました。
私の経験したことのある環境では、nodata()を10分以上と広く範囲を取り、「復旧するまでに出力されたログを手動で報告する」ところもありました。ここは現場ごとの運用の性格の違いが出るところなので、どこでも適用できないとは思いますが、参考程度に。
> ・Zabbixサーバでagentからログのエラーメッセージを受け取り(17:38:25)、その後すぐにチェックが始まり、1つ目の通知が発報されました。
> ・その後、17:38:30にチェックが開始され、2つ目の通知が発報されています。
なお股書きになりますが、noataが毎分の0秒と30秒に判定があったため、「17:38:30にチェックが開始され、2つ目の通知が発報」したのかと思われます。
sh_sh - 投稿数: 5
Yasumi さん
こういった対応方法もあるんですね。ご共有をありがとうございます。
> なお股書きになりますが、noataが毎分の0秒と30秒に判定があったため、「17:38:30にチェックが開始され、2つ目の通知が発報」したのかと思われます。
そういうことですね。理解いたしました。
sh_sh - 投稿数: 5
スレッド違いでした。