監視アラートの鳴らしすぎを減らす｜閾値の決め方と運用のコツ
スマホやチャットに、また監視アラートが届く。 朝起きたら通知が30件。中身を開くと、ほとんどが「一瞬だけCPUが上がった」「すぐ戻ったエラー」——そんな経験、ありませんか。
最初はちゃんと一件ずつ見ていたのに、鳴りすぎるうちに、だんだん通知をまとめて既読にするようになる。 そして、本当に困る障害のアラートまで、その他大勢に紛れて見落としてしまう。これは担当者がだらしないからではなく、閾値が現場に合っていないときに必ず起きることです。
この記事では、アラートの鳴らしすぎを減らし、「これが鳴ったら本当に動く」だけを残すための閾値の決め方と、運用しながら育てていくコツを、一人運用の目線で一緒に整理します。全部を一度に直さなくて大丈夫です。
結論：アラートは「人が今すぐ動く必要があるか」を基準に絞ります。やることは3つ。①鳴っても何もしていないアラートを止める（または通知先を下げる）、②残すアラートは「症状（ユーザーが困ること）」で閾値を決める、③一瞬の上振れで鳴らないよう、継続時間の条件をつける。この順で、まず「鳴っても無視しているアラート」を1つ止めるところから始めます。
閾値の具体的な数字（CPU 80%、ディスク 90% など）は、サーバーの役割や余裕で正解が変わります。 この記事の考え方を出発点に、自分の環境の「いつもの値」に合わせて調整してください。
なぜ「鳴らしすぎ」が危ないのか
アラートが多いこと自体は、一見「しっかり監視できている」ように見えます。 でも、鳴らしすぎには静かなリスクがあります。
- 本当の障害が埋もれる：どうでもいいアラートに紛れて、本当に動くべき1件を見落とす。
- 通知に慣れてしまう：「また鳴ってる」が当たり前になり、反射的に既読にする癖がつく（アラート疲れ）。
- 夜間・休日にすり減る：一人運用だと、深夜の「すぐ戻った」通知でも一度起こされる。それが続くと判断力も気力も削られます。
監視の目的は「鳴らすこと」ではなく、「人が動くべきときに、ちゃんと気づけること」です。 鳴る数が多いほど良いわけではなく、むしろ「動かないアラート」は監視の精度を下げます。まずはこの前提を持っておくと、止める判断がしやすくなります。
閾値を決める前に：その通知は「動く」アラートか
閾値の数字をいじる前に、まず通知の種類を仕分けします。すべてのアラートを、次の3つに分けてみてください。
- 今すぐ動く（通知する）：放置するとユーザーに影響が出る、または間もなく出る。例：サイトが落ちている、ディスクがあと少しで満杯、証明書がもうすぐ切れる。
- あとで見る（通知しない）：気にはなるが、その場で起きて対応するほどではない。例：一時的にCPUが上がった、深夜バッチが少し長引いた。これはダッシュボードやログで後から見れば十分。
- 止める：もう意味がない、誰も対応していないアラート。例：とっくに対処済みの古い監視、毎回鳴って毎回無視しているもの。
ポイントは、「鳴ったら人が何かするか？」で線を引くことです。 鳴っても毎回「あ、はいはい」で終わるなら、それは通知である必要がありません。チャット通知やメールから外し、ダッシュボードで見る側に回しましょう。
この仕分けだけで、通知の数はかなり減ります。閾値の微調整は、その後で十分です。
残すアラートの閾値の決め方（4つの考え方）
「今すぐ動く」に分類したアラートだけ、閾値を丁寧に決めます。次の4つを意識すると、鳴らしすぎにくくなります。
① 「原因」ではなく「症状」で鳴らす
CPU使用率やメモリ単体より、ユーザーが実際に困ることで鳴らすほうが、無駄鳴りが減ります。
- 弱い例：「CPUが80%を超えた」→ 一時的に超えても問題ないことが多く、鳴りすぎる。
- 強い例：「応答時間が普段の数倍に遅い」「エラー率が一定を超えた」「サイトが応答しない」→ これは本当にユーザーが困っている合図。
CPUやメモリは、症状アラートの原因を調べるための材料としてダッシュボードで見れば十分なことが多いです。「鳴らす」のは症状側に寄せます。
ただし、一人運用の小規模な現場では、応答時間やエラー率を取れる監視がそもそも入っていないこともよくあります。その場合は無理に揃えなくて大丈夫です。まずはCPUなどの原因監視しかなくても、後述の「継続時間の条件」と「通知先を分ける」だけで、鳴らしすぎはかなり減ります。 症状監視は、余裕ができたときに足せば十分です。
② 「一瞬」で鳴らさない（継続時間の条件をつける）
多くの無駄鳴りは、ほんの一瞬の上振れが原因です。閾値に「◯分続いたら」という条件を足すだけで、ぐっと減ります。
- 「CPUが90%を5分間続けて超えたら」
- 「エラー率が高い状態が数分継続したら」
スパイク（瞬間的な跳ね）は自然に戻ることが多いので、「超えた瞬間」ではなく「超え続けている」で鳴らすのがコツです。
③ 「手遅れになる前」に余裕を持って鳴らす
逆に、じわじわ進む問題は、限界ぴったりで鳴らすと手遅れになります。対応する時間を逆算して閾値を決めます。
- ディスク使用率は「100%」ではなく、増え方を見て対応が間に合う水準（例：85〜90%）で一度鳴らす。
- 証明書の期限は「切れた日」ではなく、更新作業に必要な日数の余裕を持って（例：残り30日・14日）鳴らす。
「気づいてから動ける時間があるか」で閾値を選ぶ、と覚えておくと決めやすいです。
④ 重要度で「通知先」を分ける
すべてを同じチャンネルに流すと、軽いものに重いものが埋もれます。最低でも2段階に分けます。
- すぐ対応（critical）：電話・即時通知など、夜中でも気づく経路。サイト停止やデータ消失の危険など、本当に起きてほしくないものだけ。
- 見ておく（warning）：通常のチャットや日中に見る一覧。すぐではないが放置はしたくないもの。
一人運用では特に、「夜に自分を起こしていいアラートはどれか」をはっきりさせておくことが、自分を守ることにつながります。
鳴らしすぎを減らす運用のコツ
閾値は「一度決めて終わり」ではなく、運用しながら育てます。負担にならない範囲で、次を回します。
- 定期的に棚卸しする：月1回など、「先月鳴ったアラート」を眺め、毎回無視していたものを止める・閾値を上げる。
- 似たアラートはまとめる：同じ原因で何十件も鳴るなら、まとめて1通知にする（グルーピング）。同じ障害で通知が連打されるのを防ぎます。
- 収まっている間は黙らせる（メンテナンス）：リリースや計画メンテ中は、一時的に通知を止める。鳴ると分かっている時間に鳴らさない。
グルーピングやメンテナンス（一時停止）は、監視ツールによって機能の有無や設定の手間が大きく違います。使っているツールにその機能が無ければ、無理に入れなくて大丈夫です。 リリースやメンテの時間帯だけ、通知チャンネルを手動でミュートにするだけでも、ひとまず代わりになります。
- 「鳴ったのに何もしなかった」を記録する：対応不要だったアラートにひと言「対応不要」と残しておくと、棚卸しのときに止める判断がしやすい。
完璧な閾値を最初から当てるのは誰にも無理です。「鳴った結果を見て、少しずつ直す」を前提にしておくと、気持ちが楽になります。
具体例：よくある3つの鳴らしすぎ
実際の現場では、こんな形で鳴らしすぎが起きがちです。直し方とセットで見てみましょう。
- 「CPU 80%超え」で日に何度も鳴る：症状ではなく原因で鳴らしている例。→ 「応答が遅い／エラー率が高い」に寄せ、CPUはダッシュボード送りにする。それでもCPUを見るなら「90%を5分継続」に。
- 深夜バッチの最中に毎晩アラート：処理が重くなる時間に鳴っているだけ。→ バッチ実行中はその監視を一時停止（メンテナンス）にする、または閾値の継続時間を延ばす。ただし「上げる・延ばす」だけだと、本当に重い夜の異常まで気づけなくなることがあります。できればバッチ時間帯だけ別の閾値を持つ、それが難しければ朝イチでバッチの結果ログを確認する運用に切り替えるなど、止めっぱなしにしない逃げ道も用意しておくと安心です。
- 同じ障害で通知が50連打：1つの原因が大量の通知になっている。→ 同じラベル・同じサービスのアラートをまとめて1通知に（グルーピング）。
どれも「監視を減らす」のではなく、「人が動くべき合図だけを、ちゃんと届くように整える」直し方です。
影響：鳴らしすぎを直すと、何が変わるか
アラートを「動くものだけ」に絞ると、対応の速さ以上に、日々の安心が変わります。
- 通知が鳴ったら「これは本当に動くやつだ」と即座に分かる。反射的な既読がなくなる。
- 夜間・休日に起こされる回数が減り、すり減らない。
- 本当の障害が「その他大勢」に埋もれず、見落としが減る。
- 「このアラートが鳴ったらこうする」が明確になり、自分以外の人も同じ判断ができる。
逆に、鳴らしすぎを放置すると、監視はあるのに「誰も見ていない」状態になり、いざという時に気づけない——いちばん避けたい形に近づいてしまいます。
明日やること：無視しているアラートを1つ止める
いきなり全部の閾値を見直さなくて大丈夫です。明日できる、いちばん小さな一歩はこれです。
- ここ1週間でいちばん多く鳴ったアラートを1つ思い浮かべる。
- そのアラートで、自分が実際に何か対応したかを振り返る。毎回スルーしていたなら候補。
- そのアラートを、通知から外す（ダッシュボード送りにする）か、閾値に「◯分継続」を足す。
- 「すぐ対応」と「見ておく」の通知先を分けられないかを1つだけ考える。
- 直した内容を、ひと言でいいのでどこかにメモする（後で棚卸しのときに効きます）。
1つ止めるだけでも、明日からの通知は確実に減ります。完璧な設計を目指さず、まず「鳴っても無視している1件」を卒業させましょう。
「監視アラートの閾値」チェックリスト
鳴らしすぎになっていないかを確かめる項目です。コピーして、自分の監視に当ててみてください。
- 鳴っても毎回スルーしているアラートが、通知に残っていないか
- 各アラートは「鳴ったら人が動く」ものになっているか（動かないなら通知から外す）
- 「原因（CPU等）」ではなく「症状（遅い・エラー）」で鳴らせているか
- 一瞬の上振れで鳴らないよう「◯分継続」の条件が入っているか
- ディスク・証明書など、じわじわ進むものは余裕を持って鳴らしているか
- 「すぐ対応」と「見ておく」で通知先が分かれているか
- 夜間・休日に自分を起こしていいアラートを、自分で把握しているか
- 鳴ったアラートを、ときどき棚卸しする習慣があるか（月1回が無理なら、障害が起きた直後のついでに見直すだけでも可）
全部に○が付かなくても大丈夫です。1つでも「動かないアラート」を止められたら、それだけで監視は良くなっています。まずは本文のとおり、いちばん無視している1件を止めるところからで十分です。
よければ、こちらも
アラートの設計は、障害対応全体の入口です。鳴った後の段取りや、連絡・記録の型もあわせて1枚にしておくと、いざという時に落ち着けます。
- 障害対応runbookテンプレート｜初動・切り分け・連絡・記録を1枚に：アラートが鳴った後の動きを、初動・連絡・記録までまとめた型です。
- 500エラーが出たら最初に見る5つのログ｜場所と確認の順番：症状アラートが鳴ったとき、原因にたどり着くためのログの見方。
- 障害の第一報テンプレート｜誰に・何を・どの順で伝えるか：「すぐ対応」のアラートが鳴ったとき、関係者に出す第一報の文面テンプレ。
アラートが鳴りやまない毎日は、本当に消耗します。でも、それは監視が悪いのでも、あなたの集中力が足りないのでもありません。閾値が、まだ現場に合っていないだけです。 今日は「鳴っても無視している1件」を止めるだけで十分です。その小さな一歩が、本当に困ったときにちゃんと気づける監視へと、少しずつ近づけてくれます。
ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。