正常性ルールの条件
正常性ルールの条件を定めてメトリックの許容範囲を定義します。正常性ルールの条件により、[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] ウィンドウに表示されます。このウィンドウには、次の詳細情報が表示されます。
- 違反イベントの数
- 各違反イベントの概要
- 違反イベントに応答して開始されたアクションの詳細
- 各違反イベントのタイムライン
評価基準
正常性ルールに対して複数の条件を定義すると、定義した基準に基づいて評価されます。次のオプションを使用して、評価基準を定義できます。
- All：基準で定義されたすべての条件が「true」に評価されると、正常性ルールに違反します。
- Any：基準で定義されたいずれかの条件が「true」に評価されると、正常性ルールに違反します。
- Custom：複数の条件を持つブール式が「true」に評価されると、正常性ルールに違反します。
評価基準を設定する方法については、「条件評価基準」を参照してください。
次の表では例を使用し、基準に基づいて正常性ルールがどのように評価されるか、および違反と見なされるタイミングを説明します。
| 正常性ルールの設定 | 評価 | 例 |
|---|---|---|
| 単一の条件 |
条件は「true」と評価されます | 「平均応答時間」と定義されたベースラインを比較する正常性ルール。 |
| 「ANY」の評価基準を持つ複数の条件 | いずれかの正常性ルール条件が「true」に評価されます |
ビジネストランザクションの正常性をモニタする正常性ルールは、次のパフォーマンスメトリックのいずれかを測定することができます。
|
| 「ALL」の評価基準を持つ複数の条件 |
すべての正常性ルール条件が「true」と評価されます |
ビジネストランザクションの正常性をモニタする正常性ルールは、次のすべてのメトリックを測定します。
システム上の 50 人の同時ユーザなどです。 応答時間のしきい値に達していても、負荷（1 分あたりのコール数）が高い場合にのみ、修復アクションが開始されるようにポリシーが定義されます。条件の最初の部分では応答時間を評価し、次の部分では負荷が十分な場合にのみ正常性ルール違反になるようにします。 |
| 「CUSTOM」の評価基準を持つ複数の条件 |
複数の条件を持つブール式は「true」と評価されます 注: 条件は、 および 演算子を使用した条件の有効な組み合わせが入力された場合にのみ評価されます。それ以外の場合、評価は失敗します。
ビジネスに重大な影響が生じる前にアラートが迅速にトリガーされるようにするために、正常性ルールではブール式のすべての条件は評価されません。正常性ルールでは最初の条件の評価を開始し、式を true または false として確定的にマークできるようになるまで、次の条件を評価し続けます。評価によって式が違反すると判断されるとすぐに、アラートがトリガーされます。 |
ビジネストランザクションの正常性をモニタする正常性ルールは、次の条件に基づいてパフォーマンスを測定します。
および
|
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.
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.
データが報告されない場合の条件の評価方法
[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分目の シナリオ 2 設定されたメトリックが評価期間中に満たされていないデータポイントまたは条件を報告できなかった場合、エンティティの正常性ステータスは 、[Evaluate to true on no data] オプションに指定した内容に応じて、重大、警告、正常、または不明として表示されます。 |
| 重大、警告、正常、または不明 | 有効 | この条件は、評価のタイムフレーム（Use data from last <y> min(s)）の各データポイントに対して評価されます。 この場合、コントローラは最後の <y> 分にわたって、1 分ごとにメトリック値を確認し、違反が最後の y 分間に少なくとも x 回発生した場合、アラートがトリガーされます。そうでない場合は、false を返します。 たとえば、 [Calls Per Minute > 6] シナリオ 1 1 分目分の シナリオ 2 1 分目の |
カスタムブール式
条件は、異なるメトリックを評価する複数のステートメントで構成されます。アプリケーションのパフォーマンスメトリックを評価するために、1 つの条件または複数の条件を定義できます。複数の条件を定義する場合は、ブール式を使用して評価基準を定義することができます。
ブール式を使用する利点は次のとおりです。
- さまざまな評価指標をモニターするために、複数の正常性ルールを作成する必要がなくなります。ブール式を使用すると、1 回の操作で複数の条件の複雑な基準を評価することができます。
- ブール式が適切に調整されるため、誤検出のアラートが減少します。
- 単純な条件名を使用する複雑な評価基準を利用して、正常性ルールを簡単に作成および維持できます。条件に、A、B、C などの名前が付けられます。
-
AND OR の使用を許可する
評価範囲
正常性ルールの評価スコープは、正常性ルールに違反したと見なされるために必要な、影響を受けたエンティティで条件に違反しているノードの数を定義するものです。
評価スコープは、影響を受けたエンティティがティアレベルで定義されるビジネストランザクション タイプの正常性ルール、およびノードの正常性タイプの正常性ルールにのみ適用されます。
たとえば、どのノードにも認められない重大な条件を設定したり、ティア内の 50% 以上のノードに当てはまる場合のみ違反とみなす条件を設定したりできます。
この評価スコープのオプションは、次のとおりです。
- ティアの平均：個々のノードではなくティアの平均で評価を実行。
- いずれかのノード：いずれかのノードがしきい値を超えた場合、ルールに違反。
- ノードの割合：ノードの x% がしきい値を超えた場合、ルールに違反。
- ノードの数：x のノードがしきい値を超えた場合、ルールに違反。