フレームワーク活用ガイドひとことで言うと#
メトリクス・ログ・トレースの3つの柱で「システムの内部で何が起きているか」を可視化し、障害を予防・検知・迅速に解決するための手法。モニタリングは「何が起きたか」、オブザーバビリティは「なぜ起きたか」を知るための能力。
押さえておきたい用語#
- REDメトリクス
- **Rate（リクエスト率）、Errors（エラー率）、Duration（所要時間）**の3指標。サービスの健全性を測る基本フレームワーク。
- USEメトリクス
- Utilization（使用率）、Saturation（飽和度）、Errorsの3指標。インフラリソースのボトルネックを特定するフレームワーク。
- SLI / SLO
- Service Level Indicator（計測指標）とService Level Objective（目標値）。信頼性を定量的に管理する基盤。
- エラーバジェット
- SLOの余白を**「使える信頼性の予算」**として管理する仕組み。予算が残っていればリリース可能、枯渇したら信頼性改善に集中。
- 構造化ログ
- JSON形式などで検索・フィルタリングが容易なログ形式。非構造化テキストログの問題を解決する。
モニタリングとオブザーバビリティの全体像#
こんな悩みに効く#
- 障害に気づくのがいつもユーザーからの問い合わせ
- 「なんか遅い」と言われても、どこがボトルネックか特定できない
- マイクロサービスでリクエストが複数サービスをまたぐと、追跡できない
基本の使い方#
システムの数値データを定期的に収集し、ダッシュボードで可視化する。
- インフラメトリクス: CPU使用率、メモリ使用量、ディスクI/O
- アプリケーションメトリクス: リクエスト数、レスポンスタイム、エラーレート
- ビジネスメトリクス: 注文数、アクティブユーザー数、売上
- ツール: Prometheus + Grafana、Datadog、CloudWatch
ポイント: RED（Rate/Errors/Duration）またはUSE（Utilization/Saturation/Errors）メソッドで必要なメトリクスを選定する。
アプリケーションのログを構造化し、一箇所に集める。
- JSON形式で構造化ログを出力する
- リクエストIDやユーザーIDをログに含める
- ログ集約: Elasticsearch + Kibana、Loki + Grafana、CloudWatch Logs
- ログレベル（ERROR/WARN/INFO/DEBUG）を適切に使い分ける
ポイント: 「障害が起きたとき、このログだけで原因がわかるか？」を基準に、ログの内容を設計する。
1つのリクエストが複数サービスを横断する経路を追跡する。
- リクエストにトレースIDを付与し、サービス間で伝播させる
- 各サービスでの処理時間を可視化する
- ツール: Jaeger、Zipkin、OpenTelemetry、Datadog APM
ポイント: マイクロサービス環境では分散トレースがないと障害調査が不可能に近い。
異常を検知して通知し、サービスレベルを管理する。
- SLI（サービスレベル指標）: レスポンスタイム p99 < 500ms、エラーレート < 0.1%
- SLO（サービスレベル目標）: 可用性 99.9%（月間ダウンタイム43分以内）
- アラート: SLOに影響するメトリクスが閾値を超えたらSlack/PagerDutyに通知
ポイント: アラートが多すぎると「アラート疲れ」で無視される。本当に対応が必要なものだけ通知する。
具体例#
メトリクス: 注文APIのリクエスト数（1分あたり）、p50/p95/p99レスポンスタイム、決済成功率、在庫エラー率をGrafanaダッシュボードで可視化。
ログ: 注文処理の各ステップをJSON形式で出力。{ "traceId": "abc-123", "step": "payment", "status": "success", "duration_ms": 150 }。KibanaでtraceId検索すると1注文の全処理ログが一覧表示。
トレース: 注文API → 在庫サービス → 決済サービス → 通知サービスの処理時間をJaegerで可視化。決済サービスのレスポンスが2秒かかっていることを発見 → 決済ゲートウェイのタイムアウト設定を調整。
結果: 障害の検知から原因特定まで平均45分から12分に短縮。ユーザーからの問い合わせで気づくケースがゼロに。
状況: 月間アラート数が800件。うち対応が必要なのは50件（6%）。オンコール担当が疲弊し、本当に重要なアラートも見逃す事態に。
改善:
- SLOベースのアラートに移行。「エラーバジェットの消費速度」でアラート発報
- 情報系（ログ量の急増など）はSlack通知のみに格下げ
- 同一障害の連続アラートを抑制（グルーピング+抑制ルール）
結果: 月間アラート数が800件から60件に削減。対応必要なアラートの割合が6%から85%に向上。オンコール担当の離職率も改善。
状況: 深夜にDBの応答が遅くなる障害が発生。技術メトリクスでは「DB応答時間が3倍」とわかるが、ビジネスへの影響がわからず、エスカレーション判断に30分を浪費。
改善: Grafanaダッシュボードにビジネスメトリクスを追加。
- リアルタイム注文数（1分間隔）
- 決済成功率
- カート離脱率
効果: 同様の障害が再発した際、「注文数が通常の40%に低下」「決済成功率が60%に悪化」を即座に確認。影響額を「分あたり約15万円の機会損失」と見積もり、5分でエスカレーション判断を実行。
やりがちな失敗パターン#
- メトリクスを取りすぎてダッシュボードが見きれない — 100個のグラフがあるダッシュボードは誰も見ない。「この画面を見れば健全性がわかる」というサマリーダッシュボードを1つ作る
- ログに個人情報を出力する — メールアドレスやパスワードがログに残り、セキュリティインシデントになる。個人情報はマスキングするルールを必ず設ける
- アラートの閾値が固定的すぎる — 平日と休日でトラフィックが違うのに同じ閾値を使い、毎週末に誤報が出る。動的な閾値（異常検知ベース）を検討する
- 3つの柱をバラバラに運用する — メトリクスからトレース、トレースからログへジャンプできない。トレースIDで横断検索できる仕組みを構築すること
まとめ#
モニタリングとオブザーバビリティは 「運用の基盤」。メトリクス・ログ・トレースの3本柱を整備し、SLOベースでアラートを設定することで、障害の早期検知と迅速な原因特定が可能になる。まずはアプリケーションのREDメトリクス（リクエスト数、エラーレート、レスポンスタイム）のダッシュボードを1つ作るところから始めよう。