通常、各アクティブ・ルールには、Active Correlation Technology エンジン内で 実行中の 1 つのルール・インスタンス (またはコピー) が存在します。ただし、 多くの場合異なるリソースのグループに関連している異なるイベントのグループに、 同じルールが必要な場合があります。グループ化キーは、選択されたイベントを、 グループとして固有の処理を行う目的で別々のグループに分離するために使用できる、 1 つ以上のイベント属性またはイベント属性の一部です。<groupingKey> エレメントは、 ルールに対してグループ化キーを定義します。<groupingKey> エレメントの目的は、 ルールに対して、(グループ化キーを構成するイベント属性の値によって 定義されているように) 共通の特性を共有するイベントの各グループについて、 別個のルール・インスタンス (または自身のコピー) を作成するよう指示することです。
以下の 2 つのシナリオで、グループ化キーの重要性について 説明します。
このシーケンス・ルールがグループ化キー なしで定義されており、コンピューター A から DB2down イベントが受信された場合、 いずれかのコンピューターから DB2up イベントが受信されるとシーケンスは完了しますが、 これにより意図した結果は得られません。しかし、グループ化キーが hostname 属性として定義されていた場合、ルールの固有のコピー (またはインスタンス) が、 選択されたイベントの hostname 属性の各固有値に対して 作成されます。Active Correlation Technology エンジンは、各イベントを、正しいルール・ インスタンス (そのイベントの hostname 値に対するルール・インスタンス) に送信します。 このため、コンピューター A から DB2down イベントを受信すると、Active Correlation Technology エンジンは、コンピューター A のルール・インスタンスを作成します。 コンピューター B から DB2down イベントを受信すると、Active Correlation Technology エンジンは、 コンピューター B に対して 2 番目のルール・インスタンスを作成します。コンピューター B から DB2up イベントを受信すると、Active Correlation Technology エンジンは、そのイベントを 2 番目のルール・インスタンス内で処理します。シーケンスは完了し、 コンピューター B からの DB2down イベントおよび DB2up イベントが正しく相関されているため、オペレーターに アラートが出されます。
グループ化キーをユーザー ID として 定義することもできます。その場合、各固有ユーザー ID に対して新規のルール・インスタンスが 作成されます。各ユーザーのログイン試行は、固有のしきい値ルール・インスタンス内で 追跡され、各インスタンスでは、そのユーザーによるログイン試行回数を個別にカウントします。 5 分間で不正ログイン試行が 10 回を超えるユーザー ID があれば、 オペレーターは警告を受け取ります。
ルールに対して指定されたすべてのイベント・タイプで同じ属性が 指定されている場合、グループ化キーを定義するための最も単純かつ一般的な方法として、 <attributeName> エレメントを使用します。
<groupingKey> には、以下の属性があります。
名前 | 説明 | データ・タイプ | 必須? |
---|---|---|---|
missingAttributeHandling | 以下の条件のいずれかに該当する場合に、ルールが実行する
必要のあるアクションを定義します。
missingAttributeHandling 属性の有効値は以下のとおりです。
|
xsd:string | いいえ |
<groupingKey> には、以下のエレメントが 含まれます。
エレメント | 必須/オプション |
---|---|
<attributeAlias> | これらのエレメントのうち 1 つは指定する必要があります。これらのエレメントを複数コーディングするかどうかはオプションです。 3 つすべてのエレメントを複数回指定することができます。これらのエレメントは、任意の順序でコーディングできます。 |
<attributeName> | |
<computedValue> |