アラート
アラート
メトリクスやログの異常を検知して人間へ通知する仕組み。監視を行動につなげる出口。
概要
アラートは、システムの異常を検知して人間に知らせる仕組みです。メトリクスやログを集めてダッシュボードに描くだけでは、誰かが画面を見つめ続けない限り異常に気づけません。「エラー率が一定を超えたら」「証明書の期限が近づいたら」といった条件をルールとして登録しておき、条件が成立したときにチャット・電話・専用アプリへ通知を飛ばす — 監視を人間の行動につなげる「出口」がアラートです。
一見すると「閾値を決めて通知するだけ」の単純な話に思えますが、実務ではアラートは監視の中で最も設計が難しい部分です。感度を上げれば誤報が増えて人が疲弊し、下げれば本物の障害を見逃す。深夜に人を叩き起こす価値がある異常はどれか — アラート設計とは、技術の問題であると同時に「人間の注意力という有限資源をどう配分するか」という問題なのです。
なぜ生まれたか
自動通知がなかった時代、異常への気づきは「オペレーターが監視画面を目視で確認する」か「ユーザーからの苦情」に頼っていました。前者は24時間の人員配置が必要でコストが高く、それでも人間の注意力は数十分と持続しません。後者は論外で、ユーザーが被害を受けてからしか動けません。システムが増えるほど目視は破綻し、「機械が監視し、異常時だけ人間を呼ぶ」自動化が必然になりました。
しかし自動化は新しい問題を生みます。通知が簡単に出せるようになると、アラートは際限なく増殖するのです。1台の障害が連鎖して数百通の通知が一斉に鳴る、対応不要な警告が毎晩届いて本物が埋もれる — 「アラート疲れ(alert fatigue)」と呼ばれるこの状態は、狼少年の寓話そのもので、通知の無視が常態化した組織は重大障害の一報すら見逃します。現代のアラート設計論は、「どう通知するか」よりも「どう通知を減らし、鳴ったら必ず意味がある状態を保つか」を中心課題として発展してきました。
詳細
アラートが届くまでの流れ
代表的な構成であるPrometheus + Alertmanagerを例に、検知から通知までを追ってみます。監視サーバは登録されたルール(例: 5分間の平均エラー率が1%を超える)を定期的に評価し、成立するとアラートを発火して通知管理コンポーネントへ渡します。通知管理側は即座に送るのではなく、関連するアラートをひとまとめにし(グルーピング)、既知の障害に由来する重複を抑制し(抑制・サイレンス)、深刻度に応じた宛先へ配送します。深刻ならオンコール担当の電話を鳴らし、軽微ならチャットに流すだけ、という振り分けです。配送先との接続にはWebhookが広く使われ、SlackもPagerDutyもWebhook経由でアラートを受け取ります。
通知して終わりではない点も重要です。担当者が一定時間内に確認応答(acknowledge)しなければ、次の担当者や上位者へ自動的にエスカレーションする仕組みを組み込み、「通知したのに誰も見ていなかった」を防ぎます。この受け皿となる当番体制がオンコールであり、アラートはインシデント対応プロセスの起点になります。
閾値ベースからSLOベースへ
古典的なアラートは原因側の閾値に仕掛けます。CPU使用率90%、ディスク残量10%、プロセスの死活 — 分かりやすい反面、「CPUが90%でもユーザーは何も困っていない」「すべての内部指標は正常なのにユーザーは使えない」というズレが頻発します。原因になりうる項目は無数にあるため、この方式はアラートの増殖とアラート疲れに直結します。
これに対する現代の答えが、SREの実践から生まれたSLOベースのアラートです。まず「リクエストの99.9%が成功する」のようなSLO(ユーザー視点の目標)を定め、その達成を脅かすときだけ通知します。具体的にはエラーバジェット(許容できる失敗の残量)を消費する速度 — バーンレート — を監視し、「この速度で燃え続けると数時間でバジェットが尽きる」なら即時に呼び出し、「数日かけてじわじわ減っている」なら翌営業日のチケットで扱う、と緊急度を消費速度で決めます。原因が何百通りあっても、ユーザー影響という一点で束ねられるため、アラートの数を劇的に減らせるのがこの方式の本質的な強みです。
良いアラートの条件
SREの文脈で繰り返し語られる原則は「ページ(緊急呼び出し)に値するのは、緊急かつ、人間の判断と行動を必要とするものだけ」です。ここから実践的なチェックリストが導けます。第一に、アクション可能であること。受けた人が何をすべきか分からない通知は、ダッシュボードやチケットに格下げします。第二に、症状に対して鳴らすこと。原因(CPUが高い)ではなく症状(ユーザーのリクエストが遅い)に仕掛ければ、未知の原因による障害も捕捉できます。第三に、緊急度で経路を分けること。すべてを同じ音で鳴らすと、深刻度の判断が受け手に丸投げされます。第四に、定期的に棚卸しすること。一度も対応につながっていないアラート、毎回無視されているアラートは、消すか閾値を見直します。ポストモーテムで「アラートは適切に鳴ったか、早すぎたか遅すぎたか」を振り返るのも、アラートの精度を継続的に高める定番の営みです。
アラートの質は、チームの健康に直結します。夜間の呼び出しが月に数回か毎晩かは、オンコール担当の生活の質そのものであり、無意味なアラートを消す作業は地味ながら、可観測性への投資と並んで運用改善の費用対効果が最も高い仕事のひとつです。