メインコンテンツまでスキップ

第22章：アラートに向く指標、向かない指標🚨📣

この章でできるようになること🎯✨​

  • 「起こしていいアラート」と「ダッシュボードで眺めればいい指標」を見分けられる👀
  • アラート候補を3つだけに絞れる（鳴らしすぎ地獄回避🥲➡️😊）
  • しきい値・時間窓・ノイズ対策まで含めて、**“実戦で使える形”**にできる💪🔥

1) まず大前提：アラートの目的って何？🔔🧠​

アラートは「通知」じゃなくて「行動スイッチ」だよ〜！🕹️✨

✅ 良いアラート = 人が今すぐ何かできる（止血・切り分け・エスカレーション） ❌ ダメなアラート = 見ても困る／原因が多すぎる／頻繁に誤報

そして超重要な考え方👇

「原因」より「症状」をアラートにする💡​

  • 原因（CPU高い・メモリ多い）って、別にユーザーが困ってないこともあるよね？🫠
  • 症状（エラー増・遅い・タイムアウト）は ユーザー影響そのもの✨ なので「症状ベースで少なく」がおすすめ！ (Google Cloud)

2) 1秒で判定する “アラート向き” チェック✅⏱️​

画像を挿入予定

次の5つ、全部Yesならアラート向き！😍

  1. ユーザー影響（症状）に直結してる？（遅い/失敗/利用不能）
  2. それが起きたら 今すぐ対応したい？（夜中でも起きる価値）😪➡️😱
  3. しきい値を説明できる？（SLO/仕様/過去データ）📏
  4. ノイズに強い？（スパイク1発で鳴らない）⚡️🧯
  5. 鳴ったら **手順（Runbook）**がある？（最初の3手が書ける）🧭

3) アラートに向く指標たち🥇🚨（基本これ！）​

A. エラー率（失敗の割合）🟥​

  • **「失敗が増えた」**は症状ど真ん中

  • カウントじゃなくて **率（割合）**が強い✨

    • 例：5xx率、例外率、タイムアウト率、依存先エラー率 など

Prometheusでは rate() が基本（アラート向き）だよ〜！ (prometheus.io)

B. レイテンシ（遅さ）🕰️🐢​

  • これも症状ど真ん中✨

  • ただし注意！

    • ❌ 平均（average）だけでアラートは危険（遅い人が埋もれる😇）
    • ✅ **パーセンタイル（p95/p99）**が扱いやすい

パーセンタイルは Histogram が強い！

  • Histogram はサーバ側で histogram_quantile() で求められる仕組みが説明されてるよ (prometheus.io)

C. Saturation（詰まり・飽和）🚧📛​

  • CPUやメモリそのものじゃなくて、**「詰まりがユーザー影響につながる形」**がアラート向き✨

    • 例：キュー長が増え続ける、同時処理が上限に貼り付く、コネクションプール枯渇など

4) アラートに “向かないことが多い” 指標たち🙅‍♀️📉​

「原因っぽい」ものは、基本ダッシュボード行き🧸​

  • CPU使用率が高い🔥
  • メモリ使用量が多い🧠
  • GC回数が多い🧹
  • スレッド数が増えた🧵
  • Pod/プロセス数が減った（ただし可用性に直結なら例外）

これらは「原因候補が多すぎる」ので、誤報やノイズになりがち。 症状（エラー/遅延）とセットで使うのが気持ちいい！ (Google Cloud)

5) しきい値と時間窓：ここが勝負🔥⏳​

“瞬間値”で鳴らさない（ノイズ対策）🧯​

アラートはだいたい👇の形が安定！

  • **率（ratio）**を
  • **時間窓（例：5分）**でならして
  • 一定時間続いたら or 複数窓で一致したら発火

Prometheus的には「irate()はグラフ用」「アラートはrate()」が推奨だよ (prometheus.io)

6) “SLOベース”にするとアラート設計が一気にラク😍📐​

ここ、2026時点でも超王道！✨ GoogleのSRE Workbookは「SLOをアラートに落とす方法」を段階的に説明してて、**Burn rate（燃焼率）**まで丁寧に扱ってるよ (Google SRE)

Burn rateってなに？🔥​

  • 「許される失敗（エラーバジェット）」を どれくらいの速度で溶かしてるか

  • 例：SLO 99.9%（許容失敗率0.1% = 0.001）なら

    • 失敗率が 1%（0.01）だと burn rate = 0.01 / 0.001 = 10 みたいな感じ💡 (Google SRE)

“for:で◯分続いたら” だけに頼るのは危険⚠️​

SRE Workbookでも、持続条件（duration）だけで作ると

  • 重大障害でも検知が遅い
  • ちょい回復でタイマーがリセットされ続けて検知できない みたいな欠点があるよ、とハッキリ書いてるよ (Google SRE)

7) 題材アプリで「アラート候補3つ」を決めよう🥹➡️😊（演習パート）​

第21章の “成功/失敗/遅延” を思い出してね🧪✨ ここから 3つだけ選ぶよ！

候補A：エラー率（5xx / 例外率）🚨🟥​

  • 目的：ユーザーが失敗してるのを即検知
  • 判断：症状ど真ん中✅

候補B：p95レイテンシ（遅延）🐢⏱️​

  • 目的：遅くて不満が爆発する前に検知
  • 判断：症状ど真ん中✅（平均じゃなくp95/p99推奨） (prometheus.io)

候補C：飽和の予兆（詰まり系）🚧​

  • 目的：遅延→タイムアウトに行く前に止血
  • 判断：単体だと原因寄りなので、症状とセットがおすすめ✨

8) 例：PromQL（雰囲気だけ掴めればOK）🧩​

※ “形”が大事！暗記しなくてOKだよ〜🫶

8.1 エラー率アラート（率で見る）🟥​

- alert: HighErrorRate
  expr: |
    sum(rate(http_requests_total{status=~"5.."}[5m]))
      /
    sum(rate(http_requests_total[5m]))
    > 0.01
  for: 5m

8.2 レイテンシ（Histogram + p95）🐢​

histogram_quantile(
  0.95,
  sum(rate(http_request_duration_seconds_bucket[5m])) by (le)
) > 0.5
  • Histogram/Summaryの違いと、histogram_quantile() 前提の話はPrometheus公式がわかりやすいよ (prometheus.io)

8.3 SLO/Burn rate（考え方）🔥​

SRE Workbookの流れだと、SLOをアラートにする時は

  • 有意なエラーバジェット消費を検知する
  • そのために burn rate を使う …が王道だよ (Google SRE)

9) C#側：メトリクスを “アラート向き” に出すコツ🔧📈​

.NETは System.Diagnostics.Metrics が基礎だよ（公式の説明あり） (Microsoft Learn) OpenTelemetry .NETでも MetricsはこのAPI前提でベストプラクティスがまとまってるよ (OpenTelemetry)

9.1 最小メトリクス（カウント＋失敗＋時間）🧸​

using System.Diagnostics.Metrics;

public static class AppMetrics
{
    public static readonly Meter Meter = new("Sample.Api", "1.0.0");

    public static readonly Counter<long> RequestsTotal =
        Meter.CreateCounter<long>("app_requests_total");

    public static readonly Counter<long> ErrorsTotal =
        Meter.CreateCounter<long>("app_errors_total");

    public static readonly Histogram<double> RequestDurationMs =
        Meter.CreateHistogram<double>("app_request_duration_ms", unit: "ms");
}

設計ポイント✨

  • アラートに使うなら「文字列ログ」じゃなくて

    • 総数（Counter）
    • 失敗数（Counter）
    • 時間分布（Histogram） を揃えるのが強い💪

9.2 Prometheusに出す（OpenTelemetry）🧩​

Prometheusスクレイプ用のASP.NET Core exporterはNuGetでも公式で提供されてるよ (nuget.org) また、OTel公式ドキュメントに UseOpenTelemetryPrometheusScrapingEndpoint が載ってるよ (OpenTelemetry)

（本番はCollector経由がベストプラクティス、も公式で推してるよ） (OpenTelemetry)

10) 最後のミニ演習🎓✨（ここが本番！）​

演習1：向き/不向きを仕分け🗂️​

次を「アラート向き / ダッシュボード向き」に分類してね👇

  • CPU使用率
  • 5xx率
  • 平均レイテンシ
  • p95レイテンシ
  • 例外数
  • GC回数

👉 ヒント：症状はアラート、原因はダッシュボード (Google Cloud)

演習2：「3つだけ」選ぶ🥲➡️😊​

題材アプリに対して、次のフォーマットで3つ書いてね📝

  • アラート名：
  • 何が起きてる？（症状）
  • ユーザー影響は？
  • しきい値（仮）：
  • 見るべき次の画面（ダッシュボード/ログ/トレース）：

11) AI活用（Copilot/Codex向け）🤖✨​

  • 「このメトリクスはアラート向き？向かない？理由も」って聞く👂
  • 「p95のPromQL作って」→ 作らせて、しきい値と窓だけ人が決める🧠
  • 「アラート本文（何が起きて、何を見て、何をする）を短く」って整形✂️

まとめ💖​

  • アラートは **“行動スイッチ”**🔔
  • 基本は 症状（エラー率・遅延・飽和の影響） を鳴らす (Google Cloud)
  • Prometheusなら rate()中心、Histogramでp95/p99も扱いやすい (prometheus.io)
  • 迷ったら SLO/Burn rateで整えるとスッキリするよ (Google SRE)

次の章（23章）は、いよいよトレース編に入って「遅いのはどこ？」を地図で追いかける感じになるよ〜！🧵🧭✨