複数のConditionを組み合わせて、より正確な検知を行う機能です。単独の条件では誤検知が多くなる場面で使います。
Compound Conditionsが必要になる場面
単独のConditionは「ある1つの状態」しか見られません。しかし実際の障害は、複数の状態が重なったときに起きることが多くあります。
| 単独の条件 | 誤検知しやすい理由 | 組み合わせる条件 |
|---|---|---|
| CPU使用率が高い | バッチ処理中は正常 | 特定のプロセスが動いていない |
| ディスク空き容量が少ない | 想定内の運用の場合がある | バックアップが失敗している |
| サービスが停止している | メンテナンス中の場合がある | 業務時間内である |
| メモリー使用率が高い | アプリの仕様の場合がある | スワップが発生している |
条件を重ねることで、本当に対応が必要な状態だけを検知できます。
条件の組み合わせ方
編集画面はConditions、Automations、Settings、Notificationsの4つに分かれます。
条件はConditionsで設定します。
Trigger whenで判定方法を選ぶ。+ Add conditionから条件を追加するTrigger whenには2つの選択肢があります。
| 選択肢 | 意味 |
|---|---|
all conditions are true | 全ての条件が成立したときに検知する |
any condition is true | いずれか1つが成立したときに検知する |
誤検知を減らす目的ならall conditions are trueを使います。複数の異常のどれかを検知したい場合はany condition is trueです。
+ Add conditionから条件を追加します。ソフトウェアの状態やCustom Fieldsの値も条件に使えるため、独自の判定基準を組み立てられます。
動作の設定
Settingsでは、判定の頻度と検知後の挙動を指定します。
Auto Reset、Run Every、Trigger uptimeで検知の挙動を調整する| 設定 | 内容 |
|---|---|
Auto ResetのAfter | 指定時間が経過したら検知状態を自動で解除する |
Auto ResetのWhen no longer met | 条件が成立しなくなったら自動で解除する |
Run Every | 条件を評価する間隔 |
Trigger uptime | 起動から指定時間が経過するまで検知しない |
Trigger uptimeは実務で効果の大きい設定です。再起動直後はサービスの起動が完了しておらず、リソースも一時的に高くなります。ここで検知させないことで、パッチ適用後の再起動のたびにアラートが飛ぶ状況を防げます。
Auto Resetの使い分けも重要です。When no longer metを選ぶと、状態が改善した時点で自動的に解除されます。人手で解除する運用にすると、対応済みの検知が残り続けて一覧が読めなくなります。
設定例
CPU使用率が高い状態が継続した場合
Trigger when: all conditions are true
条件1: CPU使用率が90%以上
条件2: 指定したバッチプロセスが動作していない
Settings:
Run Every: 5分
Trigger uptime: 10分
Auto Reset: When no longer met
バッチ処理中の高負荷を除外し、想定外の高負荷だけを検知します。
ディスク空き容量の低下とバックアップ失敗の複合
Trigger when: all conditions are true
条件1: Cドライブの空き容量が10%未満
条件2: 直近のバックアップが失敗している
Settings:
Auto Reset: When no longer met
どちらか一方なら計画的に対応できますが、両方が重なると復旧手段を失います。この組み合わせは優先度を上げて通知すべき事象です。
動作の確認
設定したら、意図どおりに動くかを確認してください。
- 検証用のデバイスで、条件が成立する状態を意図的に作る
- 検知が発生するか確認する
- 通知が届くか確認する
- 状態を戻し、自動で解除されるか確認する
4番目まで確認してください。検知はするが解除されない設定だと、一覧に古い検知が残り続けます。
【運用のポイント】 Compound Conditionsは便利ですが、条件が複雑になるほど「なぜ検知したのか」が分かりにくくなります。条件は2つか3つまでにとどめ、それ以上必要なら監視の設計自体を見直してください。