相関イベントを使用したイベントポリシーのトリガー

2つ以上の相関イベントが発生したときに実行するイベントポリシーを設定します。

相関イベントの理解

単一のイベントでトリガーするようにイベントポリシーを設定するだけでなく、2つ以上のイベントを関連付けるイベントポリシーを設定することもできます。イベントが指定どおりに発生した場合、イベント ポリシーは設定されたアクションを実行します。例えば、UI_COMMIT_PROGRESSイベント発生後5分以内にUI_CONFIGURATION_ERRORイベントが生成された場合に、特定の動作モードコマンドを発行することができます。別の例として、DCD_INTERFACE_DOWNイベントが60秒間隔内に2回生成された場合に、特定のファイルをアップロードすることができます。

イベントポリシーでイベントを関連付けるには、 [edit event-options] 階層レベルで以下のステートメントを含めます。

eventsステートメントでは、複数のトリガーイベントを一覧表示できます。イベントポリシーでのイベント定義については、イベントポリシーとイベント通知の概要を参照してください。これらのイベントを他のイベントと関連付けるには、withinやattributes-matchステートメントを設定します。

withinステートメントは、トリガーイベントが発生する前に指定された時間間隔内に発生しなければならない(または発生してはならない)相関イベントを定義します。attributes-matchステートメントにより、システムはイベントの属性を考慮に入れることができます。attributes-matchステートメントは、イベントの属性を別のイベントの属性または正規表現と関連付けることができます。イベントポリシーは、指定された条件が満たされた場合にのみ、thenステートメントで設定されたアクションを実行します。以下のセクションでは、ステートメントの使用方法について説明します。

時間間隔によるイベントの関連付け

トリガーイベントが別のイベントの後に指定された時間間隔内に発生した場合にのみ実行されるようにイベントポリシーを設定できます。イベントを関連付けるには、 within seconds events ステートメントを設定します。ポリシーは、 within seconds events ステートメントで定義された相関イベントのいずれかが、最初の events ステートメントで定義されたトリガーイベントのいずれかが発生する前に設定された秒数内に発生した場合に実行されます。秒数は60〜604,800です。 not ステートメントは、トリガーイベントが発生する前に設定された時間間隔内に相関イベントが発生しない場合にのみ、ポリシーが実行されるようにします。

たとえば、トリガーイベント( event3、 event4、または event5)の1つが、相関イベントのいずれか( event1 または event2)の後60秒以内に発生した場合、デバイスは次のポリシーを実行します。

複数のイベントが発生した後、指定された時間間隔内にトリガーイベントが発生した場合にのみ実行されるようにイベントポリシーを設定するには、個別の within ステートメントを設定する必要があります。各 within ステートメントは、異なる時間間隔を使用する必要があります。複数の within ステートメントを設定する場合、ポリシーをトリガーするために、それぞれの時間枠内に発生する一致するイベントが1つすべてのステートメントに必要です。したがって、システムは論理ANDを使用してステートメントを評価します。

たとえば、トリガーイベント( event4、 event5、または event6)のいずれかが event1 後60秒以内に発生し、 event2 または event3後50秒以内に発生した場合、デバイスは次のポリシーを実行します。

時間間隔でイベントを関連付けるイベントポリシーを設定するには:

  1. 1つ以上のトリガーイベントを設定します。

  2. トリガーイベントの前、指定された時間間隔内に発生しなければならない、または発生してはならない相関イベントを設定します。

    • トリガーイベントの前に指定された時間間隔内に相関イベントが発生する必要があることを指定するには、 not キーワードを省略します。

    • トリガーイベントが発生する前の指定された時間間隔内に相関イベントが発生し ないように 指定するには、 not キーワードを含めます。

    • トリガーイベントの前に指定された時間間隔内に複数の相関イベントが発生する必要があることを指定するには、それぞれ異なる時間間隔を定義する複数の within ステートメントを含めます。

  3. 条件が満たされた場合にイベントポリシーが実行するアクションを設定します。

withinステートメントは、トリガーイベントが特定の時間間隔内に一定回数発生した場合のイベントポリシーの実行もサポートします。詳細については、「イベント数に基づいてイベントポリシーをトリガーする」を参照してください。

イベント属性に基づくイベントの関連付け

多くのイベントには、イベントポリシーで参照できる1つ以上の属性があります。例えば、 UI_COMMIT イベントに関する以下のシステムログメッセージを考えてみましょう。

一般的な UI_COMMIT イベントメッセージは、 User 'username' requested 'command' operation (comment: message)です。

username、command、messageの3つの属性があります。

attributes-matchステートメントを使用すると、equals、matches、starts-with比較を使用してイベント属性を目的の値と比較することで、より正確なイベントポリシーマッチングを構築できます。このステートメントでは、イベントを次のように関連付けています。

  • event1.attribute-name equals event2.attribute-name— event1 属性と event2 属性が同じ値を持つ場合にのみポリシーを実行します。

  • event.attribute-name matches regular-expression— event 属性値が指定された正規表現に一致する場合にのみポリシーを実行します。詳細については、「 正規表現を使用してポリシーをトリガーするイベントのセットを絞り込む」を参照してください。

  • event1.attribute-name starts-with event2.attribute-name— event1 属性値が event2 属性の値で始まる場合にのみ、ポリシーを実行します。

attributes-matchステートメントで参照されるイベントは、トリガーイベントまたはイベントポリシーのwithinステートメントに含まれる相関イベントのいずれかである必要があります。attributes-matchステートメントの場合、1つ以上のwithinステートメントを定義する必要があります。

  • equalsまたはstarts-withの比較を含む

  • トリガーイベントではないイベントの句を含む matches 比較が含まれます。

attributes-matchステートメントには、複数のequals、matches、およびstarts-with比較ステートメントを含めることができます。システムは、論理 AND 運用担当者を使用して複数の比較ステートメントを評価します。したがって、イベント ポリシーを実行するには、すべてのattributes-match条件が true と評価される必要があります。

例えば、複数のリアルタイムパフォーマンスモニタリング(RPM)プローブを設定し、そのうちの1つが所有者名 Connectivity を使用し、 Managementという名前のテストがあるとします。イベントポリシーでプローブの ping_test_failed イベントを参照する場合、どのRPMプローブテストがイベントを生成したかを区別する必要があります。以下のイベントポリシーは、 ping_test_failed イベントの test-owner 属性と test-name 属性に一致するため、イベントポリシーは正しいプローブに対してのみトリガーされます。イベント ポリシーは、両方の一致条件が true である場合にのみ実行されます。この例の詳細な説明については、「 例:時間間隔とイベント属性に基づくイベントの関連付け」を参照してください。

同様に、以下のイベント・ポリシーは、 messages 属性を持つ非標準のSYSTEMイベントでトリガーされます。 attributes-match ステートメントでは、イベントポリシーを呼び出すには、 matches ステートメントがすべてtrueである必要があります。

attributes-matchステートメント内でイベントポリシー変数を使用して、トリガーイベント属性と相関イベント属性を区別できます。トリガーイベントとは、[edit event-options policy policy-name events]階層レベルで設定するイベントです。ダブル・ドル記号($$)表記は、ポリシーをトリガーするイベントを表し、{$$.attribute-name}トリガー・イベントの属性の値に解決されます。イベントを関連付ける場合、イベント名($event)表記の付いた1つのドル記号は、イベント名に一致する最新のイベントを表し、{$event.attribute-name}はそのイベントに関連付けられた属性の値に解決されます。

例えば、次のイベントポリシーは、5分間に4つ以上のコミットが実行され、1つ以上の相関イベントのユーザー名がトリガーイベントのユーザー名と同じ場合、 then ステートメントの下でのアクションを実行します。

特定のイベントで参照できる属性を見つけるには、次のようなさまざまな方法があります。

  • システムログエクスプローラツールを使用します。

  • CLIで help syslog event 動作モードコマンドを使用します。

  • 属性を設定するときは、設定モードでコンテキストに応じたヘルプを使用します。

システムログエクスプローラアプリケーションを使用すると、特定のオペレーティングシステムおよびリリースの標準システムログメッセージを検索できます。メッセージの詳細には、そのイベントで参照できる属性が含まれます。さらに、「属性」フィールドには、そのイベントのすべての属性が一覧表示されます。

CLIでは、 help syslog event 動作モードコマンドは、特定のイベントで参照できる属性のリストも表示します。コマンド出力は、イベント属性を山括弧(<>)で示しています。以下の出力は、 ACCT_ACCOUNTING_SMALL_FILE_SIZE イベントに filename、 file-size、 record-sizeの3つの属性があることを示しています。

注:

パイプ(|)記号を使用して検索の出力をフィルター処理できます。パイプ記号の使用について詳しくは、 『CLIユーザーガイド』を参照してください。

次の例に示すように、[edit event-options policy policy-name]階層レベルでset attributes-match event?設定モードコマンドを発行することで、イベント属性を表示することもできます。

注:

この set コマンドでは、イベント名と疑問符(?)の間にスペースはありません。

イベントポリシーでトリガーイベントと関連付けイベントを表す方法

イベントスクリプト引数や、 execute-commands ステートメントなどのサポートされているイベントポリシーステートメントでは、イベントポリシー変数を使用して、 トリガーイベント と 相関イベントを区別できます。トリガーイベントと相関イベントは、 [edit event-options policy policy-name] 階層レベルの以下のステートメントで設定します。

  • トリガーイベント— events ステートメントで設定
  • 相関イベント— within seconds events ステートメントで設定

以下の形式のイベントポリシー変数を使用して、トリガーイベントと相関イベントを表すことができます。

  • {$$.attribute-name}—ダブルドル記号($$)表記は、ポリシーをトリガーするイベントを表します。属性名と組み合わせると、変数はトリガーイベントに関連付けられた属性の値に解決されます。たとえば、 {$$.interface-name} はトリガーイベントに関連付けられたインターフェイス名に解決されます。

  • {$event.attribute-name}—イベント名($event)表記の付いた1つのドル記号は、 eventに一致する最新のイベントを表しています。属性名と組み合わせると、変数はそのイベントに関連付けられた属性の値に解決されます。例えば、ポリシーが show interfaces {$COSD_CHAS_SCHED_MAP_INVALID.interface-name} コマンドを発行すると、 {$COSD_CHAS_SCHED_MAP_INVALID.interface-name} 変数は、イベントプロセスによってキャッシュされた最新の COSD_CHAS_SCHED_MAP_INVALID イベントに関連付けられたインターフェイス名に解決されます。

  • {$*.attribute-name}—アスタリスク($*)表記の付いたドル記号は、相関するイベントのいずれかに一致する最新のイベントを表します。この変数は、ポリシー設定で指定された相関イベントのいずれかに一致する、最新のイベントに関連する属性の値に解決されます。

イベントポリシーでは、イベントポリシー変数を使用して特定のイベントを参照できます。次のイベントポリシーについて考えてみましょう。

show interfaces {$$.interface-name}コマンドでは、イベントe1、e2、またはe3のinterface-name属性の値が{$$.interface-name}変数に置き換えられます。

show interfaces {$e4.interface-name}コマンドでは、直近のe4イベントのinterface-name属性の値が{$e4.interface-name}変数に置き換えられます。

show interfaces {$*.interface-name}コマンドでは、最新のe4、e5、またはe6イベントのinterface-name属性の値が{$*.interface-name}変数に置き換えられます。e1、e2、またはe3のいずれかがe4、e5、またはe6の後60秒以内に発生した場合、その相関イベント(e4、e5、またはe6)のinterface-name属性の値が{$*.interface-name}変数に置き換えられます。相関イベントにinterface-name属性がない場合、ソフトウェアはshow interfaces {$*.interface-name}コマンドを実行しません。

e1がe4とe5の両方から60秒以内に発生した場合、{$*.interface-name}変数はe4にinterface-name属性の値を使用します。イベントプロセス(eventd)がwithinステートメントで設定された順番に相関イベントを検索するため、ポリシーはe4を使用します。この場合、順序はe4 > e5 > e6です。

例:時間間隔に基づくイベントの関連付け

以下のイベントポリシーは、一連のコマンドを発行し、結果の出力ファイルをアーカイブサイトにアップロードします。システムは、トリガーイベント( event3、 event4、または event5)の1つが、相関イベントのいずれか( event1 または event2)が発生してから60秒以内に発生した場合、イベントポリシーを実行します。ポリシーの擬似コードは次のとおりです。

イベントポリシーの宛先は、2つのアーカイブサイトを定義します。デバイスはリストの最初のアーカイブサイトへの転送を試み、転送に失敗した場合にのみ次のサイトに移動します。イベントポリシーの設定は次のとおりです。

例: イベント属性に基づくイベントの関連付け

以下のイベントポリシーでは、イベント属性値が一致する場合、2つのイベントが相関します。両方のイベントの属性を一致させることで、2つのイベントが関連していることが保証されます。この場合、インターフェイス アドレスが一致し、物理インターフェイス(ifd)名が一致する必要があります。

RPD_KRT_IFDCHANGEエラーは、ルーティングプロトコルプロセス(rpd)がインターフェイスの状態を変更するリクエストをカーネルに送信し、リクエストが失敗した場合に発生します。RPD_RDISC_NOMULTIエラーは、インターフェイスがルーター検出用に設定されているが、必要に応じてIPマルチキャスト操作をサポートしていない場合に発生します。

例:時間間隔とイベント属性に基づくイベントの関連付け

次の例では、組織は、管理ネットワークへの接続を失う結果となったすべての失敗した設定を記録したいと考えています。組織は、リアルタイムパフォーマンス監視(RPM)テストセットアップを使用して、管理ネットワークの到達可能性を毎分検証します。オペレーターは、常に commit confirmed CLIコマンドを使用して変更をコミットします。 commit confirmed コマンドを使用すると、設定の変更が接続に影響を与える場合に、設定を自動的にロールバックできます。

イベントポリシーは、イベントスクリプト save-rollback.slaxを実行して、自動ロールバックによって上書きされた失敗した設定を特定の場所にコピーします。イベントスクリプトは、保存と後で確認するために、 /config/juniper.conf.1.gz ロールバックファイルを /var/tmp ディレクトリにコピーします。

イベントポリシートリガーイベントは、UI_COMMIT_NOT_CONFIRMEDイベントです。このイベントは、デバイスが確認されたコミットを自動的にロールバックするときに発生します。システムがコミット確認ロールバックをトリガーすると、UI_COMMIT_NOT_CONFIRMEDイベントが 2 回発生します。最初のイベントメッセージはロールバックが進行中であることを示し、2番目のイベントメッセージはロールバックが完了したことを示します。したがって、イベント ポリシーは、システムがイベント ポリシーを 2 回トリガーしないように、2 つのUI_COMMIT_NOT_CONFIRMED イベントを関連付ける必要があります。この例では、2つ目のUI_COMMIT_NOT_CONFIRMEDイベントは、最初のイベントから50秒以内に発生する必要があります。

設定によって管理ネットワークへの接続が失われたかどうかを判断するために、イベント ポリシーは、UI_COMMIT_NOT_CONFIRMED イベントと RPM プローブからの PING_TEST_FAILED イベントを関連付けます。PING_TEST_FAILED イベントは、管理ネットワークへの RPM テストが失敗すると発生します。この例では、UI_COMMIT_NOT_CONFIRMEDイベントはPING_TEST_FAILEDイベントから60秒以内に発生する必要があります。イベントを生成したRPMプローブテストを指定するために、イベントポリシーには attributes-match ステートメントが含まれ、イベントの test-owner 属性が Connectivity と一致し、イベントの test-name 属性が Managementと一致する場合にのみトリガーされます。

イベントポリシーは、PING_TEST_FAILEDイベントと最初のUI_COMMIT_NOT_CONFIRMEDイベントに対して個別の within ステートメントを設定します。複数の within ステートメントを使用することで、イベントポリシーがトリガーされるには、両方の条件が発生する必要があります。各 within ステートメントに必要な時間間隔は異なります。同様に、ポリシーをトリガーするには、両方の attributes-match 条件が当てはまる必要があります。

イベントポリシーの設定は次のとおりです。

save-rollback.slaxイベントスクリプトは次のとおりです。

Junos OSを実行しているデバイスがイベントポリシーをトリガーすると、デバイスはロールバック設定ファイルをタイムスタンプを含む新しいファイル名で/ var/tmp ディレクトリに保存します。