What Is the Difference Between OpenTelemetry and Zipkin? 

OpenTelemetry and Zipkin are both used in distributed tracing, but they operate at different layers and their relationship changed significantly in 2025 and 2026. OpenTelemetry is an instrumentation and collection framework. Zipkin is a distributed tracing storage and visualization backend. 

The relationship changed in two ways: Zipkin now supports OTLP ingestion natively via the zipkin-otel project, removing the need for format translation. And OpenTelemetry deprecated its Zipkin exporter specification in December 2025, with SDK support for existing exporters continuing until at least December 2026.

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 backends.

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

Zipkin

Zipkin is a distributed tracing backend originally developed at Twitter, inspired by Google’s Dapper paper, and open-sourced in 2012. It stores trace spans, provides a query API, and a UI at port 9411 for visualizing individual traces and service dependency graphs.

What Zipkin does not do: it has no instrumentation API targeting modern standards, no metrics storage, and no log storage. It handles traces only.

The Core Differences

The Propagation Difference: B3 vs W3C TraceContext

This is the most practically significant difference when migrating from Zipkin to OpenTelemetry or running both in the same system.

B3 propagation (Zipkin's native format) uses separate HTTP headers:

X-B3-TraceId: 463ac35c9f6413ad48485a3953bb6124

X-B3-SpanId: 0020000000000001

X-B3-ParentSpanId: 0010000000000001

X-B3-Sampled: 1

B3 propagation (Zipkin's native format) uses separate HTTP headers:

X-B3-TraceId: 463ac35c9f6413ad48485a3953bb6124

X-B3-SpanId: 0020000000000001

X-B3-ParentSpanId: 0010000000000001

X-B3-Sampled: 1

Or a single-header variant:

b3: 463ac35c9f6413ad48485a3953bb6124-0020000000000001-1-0010000000000001

W3C TraceContext (OpenTelemetry's default) uses a standardized format:

traceparent: 00-463ac35c9f6413ad48485a3953bb6124-0020000000000001-01

tracestate: vendor-specific-data

b3: 463ac35c9f6413ad48485a3953bb6124-0020000000000001-1-0010000000000001

W3C TraceContext (OpenTelemetry's default) uses a standardized format:

traceparent: 00-463ac35c9f6413ad48485a3953bb6124-0020000000000001-01

tracestate: vendor-specific-data

When a request crosses a boundary between a Zipkin-instrumented service and an OTel-instrumented service, the trace breaks into disconnected fragments unless one side is configured to understand both formats.

OTel supports B3 via configurable propagators. During migration, configure OTel services to propagate both formats simultaneously:

OTEL_PROPAGATORS=tracecontext,baggage,b3multi

OTEL_PROPAGATORS=tracecontext,baggage,b3multi

With this setting, OTel injects both sets of headers on every outgoing request. A Zipkin service reads B3 headers. An OTel service reads traceparent. Both see the same trace ID and can participate in the same trace.

The OTel Zipkin Exporter Deprecation

The OpenTelemetry project published an official deprecation notice for the Zipkin exporter specification in December 2025, confirmed on the official OpenTelemetry blog and the OpenTelemetry specification page. The key points:

Why deprecated: Usage analysis across language ecosystems showed Zipkin exporters see limited adoption. In several languages, adoption was lower than the already-deprecated Jaeger exporter. Zipkin now supports OTLP ingestion natively, making the custom Zipkin exporter logic in OTel SDKs an unnecessary maintenance burden.

Timeline:

• Specification deprecation: effective December 2025
• Zipkin exporter support will be removed from the OTel specification: December 2026
• Existing stable SDK exporters: continue to receive security patches and critical bug fixes until at least December 2026
• New language SDKs: not required to implement Zipkin exporters

Migration paths:

• Option 1 (recommended): Switch to OTLP. Enable Zipkin’s native OTLP ingestion via the zipkin-otel project and point your OTel SDK at Zipkin’s server port.
• Option 2: Keep your existing Zipkin backend and route OTel data through the OTel Collector’s Zipkin exporter, which remains available in opentelemetry-collector-contrib.

How to Send OTel Traces to Zipkin

Option 1: Direct OTLP to Zipkin (Recommended)

Zipkin accepts OTLP natively via the zipkin-otel extension (openzipkin-contrib/zipkin-otel). The OTLP endpoint is bound to Zipkin’s default server port 9411, not a separate port. Configure your OTel SDK to point at port 9411 using HTTP/protobuf:

OTEL_EXPORTER_OTLP_ENDPOINT=http://zipkin:9411 \

OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf \

OTEL_SERVICE_NAME=order-service \

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

OTEL_EXPORTER_OTLP_ENDPOINT=http://zipkin:9411 \

OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf \

OTEL_SERVICE_NAME=order-service \

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

Option 2: Via the OTel Collector (Legacy Zipkin Format)

If you cannot enable OTLP ingestion on Zipkin, route through the OTel Collector using its Zipkin exporter from opentelemetry-collector-contrib:

# otel-collector-config.yaml

receivers:

  otlp:

    protocols:

      grpc:

        endpoint: 0.0.0.0:4317

      http:

        endpoint: 0.0.0.0:4318

processors:

  batch:

exporters:

  zipkin:

    endpoint: http://zipkin:9411/api/v2/spans

    format: proto

service:

  pipelines:

    traces:

      receivers: [otlp]

      processors: [batch]

      exporters: [zipkin]

# otel-collector-config.yaml

receivers:

  otlp:

    protocols:

      grpc:

        endpoint: 0.0.0.0:4317

      http:

        endpoint: 0.0.0.0:4318

processors:

  batch:

exporters:

  zipkin:

    endpoint: http://zipkin:9411/api/v2/spans

    format: proto

service:

  pipelines:

    traces:

      receivers: [otlp]

      processors: [batch]

      exporters: [zipkin]

Quick-start: Run Zipkin

docker run -d -p 9411:9411 openzipkin/zipkin:3.6.0

Open the Zipkin UI at http://localhost:9411.

docker run -d -p 9411:9411 openzipkin/zipkin:3.6.0

Open the Zipkin UI at http://localhost:9411.

Migrating from Zipkin to OpenTelemetry

If you are running Zipkin instrumentation (Brave client libraries) and want to migrate to OTel SDKs, the migration has two distinct phases.

• Phase 1: Bridge propagation formats. Configure your OTel services to emit both W3C and B3 headers so they can participate in traces with existing Zipkin services:

OTEL_PROPAGATORS=tracecontext,baggage,b3multi

OTEL_PROPAGATORS=tracecontext,baggage,b3multi

• Phase 2: Migrate instrumentation service by service. Replace Brave instrumentation with OTel SDKs in each service. Because both formats are propagated in Phase 1, mixed deployments work correctly. Once all services are migrated, remove B3 from the propagator list.

Keep your Zipkin backend during migration. You do not need to migrate your storage backend at the same time as your instrumentation. The OTel Collector’s Zipkin exporter can continue sending data to your existing Zipkin backend while you migrate instrumentation.

Zipkin vs Other Trace Backends

Common Setup Problems

When You Need More Than Traces: Where CubeAPM Fits

Both Zipkin and Jaeger solve the trace storage and visualization problem well. What neither provides is correlation between a slow trace and the infrastructure metric at that moment, or the logs from that exact request. Finding the root cause of a slow trace requires jumping between a trace UI, a metrics dashboard, and a log search tool, matching timestamps manually.

CubeAPM accepts OTLP directly from your existing OTel SDK or Collector, the same data you would send to Zipkin, and stores events, metrics, logs, and traces (MELT) 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 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 Zipkin are complementary tools. OpenTelemetry handles instrumentation and collection across all signals. Zipkin handles trace storage, querying, and visualization. The relationship between them changed in 2025: OpenTelemetry deprecated its Zipkin exporter specification in December 2025 (existing exporters supported until December 2026), and Zipkin added native OTLP ingestion via zipkin-otel. The correct endpoint for OTLP ingestion is Zipkin’s standard server port 9411 using HTTP/protobuf, not a separate port. For migration from existing Zipkin instrumentation, configure composite B3 and W3C propagation to bridge the formats during the transition.

Disclaimer: Zipkin version (3.6.0), OTel Zipkin exporter deprecation timeline (spec deprecated December 2025, specification removal December 2026, SDK support until December 2026), zipkin-otel OTLP endpoint details (port 9411, HTTP/protobuf), and Zipkin storage backend support are verified against the official OTel deprecation blog post (opentelemetry.io/blog/2025/deprecating-zipkin-exporters), the OTel specification page for Zipkin exporters (opentelemetry.io/docs/specs/otel/trace/sdk_exporters/zipkin), the openzipkin-contrib/zipkin-otel GitHub repository README, and the Zipkin GitHub releases page (github.com/openzipkin/zipkin/releases) as of May 2026.

Also read:

What Is the Difference Between OpenTelemetry and Jaeger? 

How to Set Up OpenTelemetry in .NET Applications 

How to Instrument Django Applications with OpenTelemetry