OTel Updates: OpenTelemetry Deprecates Zipkin Exporters

OpenTelemetry is deprecating the Zipkin exporter specification. Zipkin now supports OTLP ingestion natively, so the custom exporter logic in OTel SDKs is no longer necessary.

TL;DR:

Specification deprecated as of December 2025
Existing stable Zipkin exporters receive security patches until December 2026
New language SDKs don't need to implement Zipkin exporters
Two migration paths: switch to OTLP directly, or route through the Collector

The Change

After analyzing usage patterns across language ecosystems, OpenTelemetry maintainers found that Zipkin exporters see limited adoption. In several languages, usage is lower than the already-deprecated Jaeger exporter. With minimal engagement on related issues and Zipkin supporting OTLP natively, the project is consolidating around OTLP as the standard wire protocol.

The Zipkin exporter spec required custom transformation logic in every SDK. That logic needed maintenance, testing, and documentation across all language implementations. Zipkin's native OTLP support removes this maintenance burden.

Existing stable Zipkin exporters will continue to receive security patches and critical bug fixes until December 2026, following SDK stability guarantees. New language SDKs aren't required to implement Zipkin exporters.

Migration Options

If you're running Zipkin exporters, here are your options:

Switch to OTLP

Configure your application to send traces using OTLP and enable Zipkin's OTLP ingestion support through the zipkin-otel project. Point your OTel SDKs directly at Zipkin using OTLP.

This keeps your instrumentation aligned with where OpenTelemetry is heading. OTLP was designed with the OTel data model in mind, so it handles traces, metrics, and logs without transformation loss.

Route Through the Collector

Send OTLP from your application to the OpenTelemetry Collector, then use the Collector's Zipkin exporter to forward data to your Zipkin backend. The Collector's Zipkin exporter remains available in opentelemetry-collector-contrib.

This adds a hop but keeps your backend integration unchanged while you migrate instrumentation to OTLP. If you need time to transition, this provides a stable intermediate step.

Implementation

Check if your services use Zipkin exporters. Look for ZipkinExporter or similar in your OTel SDK configuration.

If you're switching to OTLP:

Enable OTLP in Zipkin using the zipkin-otel module
Update your application config to use OTLP exporters instead of Zipkin exporters
Test in a staging environment
Roll out to production

If you're routing through the Collector:

Configure the Collector with OTLP receivers
Add the Zipkin exporter to your Collector pipeline
Update applications to send OTLP to the Collector
Test and deploy

You have until December 2026 to complete the migration. That's a full year of security patches and critical bug fixes for existing stable exporters.

💡

For more on OpenTelemetry's work to stabilize the project, see our post on proposed changes to stability, releases, and semantic conventions.

What This Means for Your Backend

Last9 accepts OTLP natively. Whether you're migrating from Zipkin exporters or already using OTLP, the ingestion path is the same. Because the platform is built for high-cardinality telemetry, attributes remain intact and queryable without sampling or reduction at ingestion.

When you move to OTLP, the backend needs to handle the full data model without transformation loss. Last9 processes OTLP directly, so semantic conventions, resource attributes, and span links stay consistent from instrumentation to query.

💡

For OpenTelemetry updates covering new features, deprecations, migration guides, and configuration changes, refer to our OTel updates blog series.