正常性ルールの条件

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

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

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

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

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

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

平均応答時間の値がベースライン標準偏差の 3 倍となるデフォルトのベースラインより大きい場合。. .
毎分のエラー数が 1000 より大きい場合。. .
フリーメモリの MB 数がデフォルトのベースラインの 2 倍より小さい場合。. .
過去 15 日間の 1 分あたりのエラー数 ÷ 1 分あたりのコール数の値が 0.2 より大きい場合。. この例では単一の条件で 2 つのメトリックを組み合わせます。正常性ルールウィザードに埋め込まれている式ビルダーを使用して、相互依存の複数のメトリックからなる複雑な式に基づいた条件を作成できます。
（応答平均時間 > ベースライン OR 1 分あたりのエラー数 > ベースライン）AND（1 分あたりのコール数 > 定義されたしきい値）の場合。. 次に、複数の条件を使用して正常性ルールを評価する例を示します。[CUSTOM] オプションを使用して、条件を評価するブール式を定義できます。

重大および警告の条件

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

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

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

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

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

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

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

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

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

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

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

評価基準

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

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

評価基準を設定する方法については、「条件評価基準」を参照してください。

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


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

Persistence Thresholds

Temporary spikes in metric performance data is a major cause of false alerts. Persistence thresholds allow you to define a sensitivity level for a health rule and thereby reduce the number of false alerts. You can define the number of times metric performance data should exceed the defined threshold during the evaluation time frame to constitute a violation and subsequently trigger an alert.

注: You can define a persistence threshold for a condition only if you have defined an

evaluation time frame

of 30 minutes or less.

For example, when monitoring the CPU utilization, you would not want to be reported of a single violation (section A in thefigure below following figure) of the threshold. However, if the violation of threshold continues to occur multiple times (section B in the following figure) during the evaluation time period, you would want to be alerted.

アラート感度の調整

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

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

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

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

注: 選択した期間のデータが使用できない場合は、使用可能なデータのみが表示されます。
グラフの時間範囲を調整し、メトリックデータの詳細を表示します。
メトリックデータにカーソルを合わせると、メトリックとベースラインの値がいつでも表示されます。

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

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

アラート感度の調整

移動平均

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

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

移動平均を使用する理由

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

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

[Evaluate to true on no data] オプションは、条件をベースとした任意のメトリックがデータを返さない場合の条件の評価を制御します。

データがないシナリオでは、次のいずれかのオプションを選択できます。

[Critical] または [Warning]：正常性ルールは、このデータが利用できない状態を重大または警告状態とみなし、正常性ルールのステータスがそれぞれ赤色または黄色で表示されます。
Unknown：正常性ルールは、データが利用できない状態を不明と見なし、正常性ステータスが灰色で表示されます。データが返されない場合は、このオプションがデフォルト値になります。
Healthy：正常性ルールは、データが利用できない状態を正常と見なし、正常性ルールのステータスが緑色で表示されます。

正常性ルールが true に評価されるすべての条件に基づいている場合、データが返されないと、正常性ルールがアクションをトリガーするかどうかに影響を与える可能性があります。

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


データがない場合は true と評価されます	過去 y 分で違反が x 回発生した場合にのみトリガーされます。	条件の評価
重大、警告、正常、または不明	ディセーブル	この条件は、評価のタイムフレーム（[Use data from last <y> min(s)]）内の各データポイントに対して評価されます。この場合、コントローラは最後の <y> 分のメトリック値の平均をチェックします。条件を満たしている場合は、アラートがトリガーされます。たとえば、1 分あたりのコール数の値が 6 を超え、評価のタイムフレームが最後の 5 分間になった場合にアラートをトリガーする必要があるという条件を作成します。シナリオ 1 1分目の `Calls Per Minute` の値が 14、2 分目の `Calls Per Minute` の値が 9、3 分目の `Calls Per Minute` の値が 7、4 分目の `Calls Per Minute` の値が不明（メトリックでのデータの報告なし）、 5 分目の `Calls Per Minute` 値が 5 です。この場合、過去 5 分間のメトリック値の平均は 7 です。そのため、条件が満たされ、アラートがトリガーされます。シナリオ 2 設定されたメトリックが評価期間中に満たされていないデータポイントまたは条件を報告できなかった場合、エンティティの正常性ステータスは、[Evaluate to true on no data] オプションに指定した内容に応じて、重大、警告、正常、または不明として表示されます。
重大、警告、正常、または不明	有効	この条件は、評価のタイムフレーム（Use data from last <y> min(s)）の各データポイントに対して評価されます。この場合、コントローラは最後の <y> 分にわたって、1 分ごとにメトリック値を確認し、違反が最後の y 分間に少なくとも x 回発生した場合、アラートがトリガーされます。そうでない場合は、false を返します。たとえば、 [Calls Per Minute > 6] の値が 6 を超えた場合にアラートがトリガーされ、この条件が最後の 5 分間に少なくとも 3 回発生する必要があるという条件を作成します。この場合、コントローラは過去 5 分間の各分について [Calls Per Minute] の値をチェックします。シナリオ 1 1 分目分の `Calls Per Minute` の値が 7、2 分目の `Calls Per Minute` の値が 9、3 分目の `Calls Per Minute` の値が 8、4 分目の `Calls Per Minute` の値が不明（メトリックでのデータの報告なし）、5 分目の `Calls Per Minute` 値が 3 です。このシナリオでは、少なくとも 3 回、[Calls Per Minute] の値が 6 を超えており、条件を満たしています。そのため、アラートがトリガーされます。シナリオ 2 1 分目の `Calls Per Minute` の値が 7、2 分目、3 分目、4 分目の `Calls Per Minute` の値が不明（メトリックでのデータの報告なし）、5 分目の `Calls Per Minute` の値が 8 です。この場合、 [Calls Per Minute] 値が 6 を上回るのは 2 回のみであり、このシナリオは条件を満たしていません。したがって、エンティティの全体的な正常性ステータスは、[Evaluate to true on no data] オプションに選択した内容に応じて、重大、警告、正常、または不明として表示されます。

カスタムブール式

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

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

さまざまな評価指標をモニターするために、複数の正常性ルールを作成する必要がなくなります。ブール式を使用すると、1 回の操作で複数の条件の複雑な基準を評価することができます。
ブール式が適切に調整されるため、誤検出のアラートが減少します。
単純な条件名を使用する複雑な評価基準を利用して、正常性ルールを簡単に作成および維持できます。条件に、A、B、C などの名前が付けられます。
AND OR の使用を許可する

評価範囲

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

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

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

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

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