運用の基本／ PolicyとCondition

アラート設計のベストプラクティス

NinjaOneでアラート疲れを起こさない設計の判断基準を説明します。重要度を3段階に絞る考え方、通知するものとしないものの切り分け、用途別のしきい値の目安、見直しのサイクルを解説します。

どの検知を通知し、どれを通知しないかを設計します。技術的な設定手順ではなく、運用が破綻しないための判断基準を扱います。本ガイドで最も実務に影響する内容です。

アラート疲れが起きる原因

導入から数カ月経つと、多くの組織で同じ状態になります。アラートが多すぎて誰も読まなくなり、本当の障害を見逃すようになります。

原因は3つあります。

いずれも設定の問題であり、運用の努力では解決しません。アラートが多いことを「監視が充実している」と考えないでください。読まれないアラートは、監視していないのと同じです。

重要度の区分は3つで十分です。それ以上に分けると、区分の判断自体が曖昧になります。

重要なのは「記録のみ」の区分を作ることです。監視はするが通知はしない項目を明確に持つことで、通知の総量を抑えられます。

判断の基準は1つです。受け取った人が、その時点で行動できるかどうか。

「クライアント端末1台のOffline」を通知にすると、毎日大量の通知が飛びます。ただし「同じ端末が7日以上Offline」なら要対応です。時間の条件を加えることで、意味のある通知になります。

初期値をそのまま使わないでください。用途によって適切な値は異なります。

監視項目	クライアント端末	一般サーバー	バッチ処理サーバー
CPU使用率	90%が30分継続	85%が15分継続	監視しないか、95%が2時間継続
メモリー使用率	90%が30分継続	85%が15分継続	用途に応じて調整
ディスク空き容量	10%未満	15%未満	20%未満
Offlineの継続	7日	15分	15分

これは出発点です。1カ月運用して、常に検知されている項目があれば実態に合っていません。しきい値を上げるか、監視対象から外してください。

ディスク容量は割合ではなく絶対値で判定した方がいい場合があります。2TBのディスクの10%は200GBあり、逼迫とは言えません。

一時的に条件が成立し、その後自然に解消する事象があります。これに通知を付けると、対応する前に解決している状態になります。

対処は2つです。

一時的な変動で通知が飛ぶ設定は、真っ先に見直すべき対象です。

設定して終わりにせず、定期的に見直してください。

【運用のポイント】月間の通知件数を記録してください。数字で見ないと、増えていることに気付けません。1人が1日に処理できる通知は現実的に10件程度です。それを超えているなら、設定を見直す時期です。

新規に設計する場合、次の順で進めてください。

2番目で答えが出ない項目は、通知にしないでください。対応方法が決まっていない通知は、必ず放置されます。