可観測性の三本柱とその限界（メトリクス/ログ/トレース）

可観測性の「三本柱（メトリクス・ログ・トレース）」は、入門では役割分担として教わります（/devops/observability/）。しかし上級者が直面する本当の問題は「柱をまたいだ調査がなぜこんなに難しいのか」です。本稿はこれを情報理論の射影として捉え直します。

出発点：三本柱は「同じイベントの射影」

ある瞬間にサービスが処理する1リクエストは、本来1個の高次元イベントです。timestamp, trace_id, user_id, endpoint, status, duration_ms, db_calls, cache_hit, region … といった多数の属性を持つ1レコードと考えられます。三本柱は、この同じ生イベントを異なる軸で“射影（projection）”した結果にすぎません。

ここを押さえると、後の議論がすべて「どの射影で、どの次元が消えたか」の問題に還元できます。

情報理論的トレードオフ：基数・コスト・文脈

三本柱の差は、3つの量のうち「何を取り、何を諦めるか」で説明できます。

• 基数（cardinality）：区別できる属性値の種類数。user_id や request_id は基数が極めて高い。
• コスト（cost）：1イベントあたりの保存・索引・転送コスト。保持期間と量に比例する。
• 文脈（context）：1イベント単独でどれだけ「前後関係・因果」を語れるか。

メトリクスは、属性を集約軸へ畳むことで基数を意図的にゼロに近づけ、その代償にコストを劇的に下げます。1本の時系列は名前とラベル集合で一意なので（/devops/metrics-cardinality/）、user_id のような高基数属性を載せると時系列数が直積で爆発する。だから基数を捨てることがメトリクスの本質であり、同時に「個別の誰が遅かったか」を原理的に答えられなくなります。

ログは逆に基数を全部残すため文脈（詳細）は豊かですが、量とコストが跳ねます。トレースは因果という第3の文脈を持ち込みますが、全件保持はコスト的に無理なのでサンプリングで全件性を捨てます。

なぜ相関付けが難しいのか

柱をまたいだ調査の核心は「メトリクスのこの山を作った個別リクエストを、トレースとログで突き合わせたい」です。これが難しい理由は3つに分解できます。

1. 共有キーの欠落。 集約された時系列には、もう trace_id も request_id も残っていません。畳んだ瞬間に再結合の鍵が消えるからです。exemplar はこの問題への部分的な答えで、集約済みサンプル点に代表リクエストの trace_id を別枠で添付し、基数を増やさずメトリクスからトレースへ橋を架けます。

2. サンプリング母集団のズレ。 トレースは（例えば）1%をサンプリングします。すると「メトリクスが捉えた異常イベント」が、トレース側ではそもそも保存されていない確率が高い。とくに尾部（稀な遅延）を見たいのに、ヘッドサンプリングは異常を引き当てにくい。これを緩めるのがテールサンプリングで、trace 完了後に「遅い/エラーのものだけ残す」判断を下します。

3. 時刻だけでは結合できない。 共有キーがないと、最後の頼みは時刻の近さです。しかし分散環境では各ノードの時計がずれ、相関の基準にできません（/devops/logical-clocks/）。timestamp が近い だけで別サービスのログとspanを結びつけるのは、高負荷時ほど誤結合を生みます。

共有キーによる連結：context propagation

唯一の現実的な解は、全シグナルに同じ識別子を貫通させることです。リクエスト入口で trace_id を発行し、サービス境界を越えるたびにヘッダで伝播し（/devops/tracing-context-propagation/）、ログにもメトリクスのexemplarにも同じ ID を刻む。すると3つの射影は「同じ trace_id」という主キーで結合可能なテーブル群になります。

# 同一リクエスト由来であることを trace_id で貫通させる
metric  : http_request_duration_seconds_bucket{le="2.5"} 1 # exemplar: {trace_id="abc123"}
trace   : span{trace_id="abc123", service="payment", duration_ms=2400}
log     : {"trace_id":"abc123","level":"error","msg":"payment gateway timeout"}

この共有キーがあって初めて「メトリクスの異常 → そのトレース → そのspanの詳細ログ」という一気通貫の遷移が成立します。逆に言えば、キー伝播が1箇所でも切れると、そこから先の柱は再結合不能になります。

統合の潮流：wide event（構造化イベント）

ここまでの分析が示すのは、「先に射影してから、後で苦労して再結合する」順序の筋の悪さです。wide event（canonical log line とも呼ばれる）は順序を逆転させます。

考え方は単純です。1リクエストにつき、削る前の高基数イベントを1行（数十〜数百の属性を持つ広い構造体）として丸ごと記録する。 メトリクスやトレースは、この生イベント群から**後段で導出（クエリ時集約）**します。

{
  "trace_id": "abc123", "span_id": "f1", "parent_id": "e0",
  "timestamp": "2026-06-21T10:00:00Z", "service": "checkout",
  "user_id": "u_5521", "endpoint": "/cart/submit", "status": 500,
  "duration_ms": 2400, "db_calls": 7, "cache_hit": false,
  "region": "ap-northeast-1", "build": "v412", "error": "payment_timeout"
}

このモデルでは三本柱の境界が溶けます。属性で group by して数えればメトリクス、parent_id で親子をたどればトレース、1行を読めばログです。射影は保存時ではなくクエリ時に行うので、「事前に集約軸を決めていなかった次元」も後から掘れる——これがオブザーバビリティ本来の定義（未知の問いに後から答える）と一致します。

まとめ

• 三本柱は独立した3技術ではなく、同じ生イベントを「集約（基数を捨てる）」「全文（基数を残す）」「因果（順序を残す）」へ射影した結果である。
• 相関付けが難しいのは、集約・サンプリング・時刻という直交した削減軸で柱ごとに失う次元が異なり、共有キーがないと再結合できないため。テールサンプリングや exemplar はこのギャップへの部分解。
• 唯一の確実な連結手段は trace_id の貫通（context propagation）。これが切れると以降の柱は再結合不能になる。
• wide event は「先に射影して後で再結合」を「先に1イベントを保持して後から射影」へ反転させ、相関付けを構造的に不要にする潮流。ただし基数・コストの代償があり、従来メトリクスとの併用が現実解。
• 指標目標との結びつきは /devops/sre-slo/ と併せて考えると、何を保持し何を集約すべきかの判断軸が定まります。