トリガーのベストプラクティス

トリガーは強力なツールですが、不要なアラートノイズを発生させることもあります。より実際のシグナルを増やし、ノイズを減らすには、次のヒントを参考にしてください。

1. トリガーの感度を下げます。最新値（高すぎる/低すぎる）でアラートを出す代わりに、avg、min、max などの関数を使って、長期間の平均を分析します。

2. ランダムなスパイクや急落によるアラートを避けたい場合は、トリガーで percentile 関数を使用することを検討してください（95% または 5% に設定します）。

3. トリガーのフラッピングを避けるために ヒステリシス を使用します。フラッピングとは、トリガー状態が頻繁に変化すること（OK ↔ 障害）です。回復式（障害解決のための別条件）を追加することで、障害状態の継続条件を定義できます。

4. 根本原因に関連しないアラートを避けるために、トリガーの依存関係を使用します。

5. より深刻な障害のみをアラートするために、トリガーの深刻度を使用します。

6. メンテナンス期間を定義します。

ヒステリシス

単純な閾値ではなく、障害状態と復旧状態の間に間隔が必要な場合があります。 たとえば、サーバールームの温度が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