ログの監視について

ふりっぱぁです。
長文で失礼します。

Agent(active)と、log[] アイテムを用いたログの監視で、良い設定方法は無いものかと悩んでおります。

色々試した過程と、「監視で実現したいこと」をとりとめなく書かせてもらってます。
他にログ監視で悩んでる方々のヒントになれば幸いです。

・皆さんはどのようにしてログの監視を活用されていますか?
・もっと簡略な設定方法はないのか?

といったことをレス頂けると大変嬉しいです。

<1>
まず、一般的(と思われる)設定で試してみました。
<code>
アイテム:log[/var/log/messages]
トリガー:{HOST:log[/var/log/messages].str(ERROR)}=1
</code>
上記のような設定では「全ログが送信される」という動作になります。

今回、監視対象にしようと考えているログファイルは、常時、それなりの量が出力されるファイルなので、
監視したいエラー発生を示す行とは無関係な、些細な情報ログの行まで送信されてしまうことになり、
サーバ側の DB 資源や、agent/server 間の通信資源を無駄に浪費してしまうことになります。

できることならば、浪費を避けるために、エラーと判定すべき行だけを送れないか…と考えました。

<2>
また、ログがある程度の頻度で出力されていることと、エラー以外の情報も多数含んでいるため、

・エラー文字列を含む行が送られてきていても、トリガーの判定時には、それが最新行ではなくなって
 しまっていて、判定に引っかからないことがある
・トリガー判定でエラーの判定となったとしても、次の段階のトリガー評価の段階では、判定の対象が
 新たに届いた行となるため、エラーがすぐに画面から消えてしまう

といった問題が起こってしまいました

<3>
マニュアルを調べてみたところ、アイテム設定を以下のように変更することで、"ERROR" という文字列を
含む行が見つかった場合だけ、agent から server へ送信させることができるのがわかりました。
<code>
アイテム:log[/var/log/messages,ERROR]
トリガー:{HOST:log[/var/log/messages,ERROR].str(ERROR)}=1
</code>
1・2で起きた問題が解決されるかと思い、早速、試してみました。

DB・通信のリソース周りは最適化できたように見えるのですが、別の問題が起こりました。

上記の設定では、一度 "ERROR" を含む行が送信されてトリガーがオンになってしまうと、最新行が常に "ERROR" を
含んでいるため、トリガーがオンのまま回復せず、ダッシュボードの警告一覧から消えない状態に陥ってしまいました。

<4>
よく考えてみると、エラーの発生はログに記載されますが、エラーから復旧したことはログに記載されません。
そこで、3時間とか24時間とか、ある一定時間以内に "ERROR" を含む行がある場合にトリガーを有効にしておいて、
WebUI や メール発報で通知を受けたら復旧作業を実施し、一定時間が経過したら、警告表示は消す…という運用で、
トリガーの設定を色々と考えました。

トリガー側で、判定する行を制限できないか…と思い、以下のように設定を変えてみたのですが、
<code>
アイテム:log[/var/log/messages,ERROR]
トリガー:{HOST:log[/var/log/messages,ERROR].str(ERROR,86400)}=1
</code>
"ERROR" を含む行の受信から1日経過しても、トリガーが有効のまま、変化しないようです。

zabbix_server のマニュアルとソースコードを追っかけながら調査してみたところ、str(string[,sec]) というトリガー条件は、

<code>
最新の1行から指定文字列をチェックしたうえで、さらに[sec]以内に受信したデータがあれば、それらもチェック対象とする
</code>

という動作をしていることがわかりました。

<5>
さらにトリガー条件を突き詰めて、
「24h以内に最新の行が届いていて、なおかつ、"ERROR"を含んでいる」
という条件を思いつき、下記のように、nodata(sec) というトリガー条件を組み合わせることで、
思ったとおりの動作を得ることができました
<code>
アイテム:log[/var/log/messages,ERROR]
トリガー:({HOST:log[/var/log/messages,ERROR].nodata(86400)}=0)&({HOST:log[/var/log/messages,ERROR].str(ERROR,86400)}=1)
</code>

コメント表示オプション

お好みのコメント表示方法を選び「設定の保存」をクリックすると変更が反映されます。
ユーザー KAZ の写真

fripperさん

私が構築した環境でもnodataと組み合わせて使っています。

キーワード行のみの絞込みですが、当方では処々の事情により全部取っています。ログ監視で使用しているDBの使用量は全体の8割も使っています。

その為、3ヶ月以上のデータは保持してません。
過去データは1週間に一度DBのデフラグ&バックアップを取っているので、見る場合はデータを別環境にインポートして見る様な仕組みにしています。

ユーザー fripper の写真

>KAZさん

レスありがとうございます

>私が構築した環境でもnodataと組み合わせて使っています。

やはりそうなるのでしょうか。
というか、私の選択はあながち誤りではなかったと確信できてひと安心することができました。

ログ情報のDB全体に対する占有率が「全体の8割」というのは驚きでした。
「設定によっては、半分近くはコレで消費されそうだなぁ」と推測していたのですが、
まさか8割とは。

人間にとって都合の良い設定というのは、やはり微妙なさじ加減が
必要なんだなぁと痛感するところです。

ユーザー fripper の写真

色々テストしているうちに、先日の書き込み<5>で挙げた以下の設定では、
24時間経過してもエラー通告が消えず、正常に戻らない問題にぶつかりました。
<code>
アイテム:log[/var/log/messages,ERROR]
トリガー:({HOST:log[/var/log/messages,ERROR].nodata(86400)}=0)&({HOST:log[/var/log/messages,ERROR].str(ERROR,86400)}=1)
</code>

上記トリガーの想定では「24h以内に最新の行が届いていて、最新の行には "ERROR" という文字列が含まれている」
という条件のつもりだったのですが…

問題となったのは、zabbix_server の再起動を実施した場合のことです。
zabbix_server が再起動されると、どうやら log 関連のアクティブチェックが
再度ひととおり実施されるようで、nodata の判定基準となる
「最新のデータ取得時刻」が 0 にリセットされてしまうようです。

そのため、発生から 24h 以上経過しているにもかかわらず、トリガーによる判定は「異常」を示しつづけてしまったようです。
zabbix_server の再起動から一定時間を経過すると、該当トリガーは正常に戻りました。

このような場合にも対応できるようにするには、さらに count の判定関数も組み合わせて、以下のようにするしかないのでしょうか…
<code>
アイテム:log[/var/log/messages,ERROR]
トリガー:({HOST:log[/var/log/messages,ERROR].nodata(86400)}=0)&({HOST:log[/var/log/messages,ERROR].count(86400)}>0)&({HOST:log[/var/log/messages,ERROR].str(ERROR,86400)}=1)
</code>

ユーザー KAZ の写真

fripperさん

log[/var/log/messages,ERROR]の監視間隔はどのくらいですか?

私が設定しているlog[/var/log/messages]は300秒なので、下記の設定で動作させています。

<code>
アイテム:log[/var/log/messages]
トリガー:({HOST:log[/var/log/messages].nodata(300)}=0)&({HOST:log[/var/log/messages,ERROR].str(ERROR,300)}=1)
</code>

ユーザー fripper の写真

>KAZさん

>log[/var/log/messages,ERROR]の監視間隔はどのくらいですか?

発生をできるだけリアルタイムに捕まえたいので、
監視間隔は 10 秒に設定しています。
アイテム設定の段階でフィルタ文字列を設定してあるので、
サーバ側に向けて大量の送信はないだろう、との判断です。

アイテム側で、こまめにデータ・状況の取得を行っておいて、

トリガー側では、「"ERROR" 文字列を含む取得結果が直近xx秒以内に存在していれば」エラーと判定。

アクション等を駆使して管理者etcに通知して、
ダッシュボード上にはエラー表示のまま残るようにする。

復旧処理や対処が実施されているかどうかは判定できないため、24時間経過した時点で
トリガー判定結果の「異常」が「正常」に戻るようにしておいて
ダッシュボード上から消えるようにする。

それまでに復旧作業を実施した場合は、できるだけ「認知」機能でマーキングすることで、
ダッシュボード上では「未対処」「対処済」がわかるようにする

というようなことを実現したいと考えているのですが…