正常性ルールの条件

正常性ルールの条件を定めてメトリックの許容範囲を定義します。正常性ルールの条件により、[Warning] ステータスまたは [Critical] ステータスのメトリックレベルが設定されます。

条件は、選択されたベースラインに基づく 1 つ以上の静的または動的しきい値と、メトリックの現在値を比較するブール ステートメントで構成されます。条件が当てはまる場合、その正常性ルールの違反になります。複数のしきい値で条件を評価するルールは、構成により異なります。

静的しきい値は簡単です。静的しきい値とは、ビジネストランザクションの平均応答時間は 200 ms 以上かどうかなどです。平均応答時間が 200 ms より大きく、正常性ルールが違反している場合、条件は「true」と評価されます。

動的しきい値は、ロールアップ ベースライン トレンド パターンに基づいて構築されたベースラインとの関連のパーセンテージ、またはベースラインの標準偏差に基づいています。日次トレンドベースラインは、過去 30 日間の特定の時間帯の値をロールアップします。一方、週次トレンドベースラインは、過去 90 日間の特定の曜日について、特定の時間の値をロールアップします。ベースラインの詳細については、「動的ベースライン」を参照してください。

単一のメトリック値、または複数のメトリック値から構築された数式に基づいて、正常性ルールのしきい値を定義できます。

以下に、典型的な正常性ルールの条件をご紹介します。

• 平均応答時間の値がベースライン標準偏差の 3 倍となるデフォルトのベースラインより大きい場合。. .  
• 毎分のエラー数が 1000 より大きい場合。. .  
• フリーメモリの MB 数がデフォルトのベースラインの 2 倍より小さい場合。. .
• 過去 15 日間の Errors per Minute/Calls per Minuteの値が 0.2 より大きい場合。. .
  この例では単一の条件で 2 つのメトリックを組み合わせます。正常性ルールウィザードに埋め込まれている式ビルダーを使用して、相互依存の複数のメトリックからなる複雑な式に基づいた条件を作成できます。

• （応答平均時間 > ベースラインまたは 1 分あたりのエラー数 > ベースライン）AND（1 分あたりのコール数 > 定義されたしきい値）。. .
  次に、複数の条件を使用して正常性ルールを評価する例を示します。[CUSTOM] オプションを使用して、条件を評価するブール式を定義できます。

重大および警告の条件

条件は重大または警告に分類されます。 

重大条件は警告条件より前に評価されます。重大条件と警告条件が同じ正常性ルールで定義されていると、警告条件は重大条件が真でない場合のみに評価されます。

重大条件と警告条件の構成手順は同じですが、これら 2 つのタイプの条件は別パネルで構成します。重大条件の構成を警告条件にコピーしたら（逆もまた同様）、メトリックを調整して区別をつけます。たとえば、[Critical Condition] パネルで、次のルールに基づいた重大条件を作成できます。

• 平均応答時間が 1000 より大きい場合

次に、警告条件パネルからその条件をコピーして次のように編集します。

• 平均応答時間が 500 より大きい場合

パフォーマンスの変化に伴い、高い方のしきい値まで下がると正常性ルール違反は警告から重大にアップグレードされ、パフォーマンスが警告のしきい値まで上がると重大から警告にダウングレードされます。

正常性ルール違反イベント

メトリックレベルが許容範囲を超えると、条件に違反し、正常性ルール違反イベントが発生します。違反イベントの詳細が [Health Rule Violation] ウィンドウに表示されます。このウィンドウには、次の詳細情報が表示されます。

• 違反イベントの数
• 各違反イベントの概要
• 違反イベントに応答して開始されたアクションの詳細
• 各違反イベントのタイムライン

条件のトリガーを定義しても、単一の値がないため、正常性ルール違反イベントの概要にはメトリック値が表示されません。ただし、条件のトリガーを 1 つも定義しない場合は、正常性ルール違反イベントの概要にメトリック値が表示されます。

評価基準

正常性ルールに対して複数の条件を定義すると、定義した基準に基づいて評価されます。次のオプションを使用して、評価基準を定義できます。

• All：基準で定義されたすべての条件が「true」に評価されると、正常性ルールに違反します。
• Any：基準で定義されたいずれかの条件が「true」に評価されると、正常性ルールに違反します。
• Custom：複数の条件を持つブール式が「true」に評価されると、正常性ルールに違反します。

評価基準を設定する方法については、「正常性ルールの評価基準の構成」を参照してください。

次の表では例を使用し、基準に基づいて正常性ルールがどのように評価されるか、および違反と見なされるタイミングを説明します。

正常性ルールの設定	評価	例
単一の条件	条件は「true」と評価されます	「平均応答時間」と定義されたベースラインを比較する正常性ルール。
「ANY」の評価基準を持つ複数の条件	いずれかの正常性ルール条件が「true」に評価されます	ビジネストランザクションの正常性をモニタする正常性ルールは、次のパフォーマンスメトリックのいずれかを測定することができます。 平均応答時間または 1 分あたりのエラー数
「ALL」の評価基準を持つ複数の条件	すべての正常性ルール条件が「true」と評価されます	ビジネストランザクションの正常性をモニタする正常性ルールは、次のすべてのメトリックを測定します。 応答時間 アプリケーション負荷に関連付けられているベースライン値を超える平均応答時間。 システム上の 50 人の同時ユーザなどです。ポリシーは、応答時間のしきい値に達しても、負荷（1 分あたりのコール数）が高い場合にのみ、是正措置が開始されるように定義されています。 条件の最初の部分では応答時間を評価し、次の部分では負荷が高い場合にのみ、正常性ルールに違反していることを確認します。
「CUSTOM」の評価基準を持つ複数の条件	複数の条件を持つブール式は「true」と評価されます 条件は、AND および OR 演算子を使用した条件の有効な組み合わせが入力された場合にのみ評価されます。それ以外の場合、評価は失敗します。 ビジネスに重大な影響が生じる前にアラートが迅速にトリガーされるようにするために、正常性ルールではブール式のすべての条件は評価されません。正常性ルールでは最初の条件の評価を開始し、式を true または false として確定的にマークできるようになるまで、次の条件を評価し続けます。評価によって式が違反すると判断されるとすぐに、アラートがトリガーされます。	ビジネストランザクションの正常性をモニタする正常性ルールは、次の条件に基づいてパフォーマンスを測定します。 （ベースラインを超える平均応答時間、またはベースラインを超える 1 分あたりのエラー数） および （しきい値を超える 1 分あたりのコール数）

永続的しきい値

メトリック パフォーマンス データの一時的な上昇は偽のアラートの大きな原因です。永続的しきい値を使用すると、正常性ルールの感度レベルを定義し、偽のアラートの数を減らすことができます。評価タイムフレームでメトリック パフォーマンス データが定義されたしきい値を超える回数を定義し、違反を作成した後に、アラートをトリガーできます。

30 分以下の評価タイムフレームを定義している場合にのみ、条件の永続的しきい値を定義できます。

たとえば、CPU 使用率をモニターする場合、しきい値の違反（以下の図のセクション A）が 1 つのときは報告しないとします。ただし、評価期間中にしきい値の違反（図のセクション B）が複数回発生した場合は、アラートを生成します。 

アラート感度の調整

Deployment Support

アラート感度の調整（AST）機能は、ビジネストランザクション、サービスエンドポイント、またはリモートサービスをモニタする正常性ルールを作成した場合にのみ有効になります。

アラートを見逃さないようにしたり、誤ったアラートを受信しないようにするには、条件を適切に設定することが重要です。AST を使用すると、条件を構成するときにメトリックとベースラインの履歴データを表示できます。このデータは、定義する構成の影響を可視化し、構成を微調整するのに役立ちます。 

メトリックデータ、しきい値、標準偏差、およびベースラインのグラフィカル表示を確認できます。グラフィカルビューは、構成を更新するとすぐに更新されます。グラフィカルビューを変更して詳細を表示することもできます。詳細を表示するには、次のようにします。

• データキャプチャの期間を 1 日または 3 日に増やします。 
  

  

  選択した期間のデータが使用できない場合は、使用可能なデータのみが表示されます。

• グラフの時間範囲を調整し、メトリックデータの詳細を表示します。 
• メトリックデータにカーソルを合わせると、メトリックとベースラインの値がいつでも表示されます。

表示されたデータを分析し、必要に応じて構成を調整することができます。条件の微調整の詳細については、「BT 正常性ルールの作成とメトリック評価の微調整」を参照してください。

たとえば、正常性ルール条件をモニタするメトリックとして [Average CPU Used (ms)]（1）を選択した場合は、8 時間（2）の期間にわたる過去のメトリックデータを表示できます。メトリックデータのグラフィカル表示には、ベースライン（3）とベースライン標準偏差（4）が示されます。このデータに基づいて、条件の評価を微調整できます。これにより、誤ったアラートを回避し、正常性ルールが定義した条件に違反した場合にのみアラートを受信できます。

移動平均

永続的しきい値を定義して条件を評価する場合、毎分のメトリックデータがベースラインと比較され、AST グラフにプロットされます。ただし、永続的しきい値を定義しない場合は、選択したメトリックの「移動平均」が次のようにプロットされます。

1. [Use data from last] の値「X」に応じて、「X」分のメトリックデータが考慮されます。
2. 「X+1」分の時点で、過去の「X」分の平均が計算され、グラフの最初のポイントとして示されます。
3. 同様に、次の「X」分の平均が計算され、残りの時間範囲のグラフにポイントが示されます。

移動平均を使用する理由

永続的しきい値が使用されている場合を除き、正常性ルールはメトリックの移動平均をしきい値またはベースラインと比較します。したがって、グラフ内の移動平均を表すのが適切です。詳細については、「正常性ルールの作成とメトリック評価の微調整」を参照してください。

データが報告されない場合の条件の評価方法

[Evaluate to true on no data] オプションは、条件をベースとした任意のメトリックがデータを返さない場合の条件の評価を制御します。データが返されない場合、条件は「unknown」（デフォルト）と評価されます。正常性ルールが true に評価されるすべての条件に基づいている場合、データが返されないと、正常性ルールがアクションをトリガーするかどうかに影響を与える可能性があります。

正常性ルールの評価のタイムフレームを定義すると、各データポイントの参照データが収集されます。タイムフレームで設定されたメトリックがデータの報告に失敗した場合、正常性ルール条件は次のように評価されます。

可用性メトリックの [Evaluate to true on no data ] が無効になっていることを確認してください。

カスタムブール式

条件は、異なるメトリックを評価する複数のステートメントで構成されます。アプリケーションのパフォーマンスメトリックを評価するために、1 つの条件または複数の条件を定義できます。複数の条件を定義する場合は、ブール式を使用して評価基準を定義することができます。

ブール式を使用する利点は次のとおりです。

• さまざまなパフォーマンスメトリックをモニタするために、複数の正常性ルールを作成する必要性を軽減します。ブール式を使用すると、1 回の操作で複数の条件の複雑な基準を評価することができます。
• ブール式が適切に調整されるため、誤検出のアラートが減少します。
• 単純な条件名を使用する複雑な評価基準を利用して、正常性ルールを簡単に作成および維持できます。条件に A、B、C などという名前が付けられます。

• AND と OR 演算子を使用して、非常に複雑な式を定義できます。ブール式では、最大 8 つの演算子を使用できます。

評価範囲

正常性ルールの評価スコープは、正常性ルールに違反したと見なされるために必要な、影響を受けたエンティティで条件に違反しているノードの数を定義するものです。

評価スコープは、影響を受けたエンティティがティアレベルで定義されるビジネストランザクション タイプの正常性ルール、およびノードの正常性タイプの正常性ルールにのみ適用されます。

たとえば、どのノードにも認められない重大な条件を設定したり、ティア内の 50% 以上のノードに当てはまる場合のみ違反とみなす条件を設定したりできます。 

この評価スコープのオプションは、次のとおりです。

• ティアの平均: 個々のノードではなくティアの平均で評価を実行。
• いずれかのノード: いずれかのノードがしきい値を超えた場合、ルールに違反。
• ノードの割合: ノードのx%がしきい値を超えた場合、ルールに違反。
• ノードの数:  xのノードがしきい値を超えた場合、ルールに違反。