1 トリガーによるイベント相関

概要

トリガーベースのイベント相関では、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」というタグが付けられ、障害を復旧に対応付けることができます。

設定

item

始めに、例えばログファイルを監視するような項目を設定するのがよいでしょう:

log[/var/log/syslog]

item が設定された状態で、設定変更が反映されるまで1分ほど待ってから、Latest dataにアクセスして、
item がデータ収集を開始したことを確認します。

トリガー

アイテムが動作したら、次にトリガーを設定する必要があります。重要なのは、ログファイル内のどのエントリに注意を払うべきかを判断することです。例えば、次のトリガー式は、潜在的な問題を示すために '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: タグ値が一致する場合はすべての問題
  • イベントのマッチングに使用するタグ名を入力する

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

正しく設定されると、MonitoringProblems で、アプリケーションごとにタグ付けされ、対応する復旧と関連付けられた問題イベントを確認できるようになります。

設定ミスの可能性があり、無関係な問題に対して類似したイベントタグが作成される場合があるため、以下で説明するケースを確認してください。

  • インデックス付きマクロは常にトリガー設定の Expression フィールドを参照し、Recovery expression は参照しません。
    例えば、復旧イベントでは、{ITEM.VALUE1} は復旧時点における問題式内の最初のアイテムの最新値に展開されます。
    復旧式が別のアイテムに基づいており、復旧時までに問題式のアイテム値が変化している場合、イベントには異なるタグが付与され、相関付けされません。

  • 2つのアプリケーションが同じログファイルにエラーおよび復旧メッセージを書き込む場合、ユーザーは同じトリガー内で2つの service タグを使用し、タグ値内で個別の正規表現を使って {ITEM.VALUE} マクロから例えばサービスAとサービスBの名前を抽出し、それぞれ異なるタグ値を設定しようと考えるかもしれません(例えば、メッセージ形式が異なる場合)。しかし、正規表現に一致しない場合、この方法は想定どおりに動作しないことがあります。
    一致しない正規表現は空のタグ値を生成し、問題イベントとOKイベントの両方に1つでも空のタグ値があれば、それだけで相関付けされます。
    そのため、サービスAの復旧メッセージによって、誤ってサービスBのエラーメッセージがクローズされる可能性があります。

  • 実際のタグおよびタグ値は、トリガーが発生したときにのみ表示されます。
    使用した正規表現が無効な場合、それは暗黙的に *UNKNOWN* 文字列に置き換えられます。初回の問題イベントで *UNKNOWN* タグ値が見落とされると、後続のOKイベントに同じ *UNKNOWN* タグ値が現れ、本来クローズすべきでない問題イベントをクローズしてしまう可能性があります。

  • ユーザーがマクロ関数を使わずに {ITEM.VALUE} マクロをタグ値として使用する場合、255文字の制限が適用されます。ログメッセージが長く、先頭255文字に特定性がない場合、これによっても無関係な問題に対して類似したイベントタグが生成される可能性があります。