Deprecate Zipkin exporter

[lmolkova]

This PR intends to gather feedback on Zipkin exporter usage and possible deprecation.

What inspired it:

1. The transformations documented in zipkin exporter are not followed in practice (e.g. otel-java or zipkin-otel). I don't see any signs of transformations in collector zipkinexporter
   These transformations were not updated despite Semantic Conventions changes and it went unnoticed (e.g. database conventions went stable ~ 6 months ago, but the document still uses deprecated attributes).

2. Public download stats mostly show low usage. e.g.

   • python:
     • opentelemetry-exporter-zipkin - ~155k downloads last month
     • opentelemetry-exporter-jaeger (deprecated and removed from the spec) - ~513k downloads last month
     • opentelemetry-exporter-otlp - 96M downloads last month
   • .NET trends for Zipkin, Jaeger, OTLP exporters also show zipkin having slightly less downloads than deprecated Jaeger and ~10 times less than OTLP
   • JS shows 2.5x difference in download numbers between
     • @opentelemetry/exporter-zipkin - ~20M last month - THIS IS QUITE HIGH (possible explanation in Deprecate Zipkin exporter #4715 (comment))
     • while @opentelemetry/exporter-trace-otlp-http along with @opentelemetry/exporter-trace-otlp-grpc have ~48M downloads
   • I don't have access to Java maven download stats

3. Availability of experimental OTLP support in zipkin server and zipkin exporter in collector in beta status

4. Low activity on issues org:open-telemetry zipkin in:title - most of them are SIG work items including collector zipkin exporter with just a few issues created by end users.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: lmolkova / name: Liudmila Molkova (42ecde8)

[jsuereth]

I'm a fan of moving this direction.

Ideally, Zipkin would support OTLP based ingestion prior to deprecation (in non-beta module). However, given the existing breakage and lack of detection, I think it's good to pulse check actual usage.

We could deprecate the specification and allow OTEL based zipkin exporters to continue to exist and evolve per-use demand until Zipkin OTLP-based ingestion is "non-beta" (whatever release stage they use for this).

[pichlermarc]

JS shows 2.5x difference in download numbers between

• @opentelemetry/exporter-zipkin - ~20M last month - THIS IS QUITE HIGH
• while @opentelemetry/exporter-trace-otlp-http along with @opentelemetry/exporter-trace-otlp-grpc have ~48M downloads

The high download numbers of @opentelemetry/exporter-zipkin are likely due to its inclusion in @opentelemetry/sdk-node. It likely does not reflect actual usage numbers as it gets auto-downloaded, but then remains unused. The diff of @opentelemetry/sdk-node and @opentelemetry/exporter-zipkin is ~3.2M per month. We unfortunately have a lot of outdated examples that use Zipkin, so I have also seen that LLMs frequently spit out examples Zipkin exporter examples which may contribute to the high number.

I support deprecation given that the collector exporter exists as a workaround if needed.

We could deprecate the specification and allow OTEL based zipkin exporters to continue to exist and evolve per-use demand until Zipkin OTLP-based ingestion is "non-beta" (whatever release stage they use for this).

I think this is a good idea. If deprecated we'd likely keep the packages around anyway for a while as it requires almost no maintenance. We did the same with Jaeger.

[trentm]

We unfortunately have a lot of outdated examples that use Zipkin

As well, there is this section of the docs that mentions using the zipkin exporter: https://opentelemetry.io/docs/languages/js/exporters/#zipkin
We could perhaps remove that section.

[pellared]

Shouldn't we also deprecate this section: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/configuration/sdk-environment-variables.md#zipkin-exporter ?

[cijothomas]

Public download stats mostly show low usage. e.g.

For Rust:
OTLP Exporter has ~50M all-time download counts vs ~2M for Zipkin. Jaeger (deprecated) had ~13M downloads.

Re-itereating extremely low usage for Zipkin exporter from Rust too.

[pellared]

Nice! Just some nit comments.

[anuraaga]

/cc @reta as the current most active maintainer on zipkin and @making who pushed forward zipkin-otel, would be good to hear your thoughts on this. I tend to agree that if the exporters aren't converting correctly from newer versions of instrumentation and there aren't any reports on it, there's probably not high usage out there.

[making]

I tend to agree too. At least for Java, the zipkin exporter uses dreprecated attributes and lacks resource attributes. If users want to send trace signals to Zipkin, they should use the otlp collector from zipkin-otel.

[reta]

/cc @reta as the current most active maintainer on zipkin and @making who pushed forward zipkin-otel, would be good to hear your thoughts on this. I tend to agree that if the exporters aren't converting correctly from newer versions of instrumentation and there aren't any reports on it, there's probably not high usage out there.

Thanks a lot for heads up @anuraaga , I agree with @making (and you) on the otel part, with the resources we have at the moment, that would be a right move I believe. Thank you.

[pellared]

Only this #4715 (comment)

[reyang]

Consider the following clarifications:

1. The existing Zipkin exporters will be marked as deprecated immediately once this PR is merged, maintainers should not take any feature request for Zipkin exporters.
2. The existing Zipkin exporters will continue to receive security patches and critical bug fixes until the Dec. 1st, 2026 (adjust the date to meet the 1-year support policy).

[pellared]

The existing Zipkin exporters will continue to receive security patches and critical bug fixes until the Dec. 1st, 2026 (adjust the date to meet the 1-year support policy).

It would be good to create a blog post which announces it. Also it would be nice if each language additionally announce it in its changelog or/and release notes.

[lmolkova]

thanks @reyang !

The first point is up to maintainers - I believe one year count down starts from the moment they deprecate the artifact:

existing Zipkin exporters will be marked as deprecated immediately once this PR is merged, maintainers should not take any feature request for Zipkin exporters.

Updated text to

Zipkin exporter support will be removed from OpenTelemetry specification in December 2026.

Note: This document remains here for backwards compatibility and
will be removed in a future version. Existing stable Zipkin exporters MUST
continue to be supported for at least one year after the artifact is deprecated,
following the SDK stability guarantees.
Implementing a Zipkin exporter is not required for new SDKs.

I can draft a blog post as well.