4 トリガーのベストプラクティス
トリガーは強力なツールですが、望ましくないアラートノイズを発生させることもあります。より多くの本当のシグナルを見て、ノイズを減らすために、以下のヒントに従ってください。
-
トリガーの感度を下げる。最新値（高すぎる/低すぎる）でアラートを出すのではなく、
avg、min、maxなどの関数を使って、長期間の平均値を分析します。 -
ランダムなスパイクやドロップでアラートを出したくない場合は、トリガーで
percentile関数（95%または5%に設定）を使用することを検討してください。 -
ヒステリシスを使用して、トリガーフラッピング（トリガー状態の頻繁な変化（OK ↔ 問題））を回避します。リカバリー式（問題解決のための別の条件）を追加することで、問題状態の連続性を定義できます。
-
トリガーの依存関係を使用して、根本原因に関連しないアラートを回避します。
-
トリガーの深刻度を使用して、より深刻な問題のみでアラートを出します。
-
メンテナンスウィンドウを定義します。
ヒステリシス
単純な閾値ではなく、障害状態と復旧状態の間に間隔が必要な場合があります。 たとえば、サーバールームの温度が20°Cを超えたときに障害を報告し、温度が15°C未満になるまで障害状態を維持したい場合、単純なトリガー閾値を20°Cに設定するだけでは不十分です。
その代わりに、まず障害イベント用のトリガー式（温度が20°Cを超えた場合）を定義する必要があります。 次に、追加の復旧条件（温度が15°C未満）を定義する必要があります。 これは、トリガーを設定する際に復旧式を定義することで実現します。
この場合、障害の復旧は2段階で行われます。
- まず、障害式（温度が20°Cを超えた場合）がFALSEと評価される必要があります
- 次に、復旧式（温度が15°C未満）がTRUEと評価される必要があります
復旧式は、障害イベントが解決された後にのみ評価されます。障害式がまだTRUEの場合、復旧式がTRUEであるだけでは障害は解決されません！
例
サーバールームの温度が高すぎます。
障害の式:
last(/server/temp)>20復旧の式:
last(/server/temp)<=15復旧の式で{TRIGGER.VALUE}マクロを使用しても非効率的です。なぜなら、この式はトリガーが「障害」状態のときだけ評価されるためです。そのため、式を評価している間、{TRIGGER.VALUE}は常に「1」（「障害」状態を示す）に解決されます。