필사 모드: 分散トレーシング & OpenTelemetry 2026 — OTel / Jaeger / Tempo / Zipkin / Honeycomb / Lightstep / SigNoz / SkyWalking / Datadog APM 徹底比較

プロローグ — 「なぜ決済が遅いのか？」という問いから

2026年の金曜夜。決済チームの Slack にアラートが鳴る。

> 「p99 決済レイテンシ 4.2 秒。普段は 600ms。何が遅くなったのか？」

この問いに 5 分で答えるために、人類は過去 10 年間 **分散トレーシング(distributed tracing)** を作り続けてきた。1 つのリクエストがゲートウェイを抜け、認証を経て、決済コアに入り、外部 PG を呼び出して、領収書キューに積まれる — その全ホップを 1 本のトレースで見る。

2020 年当時、この領域は OpenTracing、OpenCensus、Jaeger クライアント、Zipkin ライブラリ、各 APM ベンダーのエージェントが乱立していた。同じ会社の中でも Java は Datadog、Go は Jaeger、Node は New Relic というのが普通だった。2026 年の答えはシンプルだ — **OpenTelemetry**。

本稿は 2026 年の分散トレーシングの地図を描く。OTel 仕様と Collector、伝搬標準、OSS バックエンド(Jaeger / Tempo / Zipkin)、observability 2.0(Honeycomb / SigNoz)、買収された巨人(Lightstep)、APM スーパーリーグ(Datadog / New Relic / Dynatrace / Splunk)、eBPF 自動計装(Pixie / Beyla)、そしてサンプリングと費用まで。韓国・日本企業が実際にどう移行したかも触れる。

1. 2026 年の分散トレーシング地図 — 4 区分

エコシステムは大きく **4 つのまとまり** に分かれる。

| 区分 | 代表 | 性格 |

| --- | --- | --- |

| 標準・計装 | **OpenTelemetry** | 共通仕様・SDK・Collector。ほぼ全員がここを通る |

| OSS セルフホスト | Jaeger、Tempo、Zipkin、SigNoz、SkyWalking | 自分で運用。ライセンス費なし |

| APM SaaS | Datadog、New Relic、Dynatrace、Splunk、AppDynamics、Sentry、Elastic | マネージド。統一 UI + アラート + AIOps |

| observability 2.0 | Honeycomb、Lightstep(ServiceNow) | ワイドイベント・高カーディナリティ分析 |

| eBPF 自動計装 | Pixie、Beyla、Coroot | コード変更なし・カーネル/ネットワーク層 |

3 軸を 1 枚で見る。

OSS SaaS

+--------------+ +-----------------+

計装 | OTel SDK | -- 互換 --- | OTel SDK |

| (ベンダー中立)| | (ベンダーアダプタ) |

+------+-------+ +--------+--------+

| |

+------v-----------------------------------v-----+

| OpenTelemetry Collector |

| receivers --> processors --> exporters |

+------+-----------------------------------+----+

| |

+-------v--------+ +--------v--------+

| Jaeger / Tempo | | Datadog APM |

| Zipkin / SigNoz| | New Relic APM |

| SkyWalking | | Honeycomb 等 |

+----------------+ +-----------------+

要点: **計装は OTel に統一し、バックエンドは差し替え可能にする。** これが 2026 年の標準姿勢だ。

2. OpenTelemetry — CNCF Graduated (2024)

OpenTelemetry(OTel)は OpenTracing(2016)と OpenCensus(2018)の合併として 2019 年に発足した。2021 年に CNCF Incubating、**2024 年 11 月に CNCF Graduated** へ昇格。事実上の業界標準になった。Kubernetes に次ぐ規模の CNCF プロジェクトだ。

OTel が提供するもの:

- **仕様(Specification)**: トレースとは、スパンとは、どんな属性を持つか。

- **API**: 言語別の計装 API(Java、Go、Python、.NET、Node.js、Ruby、PHP、Rust、C++、Swift など)。

- **SDK**: API の参照実装 — サンプリング、バッチ、エクスポータ込み。

- **Collector**: 別プロセスで動くテレメトリーパイプライン。

- **Semantic Conventions**: HTTP、DB、メッセージングなどの標準属性名。

- **OTLP**(OpenTelemetry Protocol): gRPC / HTTP のワイヤーフォーマット。

データモデルの中核: **トレースはスパンのツリー**。各スパンは `trace_id`、`span_id`、`parent_span_id`、開始・終了、属性、イベント、リンクを持つ。

from opentelemetry import trace

from opentelemetry.sdk.trace import TracerProvider

from opentelemetry.sdk.trace.export import BatchSpanProcessor

from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter

trace.set_tracer_provider(TracerProvider())

trace.get_tracer_provider().add_span_processor(

BatchSpanProcessor(OTLPSpanExporter(endpoint="otel-collector:4317"))

)

tracer = trace.get_tracer("checkout")

with tracer.start_as_current_span("charge_card") as span:

span.set_attribute("user.id", user_id)

span.set_attribute("amount", amount)

result = pg.charge(...)

span.set_attribute("pg.response_code", result.code)

OTel の真価は、**メトリクス・ログ・トレースを同じ SDK** で扱うところにある。トレースは Graduated 安定、メトリクスも安定、ログは 2024〜2025 年に多くの言語で安定段階に達した。OTel はもはや単なるトレース標準ではなく、**統合テレメトリー標準** だ。

3. OTel Collector — Receivers・Processors・Exporters

OTel SDK がアプリの中に入るなら、**Collector** はアプリの外で動く別プロセス。分離する理由は:

1. アプリにベンダーバックエンドの SDK を入れずに済む — 依存衛生がよくなる。

2. サンプリング・フィルタ・ルーティングを **集中で** 適用できる。

3. バックエンドを変えてもアプリを再起動しなくていい。

4. トラフィック急増時のキューイング・再試行。

Collector の 3 軸:

| コンポーネント | 役割 | 例 |

| --- | --- | --- |

| **Receivers** | 受信 | otlp、jaeger、zipkin、prometheus、kafka、filelog |

| **Processors** | 加工・変換・フィルタ・サンプリング | batch、memory_limiter、tail_sampling、attributes |

| **Exporters** | 送信 | otlp、jaeger、prometheus、datadog、honeycomb、logging |

この 3 軸をパイプラインでつなぐ。

receivers:

otlp:

protocols:

grpc:

endpoint: 0.0.0.0:4317

http:

endpoint: 0.0.0.0:4318

processors:

batch:

timeout: 5s

send_batch_size: 1024

memory_limiter:

check_interval: 1s

limit_mib: 1500

tail_sampling:

decision_wait: 30s

policies:

- name: errors

type: status_code

status_code: { status_codes: [ERROR] }

- name: slow

type: latency

latency: { threshold_ms: 1000 }

- name: sample_10

type: probabilistic

probabilistic: { sampling_percentage: 10 }

exporters:

otlp/tempo:

endpoint: tempo:4317

tls: { insecure: true }

datadog:

api: { site: datadoghq.com, key: ENV_DD_API_KEY }

service:

pipelines:

traces:

receivers: [otlp]

processors: [memory_limiter, tail_sampling, batch]

exporters: [otlp/tempo, datadog]

**同じトレースを OSS バックエンド(Tempo)と SaaS(Datadog)に同時** に送れる。これが Collector を移行ツールとして使う理由 — 行を 1 本足して並列で比較し、検証してから元を切る。

Collector の 2 モード:

- **Agent**: 各ホスト/ノード/Pod サイドカーに 1 つ。少量・近距離の収集。

- **Gateway**: クラスタ/リージョンに数台。バッファリング・テールサンプリング・中央ポリシー向け。

大規模では **Agent → Gateway → バックエンド** の 2 段構成が多い。

4. 伝搬標準 — W3C Trace Context・B3・Baggage

分散トレーシングが「分散」であるのは、同じ `trace_id` が **サービス境界を越えて伝搬** するからだ。伝搬は通常 HTTP ヘッダで行う。

W3C Trace Context (2020 勧告)

2020 年に W3C が標準化した 2 つのヘッダが 2026 年のデファクトだ。

traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01

| | | |

| trace-id (16 byte hex) parent-span-id trace-flags

version

tracestate: vendor1=value1,vendor2=value2

- `traceparent`: すべての OTel SDK が標準で送受信する。

- `tracestate`: ベンダー固有の付加情報(例: サンプリング決定)。

OTel SDK は HTTP・gRPC・メッセージング(Kafka・RabbitMQ ヘッダ)・一部の SQL コメントにまでこのヘッダを自動注入する。

B3 Propagation (Zipkin 系)

Zipkin が作ったマルチヘッダ形式。

X-B3-TraceId: 4bf92f3577b34da6a3ce929d0e0e4736

X-B3-SpanId: 00f067aa0ba902b7

X-B3-ParentSpanId: 05e3ac9a4f6e3b90

X-B3-Sampled: 1

OTel は W3C と B3 を両方サポート。レガシーシステムと混じる場面では両方を受けられるようにする。

Baggage — 「次のサービスへ一緒に運ぶコンテキスト」

Baggage は trace_id とは別のキー・バリューをトレース伝搬とともに運ぶ。例: `user.tier=gold`、`tenant=acme`、`experiment=ab_42`。

baggage: user.tier=gold,tenant=acme

使いどころ:

- すべての下流スパンに同じラベルを自動で付けたいとき。

- baggage の値で動的にサンプリングを変えたいとき(例: 「tenant=enterprise は 100% サンプル」)。

- 下流で権限・ロギング・ルーティングに参照する。

注意: **baggage は秘密ではない。** 次のホップが外部システムだとヘッダが見える。PII は絶対に baggage に入れない。

5. Jaeger — CNCF Graduated、Uber 出身のクラシック

Jaeger は Uber が 2015 年に作った分散トレーシング。2017 年 CNCF Incubating、**2019 年 CNCF Graduated**。OTel 以前のデファクト標準だった。

特徴:

- Go 製、バックエンドはモジュール式。

- ストレージ: Cassandra、Elasticsearch / OpenSearch、ClickHouse、Badger(組込)。

- UI: トレースビュー、依存関係グラフ、比較ビュー。

- 取り込み: 自前 SDK(非推奨)・Zipkin プロトコル・**OTLP**。

2024 年以降、Jaeger プロジェクトは明示的に **「OTel ファースト」** に舵を切った。Jaeger 独自 SDK は非推奨で、新規ユーザーには OTel SDK を勧め、Jaeger は「バックエンド + UI」として使うのが推奨経路だ。v2 バックエンドは内部的に OTel Collector をベースにビルドされている。

デプロイ形:

- **AllInOne**: agent + collector + query + UI + memory storage を 1 コンテナに。デモ/開発用。

- **Production**: collector + storage + query/UI を分離、agent はホスト別。

- **Kubernetes Operator**: jaegertracing/jaeger-operator で CR 一行。

長所: 軽量、OSS、導入が容易、UI が直感的。

弱点: メトリクス/ログはやらない(トレース専用)。高カーディナリティ分析は弱め。UI は trace_id 検索と時間範囲フィルタが主体。

6. Grafana Tempo — Parquet ベース、「オブジェクトストレージがホットパス」

Grafana Tempo は 2020 年に Grafana Labs が作ったトレースバックエンド。コンセプトが明確だ — **「インデックスのないトレースストア」**。

従来の Jaeger / Zipkin は全スパンにインデックス(サービス、オペレーション、タグ)を作る。インデックスがスパン本体より大きく、コストも高い。Tempo はインデックスを作らず、**trace_id でのみ検索** する — ただし、メトリクス(Prometheus)・ログ(Loki)から trace_id を取り出して繋ぐ前提だ。「exemplar をクリックすればトレースが出る」UX。

ストレージは **S3 / GCS / Azure Blob のようなオブジェクトストレージに直接**。インデックスがないので保存が安い。2023 年以降はディスクフォーマットが **Parquet** に統一された。カラムナで圧縮が効き、外部ツール(Athena、DuckDB)からも読める。

クエリ言語 **TraceQL** もある — トレース本体の中でパターンを探す。

{ resource.service.name = "checkout"

&& span.http.status_code = 500

&& duration > 1s

}

長所:

- **保存コストが最安** — オブジェクトストレージ直書き。

- Loki・Mimir・Grafana と自然に連携。

- Parquet なので外部分析ツールに持っていける。

弱点:

- 「メトリクス/ログとトレースを exemplar で繋ぐ」運用がないと価値が落ちる。

- 一般検索(サービス名・タグ)は Jaeger より弱い(代わりに TraceQL)。

**大規模・長期保存が最優先なら Tempo が答え。**

7. Zipkin — Twitter 原典、生きているクラシック

Zipkin は Twitter が 2012 年にオープンソース化した分散トレーシング。Google Dapper 論文の最も影響力のある OSS 実装で、後続のすべてのトレーシングシステムの出発点となった。

特徴:

- Java ベース(Brave 計装)。

- ストレージ: メモリ(開発用)、Cassandra、Elasticsearch、MySQL。

- シンプル — 単一 jar で動く。

- B3 伝搬の起源。

2026 年で新規採用は多くないが、以下では今も現役だ。

- 既存の B3 / Brave Java コードベースのバックエンド。

- 「Jaeger でも重い」と感じる小規模システム。

- OTel Collector の zipkin receiver / exporter による変換ハブ。

Jaeger と比べると、UI は地味だがセットアップはより簡単。

8. Honeycomb — Charity Majors の「observability 2.0」

Honeycomb は 2016 年に Charity Majors と Christine Yen が創業した SaaS オブザーバビリティ会社。彼女らが定着させた **「observability 2.0」** という表現が業界の語彙を変えた。

主張: 従来のモニタリング(メトリクス・ログ・トレース分離)は事前に決めた次元しか見えない。実際のデバッグに必要なのは **高カーディナリティ次元(user_id、request_id、k8s_pod 等)を自由にスライス/ダイス** できる **ワイドイベント(wide event)** だ。

Honeycomb のデータモデル: すべてのスパンが実質「イベント」。自由に属性を付け、クエリは **BubbleUp**(異常自動分解)・**ヒートマップ**・**トレースビュー** を行き来する。

BubbleUp の結果例:

遅いリクエスト(p95)の 73% が user.tier=enterprise かつ

db.host=replica-3 かつ

client_country=JP である。

← この組み合わせを人が事前に指定しなくても自動で見つける。

差別化要素:

- **すべての次元にインデックスを作らない** — 自前のカラムナストア(Retriever)。

- サンプリング SDK(Refinery) — テールサンプリングのデファクト。

- OTel 100% 互換取り込み。

- 料金: イベント数(スパン数)・保存期間。

長所: デバッグ速度が違う。「なぜ遅いか」をインデックスなしで 1〜2 分で絞れる。

弱点: SaaS のみ(セルフホスト不可)。単純な監視で高カーディナリティが要らないならオーバースペック。

9. Lightstep → ServiceNow Cloud Observability

Lightstep は Google Dapper 共著者の Ben Sigelman が 2014 年に創業した会社。「統計的分析」「メトリクスとトレースの融合」を早くから掲げていた。

2021 年に ServiceNow が買収。現在は **ServiceNow Cloud Observability** にリブランド。単独製品としては影が薄くなったが、ServiceNow の ITSM/AIOps とセットでエンタープライズ市場(特に ITIL・CMDB と絡む場所)で生き残っている。

技術的遺産:

- OTel 初期の標準化に中心的役割(Sigelman は OTel ガバナンス委員)。

- トレースに対する統計的ノイズ低減を早くから推した。

2026 年の評価: ServiceNow エコシステムの中にいる会社なら検討。そうでなければ Honeycomb・Datadog・OSS 陣営の方が活発だ。

10. SigNoz — OSS フルスタック・オブザーバビリティ

SigNoz は 2020 年にインド発のオープンソース APM。ClickHouse の上にトレース・メトリクス・ログを全部のせる。**「Datadog の OSS 代替」** をうたう。

特徴:

- 100% OTel ネイティブ — OTel Collector をほぼ SDK のように扱う。

- 単一 UI でトレース/メトリクス/ログ/例外。

- ClickHouse ベース — クエリが速く、保存も圧縮効率が高い。

- 2024 年シリーズ B 資金調達 — LogStream・Anomaly Detection・メトリクス v2 をリリース。

`docker-compose up` 一発でフルスタックが立ち上がり、OTel 互換なので移行が比較的スムーズ。

2024〜2025 のアップデート:

- **LogStream**: ログも同じ UI で検索・フィルタ。

- **Anomaly Detection**: ML ベースの異常検知(ベースライン自動)。

- **Trace Funnels**: 決済のような多段フローのステップ別成功率。

長所: OSS なのに UI が洗練されていてフルスタック。クラウド SaaS もあり、セルフホストが負担なら一方に逃げられる。

弱点: ClickHouse 依存が強く、大規模運用にはノウハウが要る。エンタープライズ機能(SSO、SOC2 レポート等)はクラウドプランに偏る。

11. Apache SkyWalking — APM + トレース、中国主導

Apache SkyWalking は 2017 年 Apache Incubating、2019 年に Graduated した OSS APM。中国系のコントリビュータ(華為・アリババ・テンセント)が厚く、東アジア圏でユーザーが多い。

特徴:

- 自前エージェント(Java、.NET、Node) + OTel 互換。

- トレースだけでなく **サービストポロジ・メトリクス・ログ・イベント** をすべて。

- バックエンド: 自前 OAP サーバ + Elasticsearch / BanyanDB(自前時系列 DB)。

- UI: トポロジ可視化が強い。

- サービスメッシュ(Istio)可視化、イベント駆動の自己修復(SkyWalking-Rover、eBPF)などの拡張。

2026 年の立ち位置: 中国・インド・東南アジアの OSS 陣営のメイン選択肢。韓国・日本では相対的に少ないが、中国法人を運営する企業なら自然に出会う。

12. Datadog APM / New Relic APM / Elastic APM / Sentry Performance

商用 APM スーパーリーグのトレース陣容。

Datadog APM

- 市場シェア最大。UI の完成度が圧倒的。

- OTel ネイティブ入出力 — `dd-trace` もあるが OTel SDK 直も対応。

- トレース + APM メトリクス(throughput・error・latency) + プロファイリング連結。

- 料金: ホスト単価 + 取り込みスパン課金で分離。大規模トラフィックでは請求書が怖くなる。

- Watchdog(AIOps)、Continuous Profiler、Database Monitoring へ連結。

New Relic APM

- 1 世代目 APM(2008)の元祖。2020 年代に **「Telemetry Data Platform」** へ再ポジショニング。

- 2020 年に料金体系大改革 — ユーザー単価 + 取り込み GB 単価へ単純化。

- OTel 互換、OTel オンリー運用も可能。

- New Relic AI、ログ・トレース自動結合。

Elastic APM

- Elasticsearch の上に乗せた APM。ELK スタックを既に使っている現場なら自然。

- セルフホスト・Elastic Cloud の両方。

- OTel + OSS バックエンドより高くなりにくく、検索・ダッシュボード・ML が統合される。

Sentry Performance

- Sentry は元々エラーモニタリング会社。2020 年頃に **Performance(分散トレーシング)** を追加。

- 強み: フロントエンドとの結合。React / Vue 等のクライアント SDK のトレースがそのままバックエンドへ繋がる。

- バックエンド専用 APM としては弱いが、フルスタック(特に SPA フロント)は強い。

13. Dynatrace / AppDynamics (Splunk) / Splunk Observability Cloud

エンタープライズ重量級。

Dynatrace

- 1993 年創業のオーストリア企業。エンタープライズ APM の巨人。

- 自前エージェント **OneAgent** がインストールした瞬間に自動でトポロジ・メトリクス・トレースを作る — 人手はほぼ不要。

- AI エンジン **Davis** が原因候補を自動提示。

- OTel 入力にも対応。

- 料金: エンタープライズ。ROI が大きい環境(グローバル大型運用)向き。

AppDynamics (Splunk 傘下)

- 2017 年に Cisco が買収、2024 年に Cisco が Splunk を買収したため、AppDynamics は **再び Splunk 傘下** に。

- Java・.NET に強い。ビジネストランザクション中心ビュー。

- 2025〜2026 のロードマップでは Splunk Observability Cloud へ段階的に統合される方向。

Splunk Observability Cloud

- 2019 年の SignalFx 買収で生まれたライン。メトリクス・トレース・ログ + RUM(real-user monitoring)。

- Cisco の Splunk 買収(2024)以降、SignalFx と AppDynamics の遺産を 1 つの SKU に統合する作業が進行中。

- Cisco + Splunk を既に使っている現場には強い候補。

14. eBPF トレーシング — Pixie と Beyla、コード変更なしの自動計装

**eBPF** は Linux カーネル内で安全にコードを実行する技術。ネットワークパケット・システムコール・HTTP リクエストをカーネル層で捕捉できる — **アプリのコードを 1 行も変えずに**。

Pixie

- 2019 年に開始、2021 年に New Relic が買収。その後 OSS として CNCF Sandbox(2021)、**2023 年に Incubating**。

- Kubernetes に DaemonSet として入れると、HTTP / HTTPS / gRPC / DNS / MySQL / Postgres / Redis 等のリクエストを自動キャプチャ。

- データはノード内インメモリに留まり(デフォルト 24h)、必要なときだけ外に出す — プライバシー・コスト面で有利。

- クエリ言語は **PxL**(Python ライク)。

Beyla — Grafana の eBPF 自動計装

- Grafana Labs が 2023 年に発表。2024 年 GA。

- 単一バイナリ・サイドカーで入り、eBPF で HTTP / gRPC を捕捉して **OTel スパン** として出す。

- セルフホスト OTel + Tempo スタックに最もスムーズに刺さる。

eBPF トレーシングの位置

- **コード変更なしの高速可視化** が要る場面 — ポリグロット環境、レガシーコード、「今この瞬間どこが遅いか」の即時把握。

- 弱点: **ビジネスコンテキスト(user_id など)** は取れない。eBPF が見るのはネットワークペイロード — アプリがその中に ID を入れなければ見えない。

結論: **eBPF + OTel SDK の両方を併用するのが定石**。eBPF でインフラ・ネットワーク層の自動可視化、OTel SDK でビジネススパン・高カーディナリティ属性。

15. サンプリング — head vs tail vs ratio

トレース費用 = 生成スパン数 × 単価。費用カーブの 8 割以上は **サンプリング戦略** で決まる。

3 つの戦略:

Head-based サンプリング

- トレースの **開始時** に決定。決定結果を traceparent の trace-flags で伝搬。

- 決定材料が少ない(まだ何が起きるか分からない)。

- 長所: シンプル、コスト予測が容易、SDK だけで可能。

- 通常 1〜10% の固定比率で流す。

Ratio サンプリング

- Head サンプリングの下位分類。例: `sample_ratio=0.1`(10%)。

- OTel SDK デフォルト(TraceIdRatioBased)。

- 一貫性保証: trace_id ハッシュで決定 → 同じトレースは全サービスで同じ決定。

Tail-based サンプリング

- トレースが **終わったあと**(または一定時間待った後)に決定。

- 全スパンをまず Collector に集めて見る — 決定材料(エラー有無、合計レイテンシ、特定属性)が豊富。

- 長所: **エラーと遅いトレースを 100% 保存**、正常は 1% だけ。費用対価値が最高。

- 弱点: 決定までキューイングが要る(通常 30 秒〜数分)、メモリ・CPU を消費、**同じトレースの全スパンが同じ Collector インスタンスへ届かねばならない**(load balancing exporter で trace_id ハッシュルーティング)。

OTel Collector `tail_sampling` プロセッサの例:

processors:

tail_sampling:

decision_wait: 30s

num_traces: 100000

policies:

- name: keep_errors

type: status_code

status_code: { status_codes: [ERROR] }

- name: keep_slow

type: latency

latency: { threshold_ms: 1500 }

- name: keep_enterprise

type: string_attribute

string_attribute: { key: tenant.tier, values: [enterprise] }

- name: random_2pct

type: probabilistic

probabilistic: { sampling_percentage: 2 }

このポリシーは: エラー 100% + 1.5 秒超 100% + enterprise テナント 100% + 残りの 2% のみ保持。

どれを選ぶか

| 状況 | 推奨 |

| --- | --- |

| 小規模(数百 rps) | Head 100% または ratio 50% |

| 一般的 SaaS(数千 rps) | Head 10% + エラー 100%(SDK で分岐) |

| 大規模(数万〜数十万 rps) | Tail-based + エラー/遅い/特定テナント 100% |

| 費用が爆発中 | Tail-based を即導入 — 通常 5〜10 倍削減 |

16. 費用 — テールサンプリングプロキシと請求書

分散トレーシングの請求書が怖くなる 2 つのパターン。

1. **トラフィック増加に比例した請求書** — 100% サンプル + 大規模トラフィック。

2. **高カーディナリティ属性の爆発** — 全スパンに user_id、request_id、k8s_pod、container_id を貼る。

対処:

- **テールサンプリングを Gateway Collector に置く。** SaaS に入る前にカットする。同じトレースの全スパンを同じ Collector に届けるため、前段に `loadbalancing` exporter を置く。

- **保存は OSS、「ホット」トレースだけ SaaS。** すべてのトレースを Tempo へ送り、エラー・遅いだけ Honeycomb / Datadog に追加送信。

- **属性ホワイトリスト**。`attributes` プロセッサで使わない属性を削除する。

- **ログ・トレース連結でトレース本体を細くする**。長くて大きい属性はログに置き、スパンには log_id 参照のみ。

実戦経験値(著者の保守的見積もり):

- 無理な 100% → 1% head サンプル = 請求書 90% 減、デバッグ品質 30% 減。

- 1% head → テールサンプル(エラー 100% + 正常 1%)= 請求書同じ、デバッグ品質 200% 増。

- Gateway Collector + ホワイトリスト追加 = 請求書をさらに 30% 減。

17. 韓国 / 日本 — 実例

韓国

- **トス(Toss)** — 自前のトレースインフラ(Kafka Consumer + Spring Sleuth)から 2023〜2024 年にかけて OTel + Tempo + Grafana スタックへ段階移行。決済・送金トラフィックのテールサンプリングで費用を抑えた。Toss SLASH カンファレンスで関連発表がある。

- **カカオ(Kakao)** — 社内 APM から OTel 標準化へ移行。KakaoTalk のバックエンドは Java スタックなので、OTel Java agent の自動計装 + 一部コアサービスのみ手動計装の組み合わせ。if(kakao) カンファレンスにトレーシング事例が時々登場。

- **NAVER** — 社内モニタリング基盤 `nLog`、`Pinpoint` といった自前ツールに OTel 互換インターフェースを追加する方向。Pinpoint は NAVER 製の OSS APM(Java バイトコード計装が強み)で、自ら OTel exporter を追加して標準に合流。

日本

- **メルカリ** — Datadog から OTel + 自前バックエンドの組み合わせへ移行した事例を Mercari Engineering ブログが公開。トラフィック費用が主要動機で、OTel Collector + テールサンプリングで請求書を抑えた。

- **NTT コミュニケーションズ** — 社内マルチクラウド監視プラットフォームに OTel を採用。Datadog / New Relic / SkyWalking 混在環境を OTel で一元化 — 韓国でいえば SK テレコム・KT のような通信キャリアのモニタリング部門の重厚事例。

- **CyberAgent / DeNA / LINE** — ゲーム・メディア・メッセンジャートラフィック特性上、テールサンプリング・高カーディナリティ分析の要件が高く、Honeycomb / Datadog + OSS セルフホスト(Tempo・Jaeger)のハイブリッド。

共通パターン: **ベンダーロックインを避けるため、SDK は OTel、バックエンドは差し替え可能に**。SaaS の単価交渉も OTel 互換が武器になる。

18. 誰が何を選ぶべきか

小さなチーム / サイドプロジェクト

- **OTel SDK + Jaeger(AllInOne)あるいは SigNoz**(セルフホスト)、または **Honeycomb Free / Sentry Performance**。

- 立ち上げ 30 分、費用は 0〜数万円。

中規模(数十名、数万〜数十万 rps)

- **OTel SDK + Collector + Tempo + Grafana**(OSS フルスタック)。費用はインフラのみ。

- あるいは **Datadog / New Relic APM**(SaaS、適用が速くアラートが統合済み)。

- 安全な移行パターンは、両方を OTel Collector で **並走** させて片方に絞ること。

エンタープライズ

- **Dynatrace / Splunk Observability Cloud / Datadog** — 自動トポロジ・AIOps・全社アラート・監査ログ。

- **OTel 互換は必須条件**。OTel オンリーで受けるようベンダーと交渉する。

デバッグ優先(高カーディナリティ・オンデマンド分析)

- **Honeycomb** — observability 2.0 の姿勢。費用はイベント数・保存期間ベース。

- SigNoz が OSS で近い方向を追いかける。

セルフホスト強制(規制・セキュリティ)

- **OTel + Tempo / Jaeger / SigNoz / SkyWalking**。SigNoz はフルスタック(トレース + メトリクス + ログ + イベント)、Tempo + Loki + Mimir は Grafana 陣営の分離型。

Kubernetes ポリグロット + コード変更が難しい

- **Pixie または Beyla** — eBPF で自動可視化。ビジネススパンは OTel SDK で追加。

19. アンチパターン 10 選

1. **OTel を使わずベンダー SDK を直結** — ベンダー切替時にコードを総書換。

2. **計装はしたがサンプリングが 100% のまま** — 請求書が爆発。

3. **テールサンプリングなしで「エラーは全部見たい」** — head 1% サンプルでは 99% のエラーが消える。

4. **すべてのスパンに user_id・request_id を無差別に貼る** — 高カーディナリティ請求に直結。

5. **W3C と B3 の併用を忘れる** — レガシーサービス境界でトレースが切れる。

6. **Baggage に PII を入れる** — 次のホップでヘッダから漏洩。

7. **メトリクス・ログ・トレースのバックエンドが分断され trace_id 連結なし** — exemplar 運用が崩壊。

8. **Collector を置かず SDK から直接 SaaS へ** — バックエンド切替でアプリ総デプロイ。

9. **テールサンプリングの trace_id ルーティングを無視** — 同じトレースが複数 Collector に分散し決定が誤る。

10. **トレースだけ見てメトリクス・ログを見ない** — トレースは「特定リクエストの物語」、メトリクスは「全体の傾向」。両方必要。

エピローグ — OTel の上に自由を建てる

2026 年の教訓は一文だ。

> **計装は OTel に統一し、バックエンドは差し替え可能にする。**

OTel は単なるトレース標準ではなく、**ベンダーロックインを断つインターフェース** だ。その上に — Jaeger / Tempo の OSS の自由でも、Honeycomb のデバッグの深さでも、Datadog の統合 UX でも、Dynatrace の AIOps でも — 自分に合うバックエンドを乗せる。差し替えコストがコード書換ではなく Collector の設定一行になった瞬間、交渉力もコスト管理もデバッグ品質も全部手に入る。

次回候補: **OpenTelemetry メトリクス徹底解説 — exemplar と trace-metric 連結**、**ログをトレースに繋ぐ — Loki・OpenSearch・OpenTelemetry Logs**、**テールサンプリング実戦 — load-balancing exporter トポロジと費用カーブ**。

— 分散トレーシング & OpenTelemetry 2026 徹底比較、了。

参考 / References

- [OpenTelemetry — Official site](https://opentelemetry.io/)

- [OpenTelemetry — CNCF graduation announcement (2024)](https://www.cncf.io/announcements/2024/11/opentelemetry-graduates/)

- [OpenTelemetry Specification](https://opentelemetry.io/docs/specs/otel/)

- [OpenTelemetry Collector](https://opentelemetry.io/docs/collector/)

- [OpenTelemetry Collector — GitHub (open-telemetry/opentelemetry-collector)](https://github.com/open-telemetry/opentelemetry-collector)

- [Collector Contrib — tail sampling processor](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/tailsamplingprocessor)

- [W3C Trace Context — Recommendation](https://www.w3.org/TR/trace-context/)

- [W3C Baggage — Specification](https://www.w3.org/TR/baggage/)

- [B3 Propagation — openzipkin/b3-propagation](https://github.com/openzipkin/b3-propagation)

- [Jaeger — Official site](https://www.jaegertracing.io/)

- [Jaeger — CNCF graduated project](https://www.cncf.io/projects/jaeger/)

- [Jaeger v2 announcement](https://www.jaegertracing.io/docs/2.0/)

- [Grafana Tempo](https://grafana.com/oss/tempo/)

- [Tempo — Parquet block format](https://grafana.com/blog/2023/11/06/grafana-tempo-architecture-deep-dive/)

- [TraceQL — Tempo query language](https://grafana.com/docs/tempo/latest/traceql/)

- [Zipkin — Official site](https://zipkin.io/)

- [Honeycomb — Observability 2.0](https://www.honeycomb.io/)

- [Charity Majors — Observability 2.0 manifesto](https://www.honeycomb.io/blog/observability-2-0)

- [Refinery — Honeycomb tail sampling proxy](https://github.com/honeycombio/refinery)

- [Lightstep — now ServiceNow Cloud Observability](https://www.servicenow.com/products/observability.html)

- [SigNoz — Official site](https://signoz.io/)

- [SigNoz — GitHub (SigNoz/signoz)](https://github.com/SigNoz/signoz)

- [Apache SkyWalking](https://skywalking.apache.org/)

- [Datadog APM](https://docs.datadoghq.com/tracing/)

- [New Relic APM](https://newrelic.com/platform/application-monitoring)

- [Elastic APM](https://www.elastic.co/observability/application-performance-monitoring)

- [Sentry Performance Monitoring](https://docs.sentry.io/product/performance/)

- [Dynatrace — distributed tracing](https://www.dynatrace.com/platform/distributed-tracing/)

- [Splunk Observability Cloud](https://www.splunk.com/en_us/products/observability.html)

- [AppDynamics — Cisco/Splunk](https://www.appdynamics.com/)

- [Pixie — eBPF observability for Kubernetes](https://px.dev/)

- [Pixie — CNCF Incubating](https://www.cncf.io/projects/pixie/)

- [Grafana Beyla — eBPF auto-instrumentation](https://grafana.com/oss/beyla-ebpf/)

- [OpenTelemetry — Semantic Conventions](https://opentelemetry.io/docs/specs/semconv/)

- [OpenTelemetry Java agent](https://github.com/open-telemetry/opentelemetry-java-instrumentation)

- [Mercari Engineering — observability migration](https://engineering.mercari.com/en/blog/)

- [Toss SLASH conference — observability talks](https://toss.tech/slash)

- [NAVER Pinpoint — open source APM](https://pinpoint-apm.github.io/pinpoint/)

- [Google Dapper paper (2010)](https://research.google/pubs/pub36356/)