Prometheus Exemplarの深淵：メトリクスとトレースを「点」で繋ぐアーキテクトの矜持
オブザーバビリティの世界において、多くのエンジニアが犯す最大の過ちは、メトリクスとトレースを「別々のツール」として扱っていることだ。ダッシュボードでレイテンシのスパイクを見つけ、別窓でトレース検索画面を開き、Time Windowを合わせ、Trace IDをコピペする……この数分間の「コンテキストスイッチ」こそが、MTTR（平均復旧時間）を殺す最大の要因だ。
PrometheusのExemplar（エグゼンプラー）は、単なる機能ではない。メトリクスの集計結果という「統計的な面」の中に、個別のリクエストという「具体的な点」を埋め込む、いわば高次元データへのポータルだ。本稿では、この機能を骨の髄まで掌握し、システムを極限まで効率化するための知見を共有する。
—
1. Exemplarの内部アーキテクチャ：なぜメモリを食い尽くさないのか？
Exemplarは、Prometheusのヒストグラムバケットの中に、特定のトレースに関連するデータ（Trace IDなど）を付加して保持する仕組みだ。
ここで懸念されるのが「メモリ消費」だ。すべてのリクエストを保存すれば、Prometheusは一瞬でOOM（Out of Memory）を起こす。しかし、Exemplarの実装は極めて賢い。「各バケットにつき、最後に観測された1つのサンプルのみを保持する」というリングバッファ的な制約がある。
- 保持戦略: バケットが更新されるたびに古いExemplarは捨てられ、新しいものが上書きされる。
- オーバーヘッド: メモリ消費量はほぼ無視できるレベル（数MB〜数十MBのオーダー）に抑えられる。
- 注意点: 高頻度なスパイクが発生した場合、最も重要な「スパイクの瞬間のトレース」が、後続の高速なリクエストによって上書きされる可能性がある。これを防ぐには、アプリケーション側のサンプリングレートとPrometheusのスクレイピング間隔のバランスを極限までチューニングする必要がある。
—
2. 実装の神髄：OpenTelemetryによる「自動注入」の自動化
Exemplarを機能させるには、アプリケーションが `OpenTelemetry` などを通じて、ヘッダーにTrace IDを乗せ、Prometheusのクライアントライブラリがそれをメトリクスデータに含める必要がある。
Go言語での実装例（最小構成）
手動でExemplarを付加するのは愚策だ。OpenTelemetryのSDKを使い、メトリクス生成時にTraceContextを自動伝播させるのが正解だ。
// OpenTelemetryを用いたExemplar対応メトリクスの宣言例
histogram := meter.Float64Histogram(
“http_request_duration_seconds”,
metric.WithDescription(“HTTPリクエストレイテンシ”),
)
// コンテキストからTrace IDを自動的に抽出してExemplarとして付与される
// この時、Spanが有効である必要がある
histogram.Record(ctx, duration, metric.WithAttributes(
attribute.String(“endpoint”, “/api/v1/data”),
))
—
3. Prometheusの有効化と最適化ハック
PrometheusでExemplarを有効にするには、`–enable-feature=exemplar-storage` をフラグに加えるだけだが、真のプロフェッショナルは「保存期間」と「サイズ」を最適化する。
prometheus.yml
global:
# Exemplarの保持時間はメトリクスの保持期間とは独立して制御可能
# デフォルトは1時間。スパイク調査が翌日になることが多いなら、これを調整せよ
exemplars:
max_exemplars: 10000 # 必要に応じてバッファを拡張
極限のヒント:
Exemplarのストレージが肥大化しすぎるのを防ぐため、特定の高トラフィックなメトリクスのみに絞るべきだ。すべてのメトリクスにExemplarをつけるのはアーキテクチャの敗北である。「レイテンシのヒストグラム」と「エラー率のカウンター」、この2点にのみ絞り込め。
—
4. Grafanaとの融合：ワンクリック・ジャンプの魔術
GrafanaでExemplarを表示するには、Data Sourceの設定で「Exemplars」を有効にする必要がある。ここで重要なのはURLのテンプレート化だ。
Exemplar URL Patternの例 (Grafana設定)
$trace_id は自動的にExemplarから抽出される
/explore?orgId=1&left=%5B%22now-1h%22,%22now%22,%22Tempo%22,%7B%22query%22:%22$trace_id%22%7D%5D
これにより、Grafanaのグラフ上の「点（Exemplar）」をクリックするだけで、TempoやJaegerのトレース詳細画面へダイレクトに遷移する。もはやログ検索のクエリを手打ちする必要はない。
—
5. アーキテクトの視点：自動化された「障害予兆検知」へ
単にクリックして調査するだけでは足りない。真のDevOpsは、「Exemplarが存在する場所を自動で特定」する。
PrometheusのAPIを叩き、Exemplarの有無を監視するスクリプトをCI/CDパイプラインに組み込め。
Exemplarが含まれるメトリクスをAPI経由で抽出する独自スニペット
curl -G ‘http://prometheus:9090/api/v1/query_exemplars’ \
–data-urlencode ‘query=http_request_duration_seconds’ \
–data-urlencode ‘start=2023-10-27T00:00:00Z’ \
–data-urlencode ‘end=2023-10-27T23:59:59Z’ | jq ‘.data’
このAPIを活用すれば、「エラー率がしきい値を超えた時、直近のExemplarからTrace IDを抜き出し、関連するエラーログをSlackに自動通知する」という、人間を介在させない自律的な障害調査基盤を構築できる。
—
結び：技術の真髄は「繋ぐ」ことにある
監視ツールが増えるほど、システムは分断される。Exemplarは、その分断された世界を「メトリクスとトレースを同じ文脈で語る」ことで統合する接着剤だ。
あなたが構築すべきは、単なる監視ダッシュボードではない。エンジニアが「何が起きたか？」を直感的に把握し、数秒でコードの修正箇所にたどり着ける「思考の拡張デバイス」だ。PrometheusとExemplarを使い倒し、観測の解像度を極限まで高めよ。それが、システムを支配する唯一の道である。