分散トレース比較：Jaeger vs Zipkin vs OpenTelemetry Collector で分散トレースを実装する

マイクロサービス・Kubernetesアーキテクチャで「どのサービスがボトルネックか」「リクエストが失敗した原因はどこか」を特定するには、**分散トレーシング（Distributed Tracing）**が必須です。Jaeger（CNCF卒業・Uber発祥）・Zipkin（Twitter発祥・最古のOSS分散トレーサー）・OpenTelemetry Collector（ベンダー中立の標準・現代の基盤）の3つが2026年のOSS分散トレーシング主要ツールです。

分散トレーシングが必要な理由

• 根本原因分析: マイクロサービス間のレイテンシ（Span）を可視化して「どのサービスが遅いか」を特定
• 依存関係マップ: サービス間の呼び出し関係を自動生成してアーキテクチャを把握
• P99レイテンシ追跡: 通常は高速でも高レイテンシになる特定リクエストの原因を特定
• エラー伝播: 1つのサービスの障害が他のサービスにどう影響するか（カスケード障害）を追跡

主要ツールの概要

Jaeger

2017年公開（CNCF/Uber）、Go製のOSSです。GitHubスター20k+。CNCF卒業プロジェクトの代表的な分散トレーシングシステムで、サービスごとのSpan収集・トレースUI・依存グラフ・ホットロードサンプリング設定を提供します。Elasticsearch/Cassandra/Kafkaをバックエンドに使用可能です。

# docker-compose.yml: Jaeger All-in-One（開発・中小規模）
version: "3.8"
services:
  jaeger:
    image: jaegertracing/all-in-one:latest
    restart: unless-stopped
    ports:
      - "16686:16686"  # Jaeger UI
      - "4317:4317"    # OTLP gRPC（OpenTelemetry）
      - "4318:4318"    # OTLP HTTP
      - "14268:14268"  # Jaeger HTTP Thrift
      - "6831:6831/udp" # Jaeger UDP（Compact Thrift）
    environment:
      COLLECTOR_OTLP_ENABLED: "true"
      SPAN_STORAGE_TYPE: badger  # 組み込みストレージ（開発用）
      BADGER_EPHEMERAL: "false"
      BADGER_DIRECTORY_VALUE: /badger/data
    volumes:
      - jaeger_data:/badger

volumes:
  jaeger_data:

# Python: OpenTelemetryでJaegerにトレースを送信
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
from opentelemetry.sdk.resources import Resource
import httpx

def setup_tracer(service_name: str) -> trace.Tracer:
    '''OpenTelemetry Tracerを設定（JaegerのOTLPエンドポイントにSpanを送信）'''
    resource = Resource.create({'service.name': service_name, 'service.version': '1.0.0'})
    provider = TracerProvider(resource=resource)
    exporter = OTLPSpanExporter(endpoint='http://jaeger:4317', insecure=True)
    provider.add_span_processor(BatchSpanProcessor(exporter))
    trace.set_tracer_provider(provider)
    return trace.get_tracer(service_name)

tracer = setup_tracer('order-service')

async def process_order(order_id: str) -> dict:
    '''注文処理の各ステップをSpanでトレース'''
    with tracer.start_as_current_span('process-order') as span:
        span.set_attribute('order.id', order_id)
        span.set_attribute('service.operation', 'process_order')

        # 在庫確認（子Span）
        with tracer.start_as_current_span('check-inventory') as inv_span:
            inv_span.set_attribute('inventory.check', True)
            async with httpx.AsyncClient() as client:
                inv_resp = await client.get(f'http://inventory-service/items/{order_id}')
            inv_span.set_attribute('inventory.status', inv_resp.status_code)

        # 決済処理（子Span）
        with tracer.start_as_current_span('process-payment') as pay_span:
            pay_span.set_attribute('payment.method', 'credit_card')
            async with httpx.AsyncClient() as client:
                pay_resp = await client.post('http://payment-service/charge',
                                             json={'order_id': order_id})
            if pay_resp.status_code != 200:
                span.record_exception(Exception(f'決済失敗: {pay_resp.status_code}'))
                span.set_status(trace.StatusCode.ERROR)
                raise ValueError('決済エラー')

        return {'order_id': order_id, 'status': 'completed'}

Zipkin

2012年公開（Twitter/OpenZipkin）、Java製のOSSです。GitHubスター17k+。分散トレーシングの草分け的OSSで、シンプルなUIとコンパクトな設計が特徴です。B3 Propagation形式（X-B3-TraceId・X-B3-SpanId・X-B3-Sampled HTTPヘッダー）でトレースコンテキストを伝播します。

# docker-compose.yml: Zipkin + Elasticsearch バックエンド
version: "3.8"
services:
  zipkin:
    image: openzipkin/zipkin:latest
    restart: unless-stopped
    ports:
      - "9411:9411"  # Zipkin UI + API
    environment:
      STORAGE_TYPE: elasticsearch
      ES_HOSTS: http://elasticsearch:9200
    depends_on: [elasticsearch]

  elasticsearch:
    image: elasticsearch:8.12.0
    environment:
      discovery.type: single-node
      xpack.security.enabled: "false"
      ES_JAVA_OPTS: "-Xms512m -Xmx512m"
    volumes:
      - es_data:/usr/share/elasticsearch/data

volumes:
  es_data:

OpenTelemetry Collector

2021年公開（CNCF）、Go製のOSSです。GitHubスター4k+（otel-collector本体）。ベンダー中立のテレメトリデータ（トレース・メトリクス・ログ）の収集・変換・エクスポートパイプラインで、アプリケーションはOTLPを使ってCollectorに送信→CollectorがJaeger・Zipkin・DataDog・New Relicなど任意のバックエンドに転送します。

# docker-compose.yml: OpenTelemetry Collector + Jaeger + Prometheus
version: "3.8"
services:
  otel-collector:
    image: otel/opentelemetry-collector-contrib:latest
    restart: unless-stopped
    ports:
      - "4317:4317"   # OTLP gRPC受信
      - "4318:4318"   # OTLP HTTP受信
      - "8889:8889"   # Prometheusメトリクスエクスポート
      - "13133:13133" # ヘルスチェック
    volumes:
      - ./otel-config.yaml:/etc/otel-collector-config.yaml
    command: ["--config=/etc/otel-collector-config.yaml"]

  jaeger:
    image: jaegertracing/all-in-one:latest
    ports:
      - "16686:16686"

  prometheus:
    image: prom/prometheus:latest
    ports:
      - "9090:9090"

# otel-config.yaml: Collectorパイプライン設定
receivers:
  otlp:
    protocols:
      grpc: { endpoint: 0.0.0.0:4317 }
      http: { endpoint: 0.0.0.0:4318 }

processors:
  batch: { timeout: 1s, send_batch_size: 1024 }
  memory_limiter:
    check_interval: 1s
    limit_mib: 400
    spike_limit_mib: 150

exporters:
  jaeger:
    endpoint: jaeger:14250
    tls: { insecure: true }
  prometheus:
    endpoint: "0.0.0.0:8889"
  logging: { loglevel: debug }

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [jaeger, logging]
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [prometheus]

機能比較表

比較項目	Jaeger	Zipkin	OTel Collector
CNCF卒業	✅	❌	✅（Incubating）
OTLP対応	✅	△	✅（基盤）
UI	✅ 充実	✅ シンプル	❌（転送のみ）
多バックエンド対応	△	△	✅ 100+
GitHub Stars	20k+	17k+	4k+

分散トレーシングはDevOpsカテゴリ/categories/devopsのPrometheusメトリクス・Lokiログ集約と組み合わせてLGTMスタック（Loki+Grafana+Tempo+Mimir）でObservability（可観測性）の三本柱（Metrics・Logs・Traces）を構築します。セキュリティカテゴリ/categories/securityのゼロトラストアーキテクチャ・サービスメッシュと組み合わせてリクエストの認証・認可・レイテンシを全Span単位で追跡します。

FAQ

Q. JaegerをKubernetesにHelmでデプロイするには？

A. Jaeger Operatorを使ってKubernetesに本番レディなJaegerクラスターをデプロイします。手順: ①helm repo add jaegertracing https://jaegertracing.github.io/helm-charts②helm install jaeger-operator jaegertracing/jaeger-operator -n observability --create-namespace③JaegerカスタムリソースをYAMLで定義（kind: Jaeger・spec.strategy: production・spec.storage.type: elasticsearch・spec.storage.options.es.server-urls: http://elasticsearch:9200）→kubectl apply -f jaeger.yaml④kubectl get jaeger -n observabilityで起動確認。サイドカー自動注入: NamespaceやDeploymentにsidecar.jaegertracing.io/inject: "true"アノテーション→JaegerのJaeger AgentサイドカーがPodに自動注入→アプリからlocalhost:6831にUDP送信でTraceをCollect。

Q. OpenTelemetryでPythonアプリを自動計装するには？

A. **opentelemetry-instrumentコマンドでPythonアプリを再起動なしに自動計装（Zero-code instrumentation）**できます。インストール: pip install opentelemetry-distro opentelemetry-exporter-otlp→opentelemetry-bootstrap -a install（使用ライブラリを自動検出してインストルメンテーションを追加）。起動: OTEL_SERVICE_NAME=my-service OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-collector:4317 opentelemetry-instrument python app.py→Flask・FastAPI・Django・requests・SQLAlchemy等が自動計装される。手動Span: 自動計装でカバーされないビジネスロジックにwith tracer.start_as_current_span('process-order')で手動Spanを追加。属性: span.set_attribute('user.id', user_id)・span.set_attribute('payment.amount', amount)でビジネスコンテキストをSpanに付与→Jaegerでのトレース分析が容易。

Q. JaegerとZipkinのどちらを選ぶべきですか？

A. 新規構築・OTLP対応・大規模マイクロサービスならJaeger、既存ZipkinインフラのB3 Propagation互換維持・シンプルさ優先ならZipkinが向いています。Jaeger優位: ①CNCF卒業プロジェクトで長期サポート保証②OTLP（OpenTelemetryプロトコル）ネイティブサポート→最新のOTel SDKと相性最良③Kafka統合でトレースデータのバッファリング・スケールアウト④アダプティブサンプリング（トラフィック量に応じてサンプリングレートを自動調整）。Zipkin優位: ①Spring Cloud Sleuth（Spring Boot）との統合が成熟②B3ヘッダー（X-B3-TraceId）を使う既存コードをそのまま流用③JVM・JAXベースの小規模サービスでJava製ZipkinとWarがマッチ④設定がシンプルで迅速に立ち上げ可能。推奨: 新規プロジェクトはOTel Collector→Jaegerのパイプラインを採用し、既存はZipkin互換レイヤーをOTel Collectorで提供してJaegerに転送する移行パスを使う。

Q. OpenTelemetry CollectorでDataDogやNew Relicに同時送信するには？

A. OTel Collectorのexportersセクションに複数のバックエンドを定義してServiceパイプラインで並列送信します。設定: exportersにdatadog（api.key: ${DD_API_KEY}）・otlphttp/newrelic（endpoint: https://otlp.nr-data.net・headers.api-key: ${NR_API_KEY}）・jaegerを定義→serviceのpipelines.traces.exportersに[jaeger, datadog, otlphttp/newrelic]を追加→CollectorがFanoutしてすべてのバックエンドに送信。コスト制御: samplingプロセッサーで本番トラフィックの5%のみDataDog（有料）に送信してコストを削減→残り100%はJaeger（セルフホスト・無料）に送信→開発時のデバッグはJaegerで行い、本番監視はDataDogのSLO/アラートを活用するハイブリッド構成。

まとめ

ユースケース	推奨ツール
新規・OTLP・大規模K8s	Jaeger
既存Zipkin互換・シンプル	Zipkin
多バックエンド転送・ベンダー中立	OTel Collector

関連外部リソース

• Jaeger GitHubリポジトリ↗
• Zipkin GitHubリポジトリ↗
• OpenTelemetry CollectorリポジトリGitHub↗
• Grafana Tempo（OSSトレースバックエンド・JaegerUI互換）↗