ログ監視のトリガーでnodataを使用したところ、大量に障害検知してしまった
[環境]
zabbixバージョン : 3.0.5
OS : Linux(CentOS)?
[設定]
条件式(修正前):{Tmp :logrt[C:\Logs\,"\[ER\]"].iregexp(ER)}>0
(ログに「ER」という文字が含まれていたら障害検知)
障害イベントを継続して生成:オン
(同じ障害が複数回発生した場合に障害管理として分けたいため)
有効:オン
当初はこのようにログ監視を設定していたのですが、以下のような指摘を受けました。
「指摘」
この条件式では、「トリガ条件に合致していない場合、正常状態」という状態を作れずに、アラーム状態が
継続してしまう。ダッシュボードの「最新20件の障害」に残り続けてしまう。
なので「直近にデータがある場合」をand条件として、トリガ条件に追加してほしい。
この指摘に対応するため、条件式を下記のように変更しました。
条件式(修正後):{Tmp :logrt[C:\Logs\,"\[ER\]"].nodata(1d)}=0
and {Tmp :logrt[C:\Logs\,"\[ER\]"].iregexp(ER)}>0
1日間はアラーム状態として継続させたいが、1日ログが出てない状態になったら正常に戻したいという意味です。
しかしこの設定をしたところ、実際にログが発生したら、30秒ごとに評価されてしまうというnodataの仕様のためか、
30秒ごとに障害検知されてしまったようです。
やはり、「障害イベントを継続して生成」をオフにすることでしょうか?
それだと本当に複数回障害が起きたときに、同一の障害として見做してしまう恐れがあるとかで指摘が入った記憶があります。
両立できないんでしょうか?
よろしくお願いします。
hyde4272 - 投稿数: 48
補足:実際に起きたログ事象は、1回のみでした。
hyde4272 - 投稿数: 48
連投で申し訳ございませんがとりあえず「障害イベントを継続して生成」をオフにしました。
他に良い方法があればご教授願えないでしょうか。
よろしくお願いします。
kaeru - 投稿数: 264
>hyde4272様
ご認識の通り、現行ではあまり良いパターンは無いかと思います。
対応としては2点考えられます。
①nodataは使用せず、ダッシュボードの「最新20件の障害」に関しては
都度、"障害対応コメント"を入力し表示させないようにする。
(トリガーとしては障害のままとなります)
②nodataを使用するのであれば、
"複数回の障害"として表現されているメッセージの絞り込みを行い、
それぞれに対応するトリガーを各個作成する。
(同一のエラーは30秒間に連続発報されても1通送付、
違うエラーはそれぞれ発報されるように設定する)
それぞれ、障害検知時の運用に合わせて検討する形が良いと思います。
発報メールにて逐次状況を確認したいのであれば①、
そんなに障害が発生せず、発生したら実際のログを見れば良いぐらいであれば②等々で私も設定しています。
補足ですが、Zabbix3.2.0より 手動でトリガーを戻せるようになる機能が付くそうです。
http://www.zabbix.com/jp/rn3.2.0
hyde4272 - 投稿数: 48
カエル様
開発者の作ったログの場合、メッセージで区別できないようで・・。
指摘がくるまでは継続生成しない設定でやり過ごします。
最新版へのアップデートを提案するのも良いかもしれません・・。
ありがとうございました。
karna - 投稿数: 61
nodata と障害の継続生成の相性は悪いですからねぇ…
アップデートも難しく、障害の通知を重視するのであれば、
障害を継続して生成させ、nodataは外して、復旧時にログを吐き出させる、
あるいは、復旧作業時/確認時に手動(スクリプト等)でログに書き込む
など、運用上カバーすることも検討できないでしょうか?
heya - 投稿数: 319
運用でカバーと言えば、私の周辺のいくつかの案件では、
>この条件式では、「トリガ条件に合致していない場合、正常状態」という状態を作れずに、アラーム状態が
>継続してしまう。ダッシュボードの「最新20件の障害」に残り続けてしまう。
こういう仕様だと言い張って、「ログに関しては障害として残り続けても気にしない」という運用になっています。
あと、ご存知かもしれませんが、3.2.x に上げるなら、半年でサポート終了なので、またすぐにバージョンアップが必要になるということも頭の隅に入れておいてください。
http://www.zabbix.com/jp/life_cycle_and_release_policy