はじめに

CentOSでログを監視します。
対象のログは「/var/log/messages」とします。

環境

Zabbixサーバ

OS:CentOS 8.2.2004
Apache:2.4.37
PHP:7.2.25
MariaDB:10.3.17
Zabbix Server:5.0.2
Zabbix Agent:5.0.2

 

検証サーバ

OS:CentOS 7.8.2003

操作手順

Zabbixの管理コンソールにサインインします。

 

パーミッションの変更

messagesは、rootユーザー以外のユーザーではアクセスすることができません。そのため、最初にオーナーとパーミッションの設定を変更してZabbixからログファイルにアクセスできるようにします。
# chown root:zabbix /var/log/messages
# chmod 640 /var/log/messages

 

テンプレートを作成する

左サイドバーから [設定] - [テンプレート] をクリックします。
「テンプレートの作成」ボタンをクリックします。
以下の通り入力します。
テンプレート名:T_Log_10
グループ:Templates
「追加」ボタンをクリックします。

 

テンプレートの作成が完了しました。
これから作成したテンプレートに対して設定を追加していきます。

 

アイテムを作成する

テンプレートの「アイテム」をクリックします。
CentOSで正規表現を使ってログを監視してみた

 

右上の「アイテムの作成」ボタンをクリックします。
アイテムの作成画面では、監視したい項目に合わせて設定します。
名前:messages
タイプ:Zabbixエージェント(アクティブ)
キー:log[/var/log/messages,"error",,,skip,,,]
「error」というキーワードで検知させます。
データ型:ログ
監視間隔:1m
アプリケーション:ログ
「追加」ボタンをクリックします。

 

正規表現を作成する

左サイドバーから [管理] - [一般設定] をクリックします。
左上の「表示設定」をクリックし、「正規表現」を選択します。
「正規表現の作成」ボタンをクリックします。
以下の通り入力します。
名前:ExcludedKeywords
条件式
 条件式の形式:文字列が含まれない
 条件式:test
「追加」ボタンをクリックします。

 

正規表現は除外キーワードを設定するために使用しています。「error」キーワードで検知させるが、「test」キーワードがあれば除外させます。

 

トリガーを作成する

テンプレートの「トリガー」をクリックします。
CentOSでログを監視してみた

 

右上の「トリガーの作成」ボタンをクリックします。
トリガーの作成画面では、監視したい項目に合わせて設定します。
名前:ログ監視
深刻度:重度の障害
条件式:{T_Log_10:log[/var/log/messages,"error",,,skip,,,].iregexp(@ExcludedKeywords)}=1 and {T_Log_10:log[/var/log/messages,"error",,,skip,,,].nodata(60)}=0
条件式の説明です。
・「error」が見つかった
・正規表現(@ExcludedKeywords)を除外
・60秒の間にデータを受信した
(60秒経過後、新たなエラーログを検知しなければ復旧となります)
【nodataの補足】
nodata:データを受信していないかの確認
(60):60秒間(公式サイトでは30秒以上必須)
=0:データを受信しているかの判定。(=1であれば受信していないかの判定)

「追加」ボタンをクリックします。

 

テンプレートをホストにリンクする

左サイドバーから [設定] - [ホスト] をクリックします。
作成したテンプレートをリンクするホストを選択します。ここでは「CentOS8-2」を選択しています。
「テンプレート」をクリックします。
新規テンプレートをリンク欄で、「T_Log_10」をリンクします。

動作確認

CentOS8-2にログインします。
syslogに任意のログを書き込みます。以下のコマンドを入力します。
# logger error
# logger test
# logger error test

 

[監視データ]-[最新データ]をクリックします。
ホストは「CentOS8-2」を選択し、「適用」ボタンをクリックします。

 

アイテム設定で指定したログのみが取得できています。
CentOSでログを監視してみた

アラートメール

アラートメールを送信している場合、アクションの実行内容に以下のような記述を記載していると思います。

Original event ID: {EVENT.ID}
障害発生時刻:{DATE} {TIME}
ホスト名:{HOST.HOST}
IPアドレス:{HOST.IP}
設置場所:{INVENTORY.LOCATION}
深刻度:{TRIGGER.SEVERITY}
障害内容:{TRIGGER.NAME}
ログ内容:{ITEM.LASTVALUE}

ここでログ内容について注意が必要です。
{ITEM.LASTVALUE} や {{HOST.HOST}:{ITEM.KEY}.last()} を使用している場合、最新のアイテム値を取得します。この内容をしっかり理解していないと想定通りのログ監視ができずドハマりします。

 

3つのパターンをご紹介します。それぞれの違いを理解しておきましょう。

 

パターン1

ログに書き込まれた内容

error

 

トリガー判定

error:条件に一致する

 

アラートメールのログ内容

error

 

パターン2

ログに書き込まれた内容

error
error test
(errorログが書き込まれて1秒後にerror testが書き込まれたとする)

 

トリガー判定

error:条件に一致する
error test:トリガーの条件に一致しない(正規表現でtestを除外しているため)

 

アラートメールのログ内容

error test

 

アラートメールのログ内容は「error」になるはずですが、実際は「error test」 になります。これは「error」のトリガー評価中に「error test」が書き込まれ、{ITEM.LASTVALUE} によって最新のアイテム値が取得されたからです。

 

トリガー評価時のアイテム値は、{ITEM.VALUE} を使用しなければなりません。ここをしっかり押さえておかないとなぜ除外キーワードを入れているのにログが検知されるのか?と悩むことになります。

 

【パターン3】

ログに書き込まれた内容

error
error test
(errorログが書き込まれて30秒後にerror testが書き込まれたとする)

 

トリガー判定

error:条件に一致する
error test:トリガーの条件に一致しない(正規表現でtestを除外しているため)

 

アラートメールのログ内容

error

 

パターン2とよく似ていますが、アラートメールのログ内容が異なります。これは30秒の間に「error」のトリガー評価が完了したためです。その後、「error test」のトリガー評価が実行されましたがトリガーの条件に一致しないので除外されました。

 

 

トップへ戻る