アラート
Alerting ・ あらーと
メトリクスやログの異常を検知して人に知らせる仕組み。監視を行動につなげる出口。
✦ 30秒で試す — 航海深夜に何度も起こされるのに、本物の障害は見逃す失敗したアクセスの数が多いのは、どちらの障害？予想してみる概要
アラートは、システムの異常を検知して人に知らせる仕組みです。メトリクスやログを集めてダッシュボードに描くだけでは、誰かが画面を見つめ続けない限り異常に気づけません。「エラー率が一定を超えたら」「証明書の期限が近づいたら」といった条件をルールとして登録しておき、条件が成り立ったときにチャット・電話・専用アプリへ通知を飛ばします。監視を人の行動につなげる「出口」がアラートです。
一見すると「閾値を決めて通知するだけ」の単純な話に思えますが、実務ではアラートは監視の中でいちばん設計が難しい部分です。感度を上げれば誤報が増えて人が疲弊し、下げれば本物の障害を見逃します。深夜に人を起こす価値がある異常はどれか。アラートの設計は技術の問題であると同時に、「人の注意力という限られた資源をどう配るか」という問題でもあります。
なぜ生まれたか
自動の通知がなかった時代、異常に気づく手段は「オペレーターが監視画面を目で確認する」か「ユーザーからの苦情」でした。前者は24時間の人員配置が必要でコストが高く、それでも人の注意力は数十分と続きません。後者では、ユーザーが被害を受けてからしか動けません。サーバの台数が増えるほど目視は破綻し、「機械が見張り、異常のときだけ人を呼ぶ」自動化が欠かせなくなりました。
ところが自動化は新しい問題を生みます。通知を簡単に出せるようになると、アラートは際限なく増えるのです。1台の障害が連鎖して数百通の通知が一斉に鳴る、対応の要らない警告が毎晩届いて本物が埋もれる。「アラート疲れ（alert fatigue）」と呼ばれるこの状態はオオカミ少年の寓話そのもので、通知の無視が当たり前になった組織は、重大障害の一報すら見逃します。このため現代のアラートの設計論は、「どう通知するか」よりも「どう通知を減らし、鳴ったら必ず意味がある状態を保つか」を中心に発展してきました。その到達点が、Google の SRE が広めた「ユーザー影響（SLO）に対して鳴らす」考え方です。
詳細
アラートが届くまでの流れ
代表的な構成である Prometheus と Alertmanager を例に、検知から通知までを追ってみます。監視サーバは、集めたメトリクスに対して登録されたルール（例: 5分間の平均エラー率が1%を超える）を定期的に評価し、成り立つとアラートを発火して通知管理のコンポーネントへ渡します。ルールには「この状態が10分続いたら」という持続時間（Prometheus の for）を付けられ、一瞬のスパイクで鳴らないようにできます（その分だけ、本物の障害でも鳴るのが遅れます）。
通知管理の側はすぐには送りません。関連するアラートをひとまとめにし（グルーピング）、既知の障害に由来する重複を抑え（抑制・サイレンス）、深刻度に応じた宛先へ配送します。深刻ならオンコール担当の電話を鳴らし、軽微ならチャットに流すだけ、という振り分けです。配送先との接続には Webhook が広く使われ、Slack も PagerDuty も Webhook 経由でアラートを受け取ります。
通知して終わりではありません。担当者が一定時間内に確認応答（acknowledge）しなければ、次の担当者や上位者へ自動でエスカレーションする仕組みを組み込み、「通知したのに誰も見ていなかった」を防ぎます。この受け皿になる当番の体制がオンコールで、アラートはインシデント対応の起点になります。
閾値では誤報と見逃しを同時には減らせない
古典的なアラートは、原因側の指標に閾値を仕掛けます。CPU 使用率90%、ディスク残量10%、プロセスの死活。分かりやすい反面、「CPU が90%でもユーザーは何も困っていない」「内部の指標はすべて正常なのにユーザーは使えない」というズレが頻発します。原因になりうる項目は無数にあるので、原因ごとに仕掛けるとアラートは増え続けます。
症状（ユーザーから見たエラー率や遅さ）に閾値を仕掛けても、まだ問題は残ります。エラー率の時系列には、デプロイ直後の数分の揺れや、一瞬のネットワークの乱れのような、ユーザーにほとんど影響しない小さなスパイクが必ず乗ります。閾値を低くすればこのスパイクで誤報が積み上がり、高くすれば、スパイクより低い値でじわじわ続く本物の障害を見逃します。1本の閾値では、誤報と見逃しの両方を同時には減らせないのです。下の部品で、閾値の線を上下に動かして確かめてください。網掛けの区間が本物の障害です。
右端の金のつまみを上下にドラッグして、エラー率の閾値を動かしてください。閾値を超えるたびに呼び出しのベルが鳴ります。網掛けは本物の障害（ユーザーが実際に困った時間）です。
SLO ベースのアラートとバーンレート
これに対する現代の答えが、SRE の実践から生まれた SLO ベースのアラートです。まず「30日間でリクエストの99.9%が成功する」のような目標を決めると、許される失敗の量（エラーバジェット）は0.1%、時間に直すと30日で約43分ぶんになります。アラートは、この予算をどれだけの速さで燃やしているか（バーンレート）に対して鳴らします。バーンレート1は「ちょうど30日で予算を使い切るペース」で、エラー率が0.1%のときに当たります。エラー率が1.44%ならバーンレートは14.4で、1時間で30日分の予算の2%が消えます。
速い燃焼と遅い燃焼は、見る窓の長さを変えて捕まえます。Google の『SRE ワークブック』が推奨する組み合わせは次のとおりです。
1段目は「1時間の平均でバーンレートが14.4を超え、かつ直近5分でも超えている」ときに呼び出します。1時間ぶんの平均を見るので、数分のスパイクでは鳴りません。一方で本物の大障害なら数分のうちに鳴ります。5分の短い窓を「かつ」で重ねるのは、障害が収まったあとに1時間の平均が下がりきるまで鳴り続けるのを防ぐためです。2段目は6時間と30分の窓でバーンレート6を見て、数時間続く中くらいの劣化を捕まえます。3段目の3日と6時間の窓でバーンレート1を超えたら、呼び出しではなくチケットを切り、翌営業日に対応します。どの段も「そのまま放置すると予算の何%が消えるか」で閾値が決まっているので、鳴ったときの緊急度に理由があります。
原因が何百通りあっても、ユーザー影響という1点で束ねられるので、アラートの数を大きく減らせます。これがこの方式の強みです。そのぶん、SLO の決め方（どのリクエストを成功と数えるか）がアラートの質を直接決めることになります。上の部品を「SLO バーンレート」に切り替えると、呼び出しが障害の区間だけに絞られるのが見えます。
良いアラートの条件
SRE の文脈で繰り返し語られる原則は、「ページ（緊急呼び出し）に値するのは、緊急で、かつ人の判断と行動を必要とするものだけ」です。ここから実践的な確認項目が導けます。まず、行動につながること。受けた人が何をすべきか分からない通知は、ダッシュボードかチケットに格下げします。受けた人が最初に開く手順書（ランブック）へのリンクをアラートに添えるのも定石です。次に、症状に対して鳴らすこと。原因（CPU が高い）ではなく症状（ユーザーのリクエストが遅い）に仕掛ければ、未知の原因による障害も捕まえられます。原因側の指標は、調査のときに見るダッシュボードに置きます。
そして、緊急度で経路を分けること。すべてを同じ音で鳴らすと、深刻度の判断が受け手に丸投げされます。最後に、定期的に棚卸しすること。一度も対応につながっていないアラートや毎回無視されているアラートは、消すか条件を見直します。ポストモーテムで「アラートは適切に鳴ったか、早すぎたか遅すぎたか」を振り返るのも、精度を高める定番の営みです。
アラートの質は、チームの健康に直結します。夜間の呼び出しが月に数回か毎晩かは、オンコール担当の生活の質そのものです。意味のないアラートを消す作業は地味ですが、可観測性への投資と並んで、運用の改善で費用対効果がとくに高い仕事のひとつです。
試問
24時間ぶんのエラー率（5分ごと）のグラフです。網掛けの2区間が本物の障害（A は急で激しく、B は低いまま何時間も続く）で、それ以外の短い跳ね上がりはユーザーにほとんど影響しません。右端の金のつまみで閾値を上下にドラッグでき、閾値を超えるたびに当番を呼び出すベルが鳴ります。上の切り替えで、鳴らし方を「SLO バーンレート」（失敗してよい量の予算を燃やす速さを、1時間・6時間などの平均で見る方式）に変えられます。
右端の金のつまみを上下にドラッグして、エラー率の閾値を動かしてください。閾値を超えるたびに呼び出しのベルが鳴ります。網掛けは本物の障害（ユーザーが実際に困った時間）です。