こんにちは。SCSKの上田です。
今回はZabbixで複雑な条件のログ監視を行う方法をご紹介します。
ログ監視は、例えば「”ERROR”という文字列が含まれる」「イベントIDが”777″」などシンプルな条件なら簡単に作成できるのですが、
- “Error”という文字列と”CPU”という文字列をともにを含む
- 深刻度が”警告”以上、但しイベントIDが”777″の場合は除外する
といった複合条件や除外条件が加わると、作成が難しくなります。
そこで今回は、ログ監視の作成方法と、複雑な条件のログ監視を設定する方法について紹介していきます。
Linuxのテキストログ監視とWindowsのイベントログ監視でやり方が異なるので、それぞれについて書いていきます。
Linuxのログ監視
まずは、Linuxのログ監視についてです。
ログ監視のやり方
Linuxのログは、以下のアイテムキーで取得できます。
- アイテムキー:log[監視するファイル名]
以下は、実際に取得されたアイテムの情報です。
このように、出力されたログがプレーンテキストとして取得できます。
このログから特定の文字列を検知するには、以下のトリガー関数を使います。
- トリガー関数:find(/ホスト名/log[監視するファイル名],,,”検知したい文字列”)
このfind関数は、アイテムの最新の値に検知したい文字列が含まれている場合1を、含まれていない場合0を返します。
例えば、/var/log/messagesで“ERROR”が含まれるログを検知したい場合、アイテムキーが“log[/var/log/messages]”のアイテムを作成し、トリガー条件式が“find(ホスト名/log[/var/log/messages],,,”ERROR”)=1″となるトリガーを作成します。
複雑なログ監視のやり方
Linuxでは、複合条件も除外条件も、グローバル正規表現を使うのが有効です。
別の記事“正規表現の使い方”にて正規表現の使い方とログ監視への応用方法を紹介しておりますので、そちらをご参照ください。
Windowsのログ監視
続いて、Windowsのログ監視についてです。こちらはLinuxと比べて少々複雑です。(理由は後述)
ログ監視のやり方
まずログ取得のアイテムですが、
- アイテムキー:eventlog[イベントログ名](またはeventlog[イベントログ名称,,,,,,skip])
で取得します。パラメータに「skip」を指定しないと、ホストに蓄積された過去のログも全て取得されてしまいますので、アイテム登録した時点からのログだけ取得したい場合はskip付きののアイテムキーを使ってください。(本記事ではskip無しのアイテムキーを使用しています。)
以下は、実際に取得されたアイテムの情報です。
Linuxのログとは異なり、1つのプレーンテキストではなく「ソース」、「深刻度」、「イベントID」、「値(ログの内容)」と分かれて値が取得され、要素ごとにトリガー関数も分かれています。(これがWindowsのイベントログ監視が複雑になる理由です)
- ソース:logsource(/ホスト名/eventlog[イベントログ名],,”検知したいソース”)
- 深刻度:logseverity(/ホスト名/eventlog[イベントログ名])
- イベントID:logeventid(/ホスト名/eventlog[イベントログ名],,”検知したいイベントID”)
- 値:find(ホスト名/log[/var/log/messages],,,”検知したい文字列”)
ソース、イベントID、値の関数は、最新のイベントログに検知したい要素が含まれている場合1を、含まれていない場合0を返します。
深刻度の関数は、深刻度が“情報”なら1、”警告”なら2、,”エラー”なら4、”クリティカル”なら9を返します。
例えば、システムログでイベントの深刻度がエラーのログを検知したい場合、”logseverity(/ホスト名/eventlog[System])=4″、イベントIDが777のログを検知したいときは”logeventid(/ホスト名/eventlog[System],,”777″)=1″という風に、適切な関数を選んでトリガーを設定します。
複雑なログ監視のやり方
それでは、複雑な条件のログ監視を設定してみましょう。
①複合条件
まず、「ソースが●● かつ 深刻度が●● かつ ・・・」という複合条件を考えてみます。
トリガー条件式は、論理演算子”and”や“or”が使えるので、それを使って条件式を組み立ててみます。
例として、以下のすべての条件を満たす条件式を作ってみましょう。
- ソースがtest
- 深刻度が警告以上
- イベントIDが777
この場合、以下のような条件式になります。
これで実際に該当のイベントログを検知できるか試してみましょう。イベントログを生成するには、“EVENTCREATE”コマンドを使います。
監視対象機器のコマンドプロンプトで、以下のコマンドを実行してみましょう。
EVENTCREATE /ID 777 /L system /SO test /T ERROR /D "イベントテスト"
すると、想定通り障害として検知しました。
②除外条件
続いて、除外条件も考えてみましょう。例えば、「深刻度がエラー以上 但しソースが●●のモノは除く」といった条件です。
トリガー条件式では、否定演算子”not”も使えるので、これを使って条件を組み立てます。
以下の条件を考えてみましょう。
- 深刻度が警告以上
- 但し、イベントIDが”777″のログは除く
この場合、以下のような条件式になります。
その後、EVENTCREATEで以下のイベントを生成します。
EVENTCREATE /ID 888 /L system /SO test /T ERROR /D "イベントテスト"
これは、深刻度が警告以上でイベントIDは”777″ではないので、条件にマッチして障害として検知されます。
その後、今度は除外条件にマッチする以下のイベントを生成します。
EVENTCREATE /ID 777 /L system /SO test /T ERROR /D "イベントテスト"
こちらは除外条件にマッチするので、想定通り障害が発生しません。
③複合条件と除外条件のMIX
最後に、さらに複雑な、複合条件と除外条件の合わせ技をやってみます。
例えば、以下のような条件を考えます。
- 深刻度が警告以上
- 但し、以下の条件のいずれかを満たすものは除外する:
1:「ソースが”test”」かつ「イベントIDが”777″」
2:「ソースが”hoge”」かつ「イベントIDが”888″」かつ「内容に”テスト”という文字列が含まれる」
複雑なので、一つ一つ紐解いていきます。
まず、”深刻度が警告以上”という条件は、今まで出てきている通り、
となります。
続いて1と2の条件式は、複合条件なので以下のように書けます。
2:logsource(/ホスト名/eventlog[System],,”hoge”)=1 and logeventid(/ホスト名/eventlog[System],,”888″)=1 and find(/ホスト名/eventlog[System],,,”テスト”)=1
これらの条件を満たす場合は検知しないので、この条件をnotで否定し、最初の条件と結合します。複数条件に演算子を適用する場合は、()で括ります。
それでは、これが正しい動作をするかテストしてみましょう。
まずは除外条件に当てはまらないログを生成し、障害検知するかテストします。
EVENTCREATE /ID 888 /L system /SO test /T ERROR /D "イベントテスト"
これは除外条件1,2ともにすり抜けているので、障害として検知されます。
続いて、以下のログを生成します。
EVENTCREATE /ID 777 /L system /SO test /T ERROR /D "イベントテスト"
これは除外条件1にマッチしているので、障害として検知されません。
以下のログでも試してみましょう。
EVENTCREATE /ID 888 /L system /SO hoge /T ERROR /D "イベントテスト"
これは除外条件2にマッチしているので、こちらも障害としては検知されません。
以上のテストより、想定通り除外条件にマッチするログは検知しないことが分かります。
まとめ
今回は、LinuxとWindowsのログ監視について紹介しました。
Linuxは正規表現を使えば複合条件も除外条件も簡単に作成できますが、Windowsはイベントログの要素によって関数が分かれているため、どうしても複雑なトリガー条件式になってしまいます。しかし、論理演算子“and” “or” “not”をうまく組み合わせれば柔軟な条件式が作成できるので、この記事を参考にぜひ試してみてください。
最後まで読んでいただき、ありがとうございました。
弊社ではZabbix関連サービスを展開しています。以下ページもご参照ください。
★SCSK Plus サポート for Zabbix★
★YouTubeに、SCSK Zabbixチャンネルを開設しました!★
★X(旧Twitter)に、SCSK Zabbixアカウントを開設しました!★