オブザーバビリティ（メトリクス・ログ・トレース）

元々は制御工学の言葉で、「出力を観測すれば内部状態を推定できるか」という性質を指します。ソフトウェアでは、コードに手を入れて再デプロイしなくても、すでに出している信号だけで未知の問題を調査できるか がオブザーバビリティの高さです。

なぜ必要か：分散システムは「中が見えない」

1台のサーバで動くモノリスなら、ログを tail して CPU を眺めれば、だいたい状況はつかめました。ところが今は、

• リクエスト1本が 複数のマイクロサービス を横断する
• コンテナは 数分で生まれて消える（落ちた頃にはもうログを出した実体がいない）
• 「遅い」と言われても、どのサービスのどの処理が原因か が一目で分からない

こうなると「サーバにログインして調べる」が成立しません。だからこそ、各サービスが自分の状態を信号として外に出し続け、それを後から突き合わせて調査する設計が要る——これがオブザーバビリティの動機です。

3本柱：メトリクス・ログ・トレース

それぞれ得意分野が違い、補完しあって初めて全体像が見えます。

メトリクス（Metrics）

一定間隔で記録される 数値の時系列 データ。CPU使用率、リクエスト数、エラー率、レイテンシのp95など。

• 集計済みで軽いので、長期間ためても安価
• ダッシュボードやアラートの土台（「エラー率が5%超えたら通知」）
• ただし「何かがおかしい」は分かっても、個別の原因までは分からない

ログ（Logs）

いつ・何が起きたか を記録した、時刻つきのイベント列。エラーメッセージ、注文ID、スタックトレースなど。

• 1件ずつの詳細が分かる（「注文 #1234 が在庫チェックで失敗」）
• 量が多くコストもかさむので、構造化ログ（JSON等）にして検索・集計できる形にするのが定石
• 「何が起きたか」は分かるが、サービスをまたいだ1リクエストの流れは追いにくい

トレース（分散トレース / Traces）

1本のリクエストが複数サービスを通る経路全体 を、所要時間つきで記録したもの。

• リクエストに trace ID を付け、各処理区間を span として連結する
• 「どのサービスの・どの処理で・何ミリ秒かかったか」が見える＝ボトルネックの特定に直結
• 「どこで遅い／失敗したか」を答えるのが役割

3本柱の比較

モニタリング（監視）との違い

混同されがちですが、視点が違います。

• モニタリング＝あらかじめ決めた指標を見張り、既知の異常に気づく（「CPUが90%を超えたら通知」）。"Known unknowns"（起こると分かっている問題）への備え。
• オブザーバビリティ＝事前に質問を決めていなくても、出ている信号を後から掘って調べられる性質。"Unknown unknowns"（予想していなかった問題）にも対応できる。

モニタリングはオブザーバビリティの一部、と捉えると整理できます。監視で「異常」に気づき、可観測性で「原因」を掘る、という関係です。具体的な指標設計は /devops/sre-slo/ の SLI/SLO と一緒に考えると効きます。

つまずきポイント

• ログだけで戦おうとする：サービス横断の遅延はログの grep では追えない。リクエストの流れはトレース、傾向はメトリクスに任せる。
• trace ID を伝播していない：サービス境界で trace ID を渡さないと span が繋がらず、トレースが“途切れた点”だらけになる。
• 何でも全部ログに出す：コスト爆発とノイズ増加で、肝心なログが埋もれる。サンプリングと構造化で「後で集計・検索できる形」に絞る。
• 計測の入れ方がバラバラ：サービスごとに独自フォーマットだと突き合わせ不能。OpenTelemetry のような共通規格で、メトリクス・ログ・トレースを統一的に収集するのが今の定番。

イメージをつかむ

メトリクスでアラートが鳴ってから原因に辿り着くまでの流れの一例です。

# 1) メトリクスで異変に気づく（Prometheus のクエリ例）
#    直近5分の 5xx エラー率
sum(rate(http_requests_total{status=~"5.."}[5m]))
  / sum(rate(http_requests_total[5m]))

# 2) 該当時間帯の失敗リクエストから trace ID を拾う（構造化ログを検索）
#    例: {"level":"error","trace_id":"abc123","msg":"checkout failed"}

# 3) その trace ID でリクエスト経路を開く → どの span で時間/失敗が出たか確認
#    checkout(120ms) → inventory(15ms) → payment(2,400ms ← ここ) ...

メトリクスが「何かおかしい」、トレースが「payment サービスで遅い」、ログが「決済APIがタイムアウトした」——3つが揃って初めて「原因はここ」と言い切れます。

メトリクス収集の具体的な仕組みは /devops/tools/prometheus/ を、信頼性目標との結びつきは /devops/sre-slo/ を参照してください。