新しいシステムの監視設計を任されたとき、まず迷うのがこれだと思います。
どこまで監視項目を入れるべきか。
多すぎれば、アラートが鳴りすぎて誰も見なくなる。少なすぎれば、障害に気づけない。
正直に告白します。私は若いころ、とにかく全部入れる派でした。
「監視項目は多いほど安心」と思っていたんです。CPU、メモリ、ディスク、プロセス、ログ、サービス——思いつく限り設定しました。
結果どうなったか。毎日大量のアラートが飛んできて、誰も見なくなりました。
本当に重要なアラートが、ノイズに埋もれて見過ごされる。これでは監視している意味がありません。
今回は、19年やってきて固まった「監視設計の判断基準」を書きます。
監視設計で最初に決めるべきこと
項目を並べる前に、決めておくべきことがあります。
そのアラートが鳴ったとき、誰が、何をするのか。
これに答えられない監視項目は、入れるべきではありません。
私が設計するときに必ず自問するのが、この3つです。
- 鳴ったら、人が動く必要があるか
- 動くとして、何をすればいいかが決まっているか
- それは、今この瞬間にやるべきことか
3つすべてにイエスと答えられるものだけが、アラートにする価値があります。
「一応入れておこう」で追加した項目が、後々ノイズになります。ここを最初に決めておくかどうかで、運用の負荷がまったく変わります。
監視は3層で考える
私は監視項目を、3つの層に分けて考えています。
第1層：サービスが提供できているか
利用者から見て、システムが使える状態かどうか。
- HTTP応答（ステータスコード、レスポンスタイム）
- ログイン処理が通るか
- 主要な業務機能が動くか
これが最上位です。 極端な話、CPUが90%でもサービスが正常に提供できているなら、緊急ではありません。
第2層：構成要素が動いているか
サービスを支えるプロセスやサービスの死活。
- サーバーの死活（Ping、SSH/RDP接続）
- 各サービス・プロセスの起動状態
- データベース接続
- 連携先との疎通
第3層：リソースに余裕があるか
将来的な障害の予兆。
- CPU、メモリ使用率
- ディスク使用率
- ネットワーク帯域
- コネクション数
この3層で、緊急度が変わります。
第1層が落ちていれば即対応。第2層は原因調査。第3層は計画的な対処——という切り分けができると、対応がぶれません。
最低限入れておく項目
「まず何から」と聞かれたら、この項目を挙げます。どの環境でも共通して必要になるものです。
サーバー・OS
- サーバーの死活監視
- CPU使用率（継続的な高負荷）
- メモリ使用率
- ディスク使用率（これは必須）
- 時刻同期のずれ
ディスク使用率は、絶対に入れてください。
ディスク枯渇は、静かに進行して、ある日突然すべてを止めます。ログが書けなくなり、DBが更新できなくなり、サービスが停止する。しかも復旧に時間がかかります。
そして、予兆が明確に出る数少ない障害です。監視していれば必ず防げます。
サービス・アプリケーション
- 主要サービス・プロセスの死活
- ポートの応答
- HTTP/HTTPSの応答（ステータスコード）
- 証明書の有効期限
証明書の有効期限も忘れずに。 期限切れは事前に必ずわかるのに、監視していないと当日まで気づきません。
バックアップ・ジョブ
- バックアップの成功/失敗
- 定期バッチの実行結果
「成功したか」だけでなく「実行されたか」も見る必要があります。ジョブ自体が起動していないケースがあるからです。
「入れない」判断をするとき
逆に、入れるかどうか迷ったときの考え方です。
鳴っても何もできない項目は入れない
たとえば、「一時的にCPUが80%を超えた」というアラート。
これが鳴って、担当者は何をするでしょうか。おそらく、状況を確認して「様子見」で終わります。
行動につながらないアラートは、ノイズです。
こういうものは、アラートではなくグラフで見るようにします。傾向として把握できれば十分で、都度鳴らす必要はありません。
対応できない時間帯に鳴らさない
夜間に無人運用しているシステムで、深夜にアラートを鳴らしても意味がありません。
アラートは、対応できる体制とセットです。
体制がないなら、翌朝まとめてレポートで確認する形にする。鳴らすだけ鳴らして誰も見ないのが、一番よくない状態です。
重複する項目は絞る
同じ障害で、複数のアラートが同時に鳴ることがあります。
サーバーが落ちたとき、死活監視、プロセス監視、HTTP監視、連携先の疎通監視——全部が一斉に鳴る。
1つの障害で10通のメールが来ると、状況把握が遅れます。
依存関係を設定して、上位の障害が発生したら下位のアラートを抑制する。この設定ができる監視ツールなら、必ず活用してください。
しきい値の決め方
「CPU 80%で警告」といったしきい値。ここも迷うポイントです。
私の考え方は、こうです。
1. まずは一般的な値で設定する
最初から最適値はわかりません。CPU 80%、メモリ 85%、ディスク 80%——一般的な値でスタートします。
2. 1〜2ヶ月運用して、実態に合わせる
実際に運用してみると、そのシステムの「普段の値」が見えてきます。
普段から常時70%で動いているシステムなら、80%のしきい値は低すぎる。逆に、普段20%のシステムが50%になったら、それは異常の兆候です。
しきい値は、システムごとの「普段」を基準に決める。 一般論より、実測値のほうが正確です。
3. 継続時間を条件に入れる
瞬間的なスパイクで鳴らさないよう、「5分間継続したら」といった条件を入れます。
これだけで、アラート数はかなり減ります。
監視設計は、一度で完成しない
最後に、一番伝えたいことを書きます。
監視設計は、作って終わりではありません。
システムは変化します。負荷も変わる、構成も変わる、業務も変わる。だから監視も、それに合わせて変えていく必要があります。
私がやっているのは、これです。
- 半年に一度、鳴っているアラートを棚卸しする
- 対応不要だったアラートは、しきい値を見直すか削除する
- 障害があったのに鳴らなかった項目は、追加を検討する
「鳴りすぎているアラート」と「鳴らなかった障害」。 この2つを見れば、監視設計の過不足がわかります。
最初から完璧を目指さなくていい。運用しながら育てていくものだと思っています。
まとめ
監視設計の判断基準をまとめます。
最初に決めること
そのアラートが鳴ったとき、誰が、何をするのか。
- 鳴ったら、人が動く必要があるか
- 何をすればいいかが決まっているか
- それは今すぐやるべきことか
3層で考える
- サービスが提供できているか — 最優先
- 構成要素が動いているか — 原因調査
- リソースに余裕があるか — 計画的な対処
最低限入れる項目
- サーバー死活、CPU、メモリ、ディスク使用率
- 主要サービス・プロセス、ポート、HTTP応答、証明書の有効期限
- バックアップとバッチの実行結果
入れない判断
- 鳴っても何もできない項目は入れない
- 対応できない時間帯に鳴らさない
- 重複する項目は依存関係で抑制する
しきい値の決め方
- 一般的な値でスタートし、実態に合わせて調整
- システムごとの「普段」を基準にする
- 継続時間を条件に入れる
監視は、多ければいいものではありません。
本当に必要なアラートが、確実に届く状態。 それが目指すところだと思っています。
もし今、アラートが鳴りすぎて困っているなら——まずは「鳴っても何もしていないアラート」を洗い出すところから始めてみてください。
コメント