--- title: メトリクスとアラート url: https://doc.liz6.com/ja/distributed-systems/08-observability/02-metrics-and-alerts locale: ja area: distributed-systems tags: - distributed-systems - observability date: 2026-06-30 modified: 2026-07-16 description: RED(Rate/Errors/Duration)はサーバー側の外部視点、USE(Utilization/Saturation/Errors)はリソースの内部視点——両者は補完関係にあります。SLIは実際の測定値、SLOは約束された目標、SLAは違反時の結果です。アラート設計の第一原則：ページングは人が直ちに行動すべき事柄のみに、その他はダッシュボードへ——誤報は当直エンジニアがアラートを無視するよう訓練してしまい、見逃しよりも危険です。 --- # メトリクスとアラート > RED(Rate/Errors/Duration)はサーバー側の外部視点、USE(Utilization/Saturation/Errors)はリソースの内部視点——両者は補完関係にあります。SLIは実際の測定値、SLOは約束された目標、SLAは違反時の結果です。アラート設計の第一原則：ページングは人が直ちに行動すべき事柄のみに、その他はダッシュボードへ——誤報は当直エンジニアがアラートを無視するよう訓練してしまい、見逃しよりも危険です。 ## RED と USE の方法论 2つの補完的な視点： ### RED (Rate, Errors, Duration) **サービス**向け——各 service endpoint: - **Rate**: 秒間リクエスト数——トラフィックパターンを理解する - **Errors**: エラー率——500番台、タイムアウト、接続エラー - **Duration**: レイテンシ分布（P50/P90/P99/P99.9）——ユーザー体験 RED はすべてのオンラインサービス（HTTP/gRPC worker）に適しており、各エンドポイントに少なくとも 3 つのメトリクスが必要です。 ### USE (Utilization, Saturation, Errors) **リソース**向け——CPU、メモリ、ディスク、ネットワーク: - **Utilization**: リソースの使用率（CPU%、メモリバイト数） - **Saturation**: リソースの待機キュー（CPU run queue、メモリ OOM score、IO await） - **Errors**: リソースのエラー（ディスク IO エラー、NIC エラー、ドロップパケット） USE はすべての物理/仮想リソースに適しており——使用制限に達する前に早期検出を行います。 ## Prometheus HA Prometheus はステートレス——各インスタンスで scrape 実行。高可用性は、2つの同一インスタンスが独立して scrape を実行することで実現します: Grafana が Thanos をクエリ → A と B の同一 time series を自動的に重複排除（Prometheus の `external_labels` を利用して区別）。 ## SLI → SLO → SLA ``` SLI (Service Level Indicator): 実際に測定されたメトリクス例: 過去28日間の GET /api 成功率 = 99.95% SLO (Service Level Objective): 私たちが約束する目標例: GET /api 成功率 >= 99.9% SLA (Service Level Agreement): 目標未达到时的后果例: SLO未达到 → 10% creditを赔偿 Error budget = 100% - SLO = 0.1% "燃烧"可能: 紧急发布hotfix时(可能短暂破坏SLO), error budget就是你的"配额" ``` ## アラート設計原則 1. **ユーザーが可視化する SLO 違反時のみページング**: メトリクスが `P99 レイテンシ > 500ms` を示していても、ユーザーが利用可能であればページングすべきではありません。`4xx/5xx rate > SLO` の場合にのみページングを送信 2. **原因ではなく症状**: アラートは「ユーザーが 500 エラーを見ている」べきであり、「CPU が 70%」ではない 3. **ノイズの排除**: 各アラートには明確なアクション可能な runbook が必要です。そうでない場合 → チケットに格下げ 4. **感度と特異度のバランス**: `for: 5m` (少なくとも5分間継続して初めて発火) で一時的なスパイクをフィルタリング。`for` が長いほど → 検知は遅くなりますが、false positive は少なくなります ## 誤報のガバナンス ``` 一般的な誤報の原因: - 閾値が固定 (P99=200ms) だが、昼間と夜間でトラフィックパターンが異なる → より大きなウィンドウでのパーセンタイルを使用 - デプロイ中にアラートがトリガーされる → メンテナンスウィンドウを追加するか、ロールアウト中に抑制 - 誤報が多すぎる → アラートが無視される → 実際の障害が見逃される → これをアラーム疲労と呼ぶ ``` ガバナンス: アラート発火を定期的にレビュー——どのアラートがトリガーされたが、対応するユーザー影響がなかったか？→ 閾値を引き上げるか、チケットに変更。 ## 参考 - **Google SRE Book**: Chapter 6 — Monitoring Distributed Systems - **USE Method**: brendangregg.com/usemethod.html - **RED Method**: grafana.com/blog/2018/08/02/the-red-method-how-to-instrument-your-services *Keywords: RED, USE, SLI, SLO, SLA, error budget, Prometheus HA, alert design, alarm fatigue*