What Is the Difference Between OpenTelemetry and Jaeger? 

OpenTelemetry and Jaeger are both open-source CNCF graduated projects used in distributed tracing, but they operate at completely different layers. OpenTelemetry is an instrumentation and collection framework. Jaeger is a distributed tracing storage and visualization backend. 

The relationship between them has also changed significantly with Jaeger v2 (released November 2024, current stable v2.18.0 as of May 2026): Jaeger v2 is now built directly on the OpenTelemetry Collector framework, accepts OTLP natively, and ships as a single binary. Jaeger v1 reached end-of-life on December 31, 2025 and will no longer receive updates.

What Each Tool Does

OpenTelemetry

OpenTelemetry is the instrumentation and collection layer. It provides language-specific SDKs for generating traces, metrics, and logs from application code, the OpenTelemetry Protocol (OTLP) for transporting that data, and the Collector for receiving, processing, and routing it to any backend.

What OpenTelemetry does not do: it has no storage engine, no query interface, no trace visualization UI, and no alerting system. It is a pipeline that feeds backends.

Jaeger

Jaeger is a distributed tracing backend. It stores trace data, provides a query API for retrieving traces, and a UI at port 16686 for visualizing individual traces, service dependency graphs, and latency distributions.

What Jaeger does not do: it has no instrumentation API, no SDK, no metrics storage, and no log storage. It handles traces only.

The Core Differences

How Jaeger v2 Changed the Relationship

Before Jaeger v2, the two tools were architecturally separate. Applications were instrumented with either OTel SDKs or Jaeger’s own client libraries, and data flowed to the Jaeger collector via Jaeger Thrift protocol. Teams running OTel needed the OTel Collector’s Jaeger exporter to translate OTLP into Jaeger Thrift.

Jaeger v2 eliminated this separation. The key changes confirmed from the official Jaeger release blog and CNCF announcement:

• Jaeger v2 is a distribution of the OTel Collector. The Jaeger team built v2 by taking the OTel Collector as the foundation and adding Jaeger-specific extensions: jaeger_storage (pluggable trace storage), jaeger_query (the query service and UI), and jaeger_storage_exporter. The cmd/jaeger binary assembles both standard OTel Collector components and these Jaeger-specific components into a single executable.
• Jaeger v2 accepts OTLP natively end-to-end. There is no longer a translation layer between OTLP and Jaeger’s internal format. Traces arrive as OTLP, are stored in an OTLP-compatible data model, and served via the query API.
• Multiple v1 binaries replaced by one. Jaeger v1 required separate processes for the agent, collector, query, and ingester. Jaeger v2 ships as a single binary configured through a single YAML file using the same configuration format as the OTel Collector.
• Jaeger v1 is end-of-life. As of December 31, 2025, Jaeger v1 receives no further updates, security patches, or bug fixes. The official download page states this explicitly.

How to Send Traces from OTel to Jaeger v2

Routing through the OTel Collector to Jaeger v2

The standard production setup routes traces from your application SDK through the OTel Collector and into Jaeger v2 via OTLP:

# otel-collector-config.yaml

receivers:

  otlp:

    protocols:

      grpc:

        endpoint: 0.0.0.0:4317

      http:

        endpoint: 0.0.0.0:4318

processors:

  batch:

exporters:

  otlp/jaeger:

    endpoint: jaeger:4317

    tls:

      insecure: true

service:

  pipelines:

    traces:

      receivers: [otlp]

      processors: [batch]

      exporters: [otlp/jaeger]

# otel-collector-config.yaml

receivers:

  otlp:

    protocols:

      grpc:

        endpoint: 0.0.0.0:4317

      http:

        endpoint: 0.0.0.0:4318

processors:

  batch:

exporters:

  otlp/jaeger:

    endpoint: jaeger:4317

    tls:

      insecure: true

service:

  pipelines:

    traces:

      receivers: [otlp]

      processors: [batch]

      exporters: [otlp/jaeger]

Jaeger v2 configuration

Jaeger v2 is configured as an OTel Collector distribution using a single YAML file:

# jaeger-config.yaml

service:

  extensions: [jaeger_storage, jaeger_query]

  pipelines:

    traces:

      receivers: [otlp]

      exporters: [jaeger_storage_exporter]

extensions:

  jaeger_storage:

    backends:

      some_store:

        memory:

          max_traces: 100000

  jaeger_query:

    storage:

      traces: some_store

receivers:

  otlp:

    protocols:

      grpc:

        endpoint: 0.0.0.0:4317

      http:

        endpoint: 0.0.0.0:4318

exporters:

  jaeger_storage_exporter:

    trace_storage: some_store

# jaeger-config.yaml

service:

  extensions: [jaeger_storage, jaeger_query]

  pipelines:

    traces:

      receivers: [otlp]

      exporters: [jaeger_storage_exporter]

extensions:

  jaeger_storage:

    backends:

      some_store:

        memory:

          max_traces: 100000

  jaeger_query:

    storage:

      traces: some_store

receivers:

  otlp:

    protocols:

      grpc:

        endpoint: 0.0.0.0:4317

      http:

        endpoint: 0.0.0.0:4318

exporters:

  jaeger_storage_exporter:

    trace_storage: some_store

Run Jaeger v2:

docker run -d \

  -p 16686:16686 \

  -p 4317:4317 \

  -p 4318:4318 \

  -v $(pwd)/jaeger-config.yaml:/etc/jaeger/config.yaml \

  jaegertracing/jaeger:2.18.0 \

  --config /etc/jaeger/config.yaml

docker run -d \

  -p 16686:16686 \

  -p 4317:4317 \

  -p 4318:4318 \

  -v $(pwd)/jaeger-config.yaml:/etc/jaeger/config.yaml \

  jaegertracing/jaeger:2.18.0 \

  --config /etc/jaeger/config.yaml

Because Jaeger v2 is itself an OTel Collector distribution, you can also point your OTel SDK directly at Jaeger v2’s OTLP endpoint without routing through a separate Collector. This simplifies small deployments:

OTEL_EXPORTER_OTLP_ENDPOINT=http://jaeger:4318 \

OTEL_SERVICE_NAME=order-service \

java -javaagent:opentelemetry-javaagent.jar -jar app.jar

OTEL_EXPORTER_OTLP_ENDPOINT=http://jaeger:4318 \

OTEL_SERVICE_NAME=order-service \

java -javaagent:opentelemetry-javaagent.jar -jar app.jar

Jaeger v1 Migration: What Changes

If you are still running Jaeger v1, these are the key changes:

Jaeger v2 Storage Backends

The official Jaeger v2 docs (last updated April 2026) describe the backends as follows:

Jaeger vs Other Trace Backends

Common Setup Problems

When You Need More Than Traces: Where CubeAPM Fits

Jaeger solves one problem exceptionally well: storing and visualizing distributed traces. When a trace shows a slow span, Jaeger shows you the full trace hierarchy. What it does not show is the infrastructure metric at that moment, the log records from that exact request, or how the trace correlates with the metrics your team already monitors in Prometheus.

Correlating a slow Jaeger trace with infrastructure metrics and logs requires jumping between tools and matching timestamps manually. The shared trace ID that OpenTelemetry provides across signals makes this correlation technically possible, but Jaeger stores only one signal.

CubeAPM accepts OTLP directly from your existing OTel SDK or Collector, the same data you would send to Jaeger, and stores traces, metrics, and logs together. When a slow trace appears, you move from the trace to the infrastructure metric on the affected host to the logs from that exact request without switching tools. It offers distributed tracing and runs self-hosted inside your own infrastructure at $0.15/GB ingestion pricing with no per-user fees, so data never leaves your environment.

Summary

OpenTelemetry and Jaeger are complementary tools at different layers of the observability stack. OpenTelemetry handles instrumentation and collection across all signals. Jaeger handles trace storage, querying, and visualization. Jaeger v2 deepened this relationship by building directly on the OTel Collector framework, accepting OTLP natively, and replacing multiple v1 binaries with a single binary. Jaeger v1 is end-of-life as of December 31, 2025. The primary supported production storage backends in v2 are Cassandra, Elasticsearch, and OpenSearch.

Disclaimer: Jaeger version (v2.18.0, confirmed from jaegertracing.io/docs/2.18), v1 end-of-life date (December 31, 2025, confirmed from jaegertracing.io/download), storage backend status (Cassandra and Elasticsearch as primary, ClickHouse as experimental, confirmed from jaegertracing.io/docs/2.18/storage and jaegertracing.io/roadmap last modified April 2026), and Jaeger v2 architecture details are verified against official Jaeger documentation as of May 2026.

Also read:

How to Set Up OpenTelemetry in .NET Applications 

How to Instrument Django Applications with OpenTelemetry 

How to Add OpenTelemetry Tracing to a Spring Boot Application