相関イベントを使用してイベントポリシーをトリガーする
2 つ以上の相関イベントが発生したときに実行するイベント ポリシーを構成します。
トリガー イベントと関連付けイベントをイベント ポリシーで表現する方法
イベントスクリプト引数とサポートされているイベントポリシーステートメント( 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}- アスタリスク($*)表記の付いたドル記号は、相関するイベントのいずれかに一致する最新のイベントを表します。変数は、ポリシー構成で指定された相関イベントのいずれかと一致する最新のイベントに関連付けられた属性の値に解決されます。
イベント ポリシーでは、イベント ポリシー変数を使用して特定のイベントを参照できます。次のイベント・ポリシーについて考えてみます。
[edit event-options]
policy p1 {
events [ e1 e2 e3 ];
within 60 events [ e4 e5 e6 ];
then {
execute-commands {
commands {
"show interfaces {$$.interface-name}";
"show interfaces {$e4.interface-name}";
"show interfaces {$*.interface-name}";
}
output-filename command-output.txt;
destination some-dest;
}
}
}
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}変数に代入されます。e4、e5、またはe6後60秒以内にe1、e2、またはe3のいずれかが発生した場合、その相関イベント(e4、e5、またはe6)のinterface-name属性の値が{$*.interface-name}変数に代入されます。相関イベントに interface-name 属性がない場合、ソフトウェアは show interfaces {$*.interface-name} コマンドを実行しません。
e4とe5の両方から60秒以内にe1が発生した場合、e4のinterface-name属性の値が{$*.interface-name}変数に代入されます。これは、イベントプロセス(eventd)が、within ステートメントで設定された順番に、相関するイベントを検索するためです。この場合、順序はe4 > e5 > e6です。
例: 指定した時間間隔内の他のイベントの受信に基づくイベントの関連付け
この例のイベント ポリシーは、一連のコマンドを発行し、結果の出力ファイルをアーカイブ サイトにアップロードします。ポリシーは、 event3、 event4、 event5のいずれかのトリガー イベント( event1 または event2)が発生してから 60 秒以内に発生した場合に実行されます。ポリシーの疑似コードは次のとおりです。
if trigger event is (event3 or event4 or event5)
and
(event1 or event2 has been received within the last 60 seconds)
then {
run a set of commands;
log the output of these commands to a location;
}
イベント ポリシーでは、構成で 2 つのアーカイブ サイトを指定します。デバイスはリスト内の最初のアーカイブ サイトへの転送を試み、転送が失敗した場合にのみ次のサイトに移動します。イベント ポリシーの構成は次のとおりです。
[edit event-options]
policy 1 {
events [ event3 event4 event5 ];
within 60 events [ event1 event2 ];
then {
execute-commands {
commands {
"command";
}
output-filename my_cmd_out;
destination policy-1-command-dest;
}
}
}
destinations {
policy-1-command-dest {
archive-sites {
scp://robot@my.big.com/a/b;
scp://robot@my.little.com/a/b;
}
}
}
例:イベント属性に基づくイベントの関連付け
次のイベント ポリシーでは、イベント属性値が一致する場合、2 つのイベントが相関関係にあります。両方のイベントの属性を一致させることで、2 つのイベントが確実に関連します。この場合、インターフェイス アドレスと物理インターフェイス(ifd)名が一致する必要があります。
RPD_KRT_IFDCHANGEエラーは、ルーティングプロトコルプロセス(rpd)がカーネルにインターフェイスの状態を変更するリクエストを送信し、そのリクエストが失敗した場合に発生します。RPD_RDISC_NOMULTIエラーは、インターフェイスがルーター検出用に設定されているが、インターフェイスが要求どおりIPマルチキャスト操作をサポートしていない場合に発生します。
この例では、 rpd_rdisc_nomulti.interface-name は so-0/0/0.0、 rpd_krt_ifdchange.ifd-index は so-0/0/0 となります。
[edit event-options]
policy 1 {
events rpd_rdisc_nomulti;
within 500 events rpd_krt_ifdchange;
attributes-match {
rpd_rdisc_nomulti.interface-address equals rpd_krt_ifdchange.address;
rpd_rdisc_nomulti.interface-name starts-with rpd_krt_ifdchange.ifd-index;
}
then {
... actions ...
}
}