監視設計の型 — 「何をアラートにするか」でアラート疲れを防ぐ

監視の失敗はほとんどの場合、監視が足りないことではなく、アラートが多すぎて誰も見なくなることで起きます。本記事では「何をアラートにするか」を症状ベースで設計し、原因メトリクスはダッシュボードに逃がすという型を、CloudWatchの実装まで含めて整理します。夜間の呼び出しを減らしたい運用担当者向けの実務ガイドです。

01アラート疲れは「監視不足」ではなく「設計不足」

本番運用で一番よく見る失敗は、監視が入っていないことではありません。むしろ逆で、あらゆるメトリクスに閾値を張り、CPUが80%を超えた、ディスクI/Oが跳ねた、特定プロセスが再起動した――そのすべてがメールやチャットに流れ込み、数週間で誰も通知を開かなくなる、という状態です。これがいわゆるアラート疲れ(alert fatigue)です。

厄介なのは、アラートが多い監視は一見「しっかり見ている」ように見えることです。しかし実際には、本当に対応すべき1件が、対応不要な99件に埋もれます。深夜に叩き起こされたのがオートスケールで自然回復する一時的なCPUスパイクだった、という経験を数回すれば、人はその通知チャンネル全体をミュートします。監視の目的は「気づくこと」なのに、通知が多すぎて「気づけなくなる」という倒錯が起きるわけです。

02症状ベース ― ユーザー影響が出た事象だけをアラートにする

設計の芯になる考え方が「症状ベース(symptom-based)のアラート」です。人を呼び出すアラートは、原因(cause)ではなく症状、つまりユーザーやビジネスに実害が出ている事象に限定します。GoogleのSite Reliability Engineeringで広く知られるようになった原則で、実務でも極めて効きます。

具体例で言うと、アラートにすべきなのは次のような症状です。

• APIのエラー率が閾値を超えた(ユーザーがエラー画面を見ている)
• レスポンスのp95レイテンシが目標を超えた(体感で遅い)
• ヘルスチェックが通らずリクエストが捌けていない
• ジョブが期限までに完了せず、後続の締めに間に合わない

一方、CPU使用率・メモリ・コネクション数・キュー長といった原因メトリクスは、それ単体では「ユーザーが困っているか」を語りません。CPUが90%でもレイテンシが正常なら、ユーザーは何も困っていないのです。だからこれらはアラートにせず、ダッシュボードで追う。障害の当事者は症状アラートで呼び出され、原因の切り分けはダッシュボードの原因メトリクスを見て行う。この役割分担が、通知量を一気に減らします。

症状ベースを徹底すると、アラートの本数は驚くほど減ります。監視を初めて整える段階の考え方はCloudWatch監視の最初の一歩でも触れていますが、本記事はその次の「増えすぎたアラートをどう削るか」に踏み込みます。

03SLO/エラーバジェットで「閾値の根拠」を作る

症状ベースにすると、次に必ず「では閾値をいくつにするのか」という問いが来ます。ここで役立つのがSLO(Service Level Objective)とエラーバジェットの発想です。厳密なSREを全面導入しなくても、考え方だけ借りると閾値の議論が一気に楽になります。

たとえば「直近30日で成功率99.9%」をSLOと置くと、許容される失敗(エラーバジェット)は0.1%です。この予算を基準に、「バジェットの消費が速すぎるとき」にアラートを鳴らす、という設計にできます。単純に「エラーが1件出たら鳴らす」のではなく、「このペースで失敗が続くと今月のSLOを割る」という燃焼率(burn rate)で判断するわけです。こうすると、一時的なスパイクでは鳴らず、本当にまずい傾向のときだけ鳴る、というメリハリが付きます。

04アラートを3分類する ― 即時対応 / 翌営業日 / 情報

症状ベースで絞り込んでも、すべての症状が「今すぐ叩き起こす」わけではありません。ここでアラートを緊急度で3分類し、通知経路を分けます。この分類こそが、夜間の呼び出しを減らす実務上の肝です。

• 即時対応(P1): ユーザー影響が今出ている。深夜でも電話・オンコールで人を起こす。例:主要導線の全面停止、決済不能。ここに入れるものを厳しく絞るほど、オンコールは信頼されます。
• 翌営業日(P2): 影響はあるが、朝まで待てる。または冗長構成で当座は耐えている。チャットに残し、営業時間に対応。例:片系のインスタンス障害で自動復旧済み、非クリティカルなバッチの遅延。
• 情報(P3): 人が対応する必要はないが、記録として残す。ダッシュボードやログ、後追いレビュー用。通知は飛ばさないか、専用の低優先チャンネルに集約。

重要なのは、通知経路(電話 / チャット / 記録のみ)を分類ごとに物理的に分けることです。P1だけが鳴る電話は信頼されますが、P1もP3も同じチャンネルに混ざった瞬間、全部がノイズに戻ります。バッチ処理の異常検知と再実行を含む設計はバッチの監視と再実行設計でも扱っており、翌営業日対応(P2)の作り込みが効いてくる典型です。

05ランブック紐付けとノイズ削減

分類ができたら、次はP1・P2の各アラートにランブック(runbook)を紐付けます。ランブックとは「このアラートが鳴ったら、まず何を確認し、何をするか」を書いた手順書です。アラート本文やSNSの通知に、対応するランブックのURLを含めておくのが実務の定石です。

ランブックが書けないアラートは、そもそも設計を疑うべきサインです。「鳴ったが、何をすればいいか誰も分からない」アラートは、対応されずに放置され、結局ミュートされます。逆に、ランブックを書こうとすると「これは自動復旧するから鳴らす必要がない」「これはダッシュボードで十分」という気づきが生まれ、アラートの棚卸しが進みます。

ノイズ削減の実務では、次のような手を組み合わせます。

• 評価期間を延ばす: 「一定期間のうち複数回、閾値を超えたら鳴らす」ことを条件にし、瞬間的なスパイクで鳴らさない。CloudWatch AlarmのDatapoints to Alarm(M out of N)がこれに当たり、評価期間(Evaluation Periods)Nの中で閾値を超えたデータポイントがM個に達すると発報します。ただしこのM個は連続している必要はないため、真に「N回連続で閾値超過」という挙動が欲しい場合はM=N(Datapoints to AlarmとEvaluation Periodsを同値)に設定します。
• フラッピング抑制: 閾値付近で行き来する指標は、閾値と評価期間を見直し、ヒステリシスを持たせる。
• 重複の集約: 同一原因で複数アラートが鳴る場合は、後述のComposite Alarmで束ねる。
• 棚卸しの定期化: 過去N日で一度も対応につながらなかったアラートは、四半期ごとに削除・降格を検討する。

06CloudWatch Alarm / Composite Alarm の実務

ここまでの設計をAWSに落とすと、中心になるのがAmazon CloudWatch AlarmとComposite Alarmです。要点だけ実務目線で整理します。

メトリクスアラームでは、閾値だけでなく評価期間(Period)、評価データポイント数(Evaluation Periods)、そしてM out of Nを表すDatapoints to Alarmを組み合わせます。ここを丁寧に設定するだけで、瞬間スパイクによる誤報がかなり減ります。また、データ欠損時の挙動(Treat missing data)を「notBreaching(欠損は正常扱い)」にするか「breaching」にするかは、監視対象の性質で必ず意識してください。バッチのように稼働時間が限られる対象では、欠損の扱いを誤ると常時アラートになります。

Composite Alarm(複合アラーム)は、複数のアラームをAND/OR/NOTの論理式で束ねる仕組みです。「ロードバランサの5xxが高いかつターゲットの正常数が閾値割れ」のように、複数条件が揃ったときだけ人を呼ぶ、といった設計ができます。個別アラームは静かにさせ、Composite Alarmだけを通知に紐付けることで、1つの障害から10個の通知が飛ぶ状況を1つにまとめられます。

さらに、Composite Alarmにはアクション抑制(action suppression)があります。計画メンテナンスや、上流の依存先がダウンしているときに、抑制用(suppressor)アラームを指定して通知を止められます。抑制の状態遷移に伴う取りこぼしを防ぐため、WaitPeriodとExtensionPeriodというパラメータで待ち時間を調整します。メンテナンス時間帯に大量のアラートが飛んで結局ミュートされる、という事故を防ぐのに有効です。数値上限やパラメータの詳細は変わり得るため、実装前にCloudWatchの公式ドキュメントで最新仕様を確認してください。

複数アカウント環境では、アラームやダッシュボードをどのアカウントに集約するかも設計事項になります。監視の集約先を含むアカウント構成の考え方はマルチアカウント統制、設計全体の指針はクラウド設計ガイドラインもあわせてご覧ください。

—まとめ

監視設計の失敗は、監視が足りないことより、アラートが多すぎて無視されることで起きます。立て直しの型はシンプルです。人を呼ぶアラートは症状ベースでユーザー影響が出た事象に絞り、原因メトリクスはダッシュボードに逃がす。閾値の根拠はSLO/エラーバジェットで持ち、アラートは即時対応 / 翌営業日 / 情報の3分類で通知経路を分ける。各アラートにはランブックを紐付け、対応につながらないアラートは棚卸しで削る。AWS上ではM out of NやTreat missing dataを丁寧に設定し、Composite Alarmで重複を束ね、アクション抑制でメンテ時のノイズを止める。

この型は一度作って終わりではなく、運用しながらアラートを減らし続ける営みです。まず「一度も対応につながっていないアラート」を1本消すところから始めれば、通知チャンネルは少しずつ信頼を取り戻します。移行直後の性能監視は移行後の性能問題、料金感の全体像は料金もあわせてどうぞ。