監視・ロギング・アラート体系——障害に気づく仕組みの設計

読了時間: 約9分 ｜ 文字数: 約3,300字

「システムは正常です」——この言葉に根拠はあるか。監視なしにシステムの状態を語ることは、計器のないコックピットで飛行するようなものだ。本稿では、Observability（可観測性）の3本柱と、アラート疲れを起こさないアラート設計を解説する。

Observability の3本柱

メトリクス

数値で表せるシステムの測定値。時系列データとして収集・可視化する。

• USE メソッド（リソース視点）: Utilization（使用率）、Saturation（飽和度）、Errors（エラー率）
• RED メソッド（リクエスト視点）: Rate（リクエストレート）、Errors（エラー率）、Duration（応答時間）

# Prometheus のメトリクス例
http_requests_total{method="GET", status="200"} 15234
http_request_duration_seconds{quantile="0.99"} 0.254

Prometheus + Grafana がメトリクス監視のデファクトスタンダードだ。

ログ

イベントの詳細な記録。メトリクスが「何が起きているか」を示し、ログが「なぜ起きたか」を示す。

構造化ログ

{
  "timestamp": "2026-03-13T10:30:00Z",
  "level": "ERROR",
  "service": "payment",
  "trace_id": "abc123",
  "message": "Payment failed",
  "user_id": "u-456",
  "error_code": "CARD_DECLINED"
}

テキストログではなく JSON 形式の構造化ログを使う。検索、フィルタリング、集計が容易になる。

ログ集約

各サービスのログを中央のストレージに集める。ELK Stack（Elasticsearch + Logstash + Kibana）や Loki + Grafana が代表的なソリューションだ。

トレース

1つのリクエストがシステム内のどのサービスを通過し、各ステップでどれだけ時間がかかったかを追跡する。マイクロサービスにおいて、パフォーマンスのボトルネックを特定するために不可欠。

[リクエスト] → API Gateway (2ms)
                → Auth Service (15ms)
                → Order Service (45ms)
                    → Payment Service (120ms) ← ボトルネック
                    → Inventory Service (8ms)

アラート設計

アラート疲れを避ける

過剰なアラートは「オオカミ少年」効果を生む。チームがアラートを無視し始めたら、重大なインシデントも見逃す。

良いアラートの条件:

1. アクション可能: アラートを受けた人が何かアクションを取れる
2. 緊急性がある: 対応が必要なタイミングで通知される
3. 文脈がある: 何が起きているか、どう対処すべきかの情報が含まれる

重要度の階層

症状ベースのアラート

原因ではなく症状でアラートを設計する。

× CPU 使用率が 90% を超えた（原因）
○ レスポンスタイムの 99 パーセンタイルが 2秒を超えた（症状）

CPU 使用率が高くても、ユーザーに影響がなければ対応不要だ。ユーザー体験に直結する指標でアラートする。

SLI / SLO / SLA

SLI（Service Level Indicator）

サービスの品質を測定する具体的な指標。

• リクエストの成功率（可用性 SLI）
• レスポンスタイムの 99 パーセンタイル（レイテンシ SLI）

SLO（Service Level Objective）

SLI の目標値。「99.9% の可用性」「99パーセンタイルのレイテンシが 500ms 以下」など。

エラーバジェット

SLO から逆算した「許容される障害の量」。月間99.9%の可用性なら、約43分のダウンタイムが許容される。エラーバジェットが残っていれば積極的にリリースし、枯渇したら安定化に注力する。

実装スタック

So What?——実務への応用

• 3本柱をすべて導入する: メトリクスだけ、ログだけでは不十分。3つを相関させることで真の可観測性が得られる
• アラートは症状ベースで設計する: ユーザー影響に直結する指標を監視し、アラートの数を最小限に保つ
• SLO を設定してエラーバジェットを運用する: 100% の可用性は目指さない。現実的な目標を定め、速度と安定性のバランスを取る
• ダッシュボードは3枚以下で始める: 概要、サービス別詳細、インシデント調査用。多すぎるダッシュボードは誰も見ない

監視は「入れて終わり」ではなく、継続的に改善するものだ。インシデントが起きるたびに「このインシデントをより早く検出できたか」を振り返り、監視体制を進化させる。

参考リンク

• Google SRE Book — Google の SRE 実践ガイド（無料公開）
• Prometheus ドキュメント — Prometheus の公式ドキュメント
• Grafana ドキュメント — Grafana の公式ドキュメント
• OpenTelemetry — 観測可能性の統合フレームワーク