LabHub

ブログ

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

2026-05-16 · 29 分で読めます · #observability#distributed-tracing#opentelemetry#otelcol#jaeger#tempo#zipkin#honeycomb#charity-majors#lightstep#servicenow#signoz#apache-skywalking#datadog-apm#new-relic-apm#elastic-apm#sentry-performance#dynatrace#appdynamics#splunk#pixie#beyla#w3c-trace-context#b3-propagation#baggage#head-based-sampling#tail-based-sampling#deep-dive#japanese

한국어English日本語

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

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 SaaSDatadog、New Relic、Dynatrace、Splunk、AppDynamics、Sentry、Elasticマネージド。統一 UI + アラート + AIOps
observability 2.0Honeycomb、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 が提供するもの:

データモデルの中核: トレースはスパンのツリー。各スパンは 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 → 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

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 は秘密ではない。 次のホップが外部システムだとヘッダが見える。PII は絶対に baggage に入れない。

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

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

特徴:

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

デプロイ形:

長所: 軽量、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
}

長所:

弱点:

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

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

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

特徴:

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

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 である。
  ← この組み合わせを人が事前に指定しなくても自動で見つける。

差別化要素:

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

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

9. Lightstep → ServiceNow Cloud Observability

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

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

技術的遺産:

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

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

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

特徴:

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

2024〜2025 のアップデート:

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

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

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

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

特徴:

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

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

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

Datadog APM

New Relic APM

Elastic APM

Sentry Performance

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

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

Dynatrace

AppDynamics (Splunk 傘下)

Splunk Observability Cloud

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

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

Pixie

Beyla — Grafana の eBPF 自動計装

eBPF トレーシングの位置

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

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

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

3 つの戦略:

Head-based サンプリング

Ratio サンプリング

Tail-based サンプリング

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 を貼る。

対処:

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

17. 韓国 / 日本 — 実例

韓国

日本

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

18. 誰が何を選ぶべきか

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

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

エンタープライズ

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

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

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

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

原文を読む: https://www.youngju.dev/blog/culture/2026-05-16-distributed-tracing-opentelemetry-2026-otel-jaeger-tempo-zipkin-honeycomb-lightstep-signoz-skywalking-datadog-apm-deep-dive.ja

コメント

まだコメントはありません。

ログインするとコメントできます