オブザーバビリティ
ログ・メトリクス・トレースの3本柱でシステム内部の状態を外部から把握するオブザーバビリティの考え方を学ぶ
モニタリングとオブザーバビリティの違い
モニタリング(監視)は、あらかじめ決めておいた指標(CPU使用率やエラー率など)を 継続的に観測し、閾値を超えたら知らせる仕組みです。一方でオブザーバビリティ(可観測性)は、システムが出力する情報だけを手がかりに、 「事前に想定していなかった質問」にも答えられる状態を指します。
たとえば「特定の地域から来た、特定のバージョンのモバイルアプリだけでエラーが増えている」といった、 事前にダッシュボードを用意していなかった切り口の調査も、可観測性の高いシステムなら データを組み合わせて掘り下げられます。モニタリングは「既知の未知」を検知する仕組み、 オブザーバビリティは「未知の未知」にも対応できる能力と整理できます。
3本柱: ログ・メトリクス・トレース
ログ(Logs)
「いつ、何が起きたか」を記録する時系列のイベント。個々のリクエストやエラーの詳細な文脈を確認するのに向く。
{"timestamp":"2026-03-01T09:12:03Z","level":"error","msg":"payment failed","orderId":"ord-4821","reason":"gateway_timeout"}メトリクス(Metrics)
時系列で集計された数値。リクエスト数・エラー率・レイテンシなど、システム全体の傾向を低コストで把握できる。
http_requests_total{status="500", route="/api/orders"} 42
http_request_duration_seconds{quantile="0.99", route="/api/orders"} 1.8トレース(Traces)
1つのリクエストが複数のサービスをまたいで処理される過程を、時間軸に沿って可視化したもの。 マイクロサービス構成でどのサービスがボトルネックかを特定するのに役立つ。
分散トレーシングの仕組み
分散トレーシングでは、1つのリクエストにトレースIDを発行し、 リクエストが経由する各サービスがその処理単位をスパンとして記録します。 スパンには開始・終了時刻や親スパンとの関係が含まれ、これをつなぎ合わせることで リクエスト全体の処理経路と、どこで時間がかかっているかが一目でわかります。
trace_id=8f3a... span=api-gateway duration=210ms
└─ span=order-service duration=180ms
└─ span=inventory-service duration=120ms
└─ span=payment-service duration=40ms読み解き方
この例では、api-gatewayからorder-serviceの呼び出しで大半の時間が消費されており、 さらにその内訳としてinventory-serviceの処理が支配的だとわかります。ボトルネックの特定にトレースが役立ちます。
オブザーバビリティ導入の心構え
3本柱を導入すること自体が目的ではありません。大切なのは「本番環境で何が起きているかを、 事前に想定していなかった問いにも答えられる形で把握できるか」です。導入初期は 既存の障害調査で「あの時この情報があれば早く原因がわかったのに」という振り返りをもとに、 必要なログ・メトリクス・トレースを段階的に増やしていくのが現実的な進め方です。
ポイント
- モニタリングは「既知の異常」を検知し、オブザーバビリティは「未知の問い」に答える能力
- ログ・メトリクス・トレースはそれぞれ役割が異なり、組み合わせて使う
- 分散トレーシングはトレースIDとスパンでリクエストの経路と所要時間を可視化する
- 導入は一度に完璧を目指さず、実際の障害調査から必要な情報を段階的に増やす
確認クイズ
1 / 3オブザーバビリティがモニタリングと最も異なる点はどれか？