ログ監視のトリガー仕様について
いつもお世話になっております。
ログ監視に置いて以下の要件で監視を行っています。
要件①:”Error”を含む文字列が出力された場合、全て通知する
上記の要件①を実現するため、
以下のトリガー条件式を設定しております。
-------------------------------------------------------------------------------
{HOST:logrt[/var/log/messages,Error].iregexp(Error)}=1
障害イベントを継続して生成:チェック
-------------------------------------------------------------------------------
ただし、要件①の設定ですと
初回の障害を検知後、トリガーが復旧状態に戻らないため、
ここに新たに以下の要件が加わりました。
要件②:障害通知後、トリガーを復旧状態に戻す。
要件②を満たすため、nodata関数を使用しトリガーを復旧状態へ戻そうと考えたのですが、
以下のような条件式にした場合、nodata関数の30秒チェックの仕様により、
タイミングによって同様の障害を2回通知します。
-------------------------------------------------------------------------------
{HOST:logrt[/var/log/messages,Error].iregexp(Error)}=1 and
{HOST:logrt[/var/log/messages,Error].nodata(30)}=0
障害イベントを継続して生成:チェック
-------------------------------------------------------------------------------
障害イベントを継続して生成のチェックを外せばよいとは思うのですが、
それですと要件①が満たせなくなります。
(30秒以内に連続で出力された"Error"が通知されない)
また、復旧条件とする文字列の出力は難しい状況です。
もし要求①、②を両方満たせる方法があれば教えて頂きたく。
TNK - 投稿数: 4769
nodata()を利用するのであれば、そのような動きになるでしょう。
設定を追加して回避することは難しいと思います。
別の方法としては、以下の方法もあります。
方法1:
nodata()の条件を外して、発生したトリガーイベントに対して
コメントが入力されたら表示されないようにする。
(「障害の表示:障害対応コメント未入力のみ」とする)
方法2:
アイテムでのログのフィルタリングをやめ、nodata()の条件も
外す。
前者では、表示のフィルタリングをかけられない画面では、対象の
ホストの状態が障害のままと表示されてしまったと思います。
後者では、ログが大量であった場合は特に、データベース上の履歴
データが肥大しますし、トリガーの条件式に合致しないログが出力
されないとトリガーの状態が回復に変化しないという問題がありま
す。
kaeru - 投稿数: 264
>TNK様
ご回答ありがとうございました。
過去ログも確認しましたが、
障害全ての通知と、トリガーの復旧両立はかなり現機能では難しいこと理解しました。
ログが不定期出力で方法2が使えないため、
方法1をコメント入力の手間と天秤にかけて検討してみます。