トリガーベースのイベント相関
概要
トリガーベースのイベント相関により、1つのトリガーによって報告された個別の障害を相関付けることができます。
通常、OKイベントは1つのトリガーによって作成されたすべての障害イベントをクローズできますが、より詳細な対応が必要な場合があります。たとえば、ログファイルを監視している場合、ログファイル内の特定の問題を検出し、それらをまとめてではなく個別にクローズしたいことがあります。
これは、PROBLEM event generation mode パラメータが Multiple に設定されているトリガーで発生します。このようなトリガーは通常、ログ監視やトラップ処理などに使用されます。
Zabbixでは、タグ付けに基づいて障害イベントを関連付けることができます。タグは値を抽出し、障害イベントの識別情報を作成するために使用されます。これを利用することで、タグの一致に基づいて障害を個別にクローズすることもできます。
言い換えると、同じトリガーがイベントタグによって識別される個別のイベントを作成できます。そのため、障害イベントは1件ずつ識別でき、イベントタグによる識別に基づいて個別にクローズできます。
動作の仕組み
ログ監視では、次のような行に遭遇することがあります。
Line1: Service 1 stopped
Line2: Service 2 stopped
Line3: Service 1 was restarted
Line4: Service 2 was restarted
イベント相関の考え方は、Line1 の障害イベントを Line3 の復旧と、Line2 の障害イベントを Line4 の復旧と対応付け、それらの障害を1つずつクローズできるようにすることです。
Line1: Service 1 stopped
Line3: Service 1 was restarted #Line 1 の障害がクローズ
Line2: Service 2 stopped
Line4: Service 2 was restarted #Line 2 の障害がクローズ
これを行うには、これらの関連するイベントに、たとえば "Service 1" や "Service 2" のようなタグを付ける必要があります。これは、ログ行に正規表現を適用してタグ値を抽出することで実現できます。すると、イベントが作成されたときに、それぞれ "Service 1" と "Service 2" のタグが付与され、障害を復旧と対応付けられるようになります。
設定
アイテム
まず、ログファイルを監視するアイテムを設定するとよいでしょう。たとえば、次のようにします。
log[/var/log/syslog]

アイテムを設定したら、設定変更が反映されるまで1分ほど待ち、その後 最新データ に移動して、アイテムがデータの収集を開始していることを確認してください。
トリガー
アイテムが動作している状態で、トリガーを設定する必要があります。ログファイル内のどのエントリに注意を払うべきかを判断することが重要です。たとえば、次のトリガー式は 'Stopping' のような文字列を検索し、潜在的な問題を示します。
find(/My host/log[/var/log/syslog],,"regexp","Stopping")=1
"Stopping" という文字列を含む各行が障害と見なされるようにするには、トリガー設定の Problem event generation mode も 'Multiple' に設定してください。
次に、復旧式を定義します。次の復旧式は、"Starting" という文字列を含むログ行が見つかった場合に、すべての障害を解決します。
find(/My host/log[/var/log/syslog],,"regexp","Starting")=1
これを望まない場合は、対応する根本原因の障害がすべての障害ではなく、確実にクローズされるようにすることが重要です。そこでタグ付けが役立ちます。
トリガー設定でタグを指定することで、障害と復旧を一致させることができます。次の設定を行う必要があります。
- Problem event generation mode: Multiple
- OK event closes: タグ値が一致する場合はすべての障害
- イベント照合用のタグ名を入力する

- ログ行からタグ値を抽出するようにタグを設定する

正しく設定できると、Monitoring > Problems で、アプリケーションごとにタグ付けされ、対応する復旧と照合された障害イベントを確認できるようになります。

誤設定が起こり得るため、関連のない無関係な障害に対しても同様のイベントタグが作成される可能性がある場合は、以下のケースを確認してください。
-
インデックス付きマクロは常にトリガー設定の Expression フィールドを参照し、Recovery expression は参照しません。 たとえば、復旧イベントでは、{ITEM.VALUE1} は復旧時点における problem expression 内の最初のアイテムの最新値に解決されます。 復旧式が別のアイテムに基づいており、復旧までの間に problem expression のアイテム値が変化すると、イベントのタグが異なり、相関されません。
-
2つのアプリケーションが同じログファイルにエラーおよび復旧メッセージを書き込む場合、メッセージ形式が異なるときは {ITEM.VALUE} マクロからサービス A とサービス B の名前を抽出するために、タグ値に別々の正規表現を使って、同じトリガー内で2つの service タグを異なるタグ値で使用したいと考えるかもしれません。しかし、正規表現に一致しない場合は、これは想定どおりに動作しない可能性があります。 一致しない正規表現は空のタグ値を生成し、障害イベントと OK イベントの両方で単一の空のタグ値があれば、それらは照合されてしまいます。 そのため、サービス A の復旧メッセージが誤ってサービス B のエラーメッセージをクローズしてしまう可能性があります。
-
実際のタグとタグ値は、トリガーが発火したときにのみ表示されます。 使用した正規表現が無効な場合は、黙って *UNKNOWN* 文字列に置き換えられます。最初の *UNKNOWN* タグ値を持つ障害イベントを見逃すと、同じ *UNKNOWN* タグ値を持つ後続の OK イベントが表示され、それらが本来クローズすべきでない障害イベントをクローズしてしまう可能性があります。
-
ユーザーがタグ値としてマクロ関数なしで {ITEM.VALUE} マクロを使用する場合、255文字の制限が適用されます。ログメッセージが長く、最初の255文字が特定性のない内容である場合、無関係な障害に対しても同様のイベントタグが生成される可能性があります。