ログ監視アラートが大量に送信される
こんにちは。
私の環境で現在下記のような状態になっています。
これを下記の理想の状態にしたいと思っています。
どうかお知恵を拝借させていただけないでしょうか。
【現在の状態】
1つのトリガーから」1秒間に2通くらいの頻度で大量にログ監視のアラートメールが送信される
※新規メッセージがある場合のみ
【理想の状態】
「トリガー判定の間隔（300秒）」でトリガーに引っ掛かった場合、「1通のみ」メールが送信される
【環境】
OS : RHEL系
kernel_version : 2.4.21-58
zabbix_server : 1.8.4
zabbix_agentd : 1.8.4
【現在の設定】
--Item--
Type ： Zabbix agent (active)
Key ： log[/var/log/messages]
Update interval : 300
※/var/log/messagesは1週間でログローテートする設定です
--Trigger--
Expression :
({Host001:log[/var/log/messages].nodata(300)}=0)&({Host001:log[/var/log/messages].count(300)}>0)&({Host001:log[/var/log/messages].iregexp(alert,300)}=1)
Event generation : Normal
Severity : Warning
※iregexpの第一引数を変えて同様の設定で「error」「warn」なども設定しています
--Action--
Event source : Triggers
Enable escalations : チェックなし
Recovery message : チェックなし
Type of calcuratin : AND/OR
Conditions :
Trigger severity = Warning
Trigger value = PROBREM
現在のトリガー設定は以下のような動きをする認識です。
------------
300秒の間に「1行以上メッセージ出力があり」かつ「iregexpの第一引数の文字列を含む」場合、トリガーステータスをPROBREMにする。300秒の間「メッセージ出力がない」場合、トリガーステータスをOKに戻す。
------------
以上、よろしくお願い致します。
TNK - 投稿数: 4769
条件式の
<code>
({Host001:log[/var/log/messages].count(300)}>0)
</code>
は不要ではないでしょうか。
取り除いても、log[/var/log/messages]でログが出力されたことを
検知してトリガーの処理は行われると思います。
deepriver - 投稿数: 7
お返事ありがとうございます。
仰る通り、不要のようですね。
ただ、こちらの条件式とアラートが大量に送信される事象とは直接関連がないと考えているのですが、いかがでしょうか。
以上、よろしくお願い致します。
TNK - 投稿数: 4769
関係ないかもしれませんが、少しでも影響がある可能性を排除した
方が、根本的な問題にスムーズにたどり着ける可能性があるため、
先の情報を提示させて頂きました。
というのも、条件式で利用する関数によっては、評価タイミングが
アイテムのチェック間隔とは別のタイミングで評価されるものがあ
るため、それによってより頻度の多いトリガー発生になる場合があ
るからです。
ちなみに、私の環境では以下のような設定で同等の監視を実現でき
ています。
・アイテム
タイプ： Zabbixエージェント(アクティブ)
キー ： logrt[/var/log/messages*]
データ型： ログ
更新間隔(秒)： 30
・トリガー
条件式：(見やすくするため改行入れています)
({ホスト名:logrt[/var/log/messages*].nodata(300)}=0)&
({ホスト名:logrt[/var/log/messages*].str(ALERT)}=1)
イベント生成： ノーマル
深刻度 ： 軽度の障害
・アクション
イベントソース： トリガー
エスカレーション、リカバリはOff
アクションのコンディション：
計算のタイプ AND/OR (A) and (B)
コンディション
(A) トリガーの値 = "障害"
(B) メンテナンスの状態 期間外 "メンテナンス"
厳密には同じではありませんが、この設定で1秒間に2通メールがく
るようなことは発生していません。
あと考えられるとしたら、もしかしたら、複数のアクションを登録
されていて、想定されているアクションとは別のアクションも動い
てしまっていたりしませんか？
複数のアクションを登録されている場合は、再度アクションのコン
ディションの設定をご確認下さい。
同じ内容のメールが複数届いているような場合は、メッセージの送
信先として、同じメールアドレスとなるようなアカウントが複数送
信先に含まれていないかもご確認下さい。
deepriver - 投稿数: 7
アクションは複数登録しておりますが、それぞれメール送信先は異なっています。
1点確認なのですが、上記設定で
トリガー検知した際にあげられるアラートは、5分以内なら（1つの判定の範囲内なら）"ALERT"が何行出力していようが1通と認識しているのですが相違ないでしょうか？
"PROBREM"の判定が行われたときに1通飛ぶという認識です。
加えて1点質問なのですが、Zabbixのログ監視はファイル内の文字列のみの判定という認識なのですが合っていますか？
syslogのpriorityも判定対象となるかを気にしています。
以上、よろしくお願い致します。
TNK - 投稿数: 4769
5分以内であれば1通のみになります。
log[]やlogrt[]はテキストファイルでの判定ですので、対象としたファイルに
priorityも出力するようにsyslogの設定を行っていれば、priorityも判定対象に
なります。
ご自身の環境でどのようにsyslogを設定されているか、実際のログにどのように
出力されているかをご確認下さい。
deepriver - 投稿数: 7
ご返信ありがとうございます。
設定自体が正しいとすれば、この事象は何に起因するものなのでしょうか。
ざっと考えてみたところ、以下の2点を疑っています
・トリガーステータスが判定時間の経過を待たずにPROBREMとOKの行き来を繰り返している。
・アクションがOK⇒PROBREM時ではなくPROBREM⇒PROBREM時にも動作している。
前回の投稿と重複した質問になるかもしれませんが、
「Condition : Triger value = "PROBREM"」
はステータスがOK⇒PROBREMになったときにメールを飛ばす、という認識で相違ありませんか？
逆にいえば、やはりファイル内に出力されている文字列以外は判定対象外ということですね。
こちらの環境を確認してみたところ出力しない設定になっているようです。
TNK - 投稿数: 4769
失礼致しました。
恐らくこれだと思います。
改めてご提示頂いた設定内容を確認させて頂きました。
そうすると、アイテムで
<code>
log[/var/log/messages]
</code>
のみを指定されているので、「alert」に合致するものもしないも
のもすべてトリガーの判定処理に引き渡されます。
そうすると、/var/log/messagesに、
(1) alertがある行
↓
(2) alertがない行
↓
(3) alertがある行
と出力されると、(1)で障害と判定され、(2)で障害復旧とみなされ、
(3)で再度障害発生とみなされます。
つまり、現在の設定では間にiregexp()で合致しない行が含まれる
たびに障害復旧とみなされ、再度iregexp()に合致すると障害発生
ということでメールの送信が行われているのだと思われます。
対策としては、
１．アイテムの段階でフィルタリングを行う
２．式を改善する
のどちらかが考えられます。
具体的には、簡単に検証してから改めて書かせていただきます。
deepriver - 投稿数: 7
ご返信ありがとうございます。
再度のご確認ありがとうございます。
私の認識では
log[/var/log/messages].nodata(300)}=0
の条件式によりトリガー検知後、5分間メッセージを受信せずにステータスがOKに変わるまではメール送信されないものと思っておりました。
＃前提としてアクション設定の「Triger value = PROBREM」の条件により、メール送信はトリガーステータスがOK⇒PROBREMに変わった場合のみ行われるという認識でいます。
つまり、表示上はPROBREMのままでも内部的にはPROBREM⇒OK⇒PROBREMという判定を行っているということですね。
しかし、その場合だとnodataの条件式の関数は表示を戻すのみということになるのでしょうか。
ご手数おかけして申し訳ございません。
具体的な対策をお待ちしております。
以上、よろしくお願い致します。
TNK - 投稿数: 4769
いくつかのパターンでやってみましたが、とりあえず、以下の設定が良いのでは
ないでしょうか。
先日対策候補としてあげた、アイテム取得時にフィルタリングする方法です。
アイテムで、「alert」(大文字小文字混在)の行を取得するようにして、トリガー
では、そのアイテムを利用します。
また、/var/log/messagesであるならば、ローテーションが行われる可能性が
ありますので、log[]ではなくlogrt[]を利用した方がよいと思います。
以下が設定例です。
・アイテム
タイプ： Zabbixエージェント(アクティブ)
キー ： logrt[/var/log/messages*,"[aA][Ll][Ee][Rr][Tt]"]
データ型： ログ
更新間隔(秒)： 30
・トリガー
条件式：(見やすくするため改行入れています)
({ホスト名:logrt[/var/log/messages*,"[aA][Ll][Ee][Rr][Tt]"].nodata(300)}=0)&
({ホスト名:logrt[/var/log/messages*,"[aA][Ll][Ee][Rr][Tt]"].iregexp(alert)}=1)
イベント生成： ノーマル
深刻度 ： 軽度の障害
「error」「warn」に関しても同様にアイテムから作成するようにして下さい。
より良い方法がございましたらお教え下さい。＞皆様
deepriver - 投稿数: 7
ご返信ありがとうございます。
また、具体的な式のご提示ありがとうございます。
お察しの通り、/var/log/messagesはローテート設定をしております。
ローテーションが行われるファイルに対してlog[]を使うことでどういったことが発生しうるのでしょうか？
こちらの条件式についてなのですが、iregxep関数も使用している意図は何なのでしょうか。
item取得時にフィルタリングするならば、トリガーに引き渡された時点で判定文字列(今回の場合大小区別なく"alert")を含んでいるため、必要ないのでは？と思っています。
すみませんがこちらについてももしご存知でしたらお教え下さい。
また、これに関連して結局アクション設定で使用される判定はトリガー条件式の表示上と内部の判定どちらを使用しているのかを知りたいと思っています。
＃これ次第で設定を見直す必要があると思うので・・・。
ばらばらと質問してしまい申し訳ございません。
以上、よろしくお願い致します。
TNK - 投稿数: 4769
Zabbixエージェントがログのチェックを行って、次のチェックを行
うまでの間に、
１．エラーとなるログが出力
２．ログのローテーションが実行
ということが起こると、log[]の場合、指定したファイル名のファ
イルしかチェックしませんので、１．で出力されたログは監視のチ
ェックに引っかからなくなります。
つまり、出力されたエラーログを見逃してしまう場合があります。
必要はありません。
該当するログが出力されたことを判別する式を書いてください。
私は、deepriverさんが書かれていた元の式を極力そのまま生かし
ただけです。
恐らく、ブラウザでご覧になられていたため、デフォルトですと30
秒間隔でしか更新されませんので、PROBREMのままだと思われてい
たのだと思います。
こまめにブラウザでも更新を行っていれば、PROBREM⇒OK⇒PROBREM
と状態が変化していたはずだと思います。
イベントの画面でも状態の遷移は確認できます。
deepriver - 投稿数: 7
ご返信ありがとうございます。
ご説明ありがとうございます。
ということは、logrt[]はlog[]の上位互換のような認識でしょうか。
処理効率についてはlog[]の方が優れていそうですが、この点については両者でどの程度差異があるものなのでしょうか。
＃環境次第といったらそれまでですが。
ご配慮ありがとうございます。
iregexp()が必要がない旨了解致しました。
表示や内部といった区分けは基本的には存在しないのですね。
了解致しました。
これまでいただいた情報を総合すると、
PROBREM⇒OK⇒PROBREMといった遷移を繰り返さないよう、
エラー検知となるアイテム以外は出力しないことが解決策としてあげられるという旨、理解致しました。
ちなみに、その他に何か代替案はありますでしょうか？
私の方でも考えてみましたが上記案の他、有効な案が思いつかず・・・。
長らくお付き合いいただき誠に感謝しております。
よろしければもうしばらくお付き合いいただければと存じます。
以上、よろしくお願い致します。
TNK - 投稿数: 4769
<code>
ということは、logrt[]はlog[]の上位互換のような認識でしょうか。
処理効率についてはlog[]の方が優れていそうですが、この点については両者でどの程度差異があるものなのでしょうか。
</code>
上位互換というような認識でよいと思います。
log[]は決まったファイル名のファイルだけを処理するのに対して、
logrt[]は指定されたパターンに合致するファイルの一覧を取得し
て処理すべきファイルを決定するので、それだけ処理は追加され
ることになります。
しかし、
１．指定されたパターンのディレクトリ部分の文字列を切り出し
２．そのディレクトリにあるファイルの一覧を取得
３．ファイル名のパターンマッチング
４．ファイルの属性(変更日付)を取得して比較
する程度ですので、それよりも、ログの内容を処理してサーバ側に
送信する処理の方がより多くの時間と資源を費やすでしょう。
そもそも、処理効率よりも、障害やエラーを見逃すほうが問題とは
ならなのでしょうか？
PROBREM⇒OK⇒PROBREMとなっていたのは、式が不適切だったからで
す。
今回、ご要望されている機能をよりご要望に近い形で実現するため
に、アイテムで絞るような設定を提示させて頂きました。
例えば、最初にご提示いただいた以下の式の部分です。
<code>
({Host001:log[/var/log/messages].nodata(300)}=0)
</code>
このままですと、/var/log/messagesにエラーとは全く関係の無い
ログが出力され続けていれば、いつまでたってもトリガーのステー
タスは正常に戻りません。
ですので、
<code>
({Host001:logrt[/var/log/messages*,"[aA][Ll][Ee][Rr][Tt]"].nodata(300)}=0)
</code>
として、特定の文字列にマッチするものとして絞り、他のログが出
力され続けていても、条件に合致するログが5分間出力されなかっ
たら正常に戻せるようにしたわけです。
エラー検知とは直接関係無くても、サーバの性能が許す限り、様々
なデータをサーバで取得しても全く問題ありません。