Deprecate Zipkin exporter#4715
Conversation
|
|
dfa9f8a to
f81bd0c
Compare
|
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). |
The high download numbers of I support deprecation given that the collector exporter exists as a workaround if needed.
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. |
f783f16 to
c2a913b
Compare
As well, there is this section of the docs that mentions using the zipkin exporter: https://opentelemetry.io/docs/languages/js/exporters/#zipkin |
pellared
left a comment
There was a problem hiding this comment.
Shouldn't we also deprecate this section: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/configuration/sdk-environment-variables.md#zipkin-exporter ?
For Rust: Re-itereating extremely low usage for Zipkin exporter from Rust too. |
7df53f5 to
53a264c
Compare
53a264c to
e2b9726
Compare
pellared
left a comment
There was a problem hiding this comment.
Nice! Just some nit comments.
|
/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. |
|
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. |
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. |
Co-authored-by: Robert Pająk <pellared@hotmail.com>
|
Consider the following clarifications:
|
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. |
|
thanks @reyang ! The first point is up to maintainers - I believe one year count down starts from the moment they deprecate the artifact:
Updated text to
I can draft a blog post as well. |
### Context - Make the W3C randomness flag required. ([#4761](#4761)) ### Traces - Deprecate Zipkin exporter document and make exporter implementation optional. ([#4715](#4715)) - Add spec for `AlwaysRecord` sampler ([#4699](#4699)) ### Metrics - Stabilize `Enabled` API for synchronous instruments. ([#4746](#4746)) - Allow instrument `Enabled` implementation to have additional optimizations and features. ([#4747](#4747)) ### Logs - Stabilize `LogRecordProcessor.Enabled`. ([#4717](#4717)) ### SDK Configuration - Clarifies that guidance related to boolean environment variables is not applicable to other configuration interfaces. ([#4723](#4723)) --------- Co-authored-by: Armin Ruech <7052238+arminru@users.noreply.github.com>
## Summary Deprecate OpenTracing compatibility requirements in the specification as Stage 1 of issue #4849. This PR changes the OpenTracing compatibility spec document status to deprecated, adds a deprecation note, and updates wording to make it explicit that new OpenTracing compatibility implementations are no longer required by this specification. ## What changed - `specification/compatibility/opentracing.md` - Status changed from `Stable` to `Deprecated` - Added top-level deprecation note: - OpenTracing compatibility requirements are deprecated - existing shims MAY continue for backwards compatibility - new compatibility implementations are not required - removal criteria/timeline deferred to a separate discussion - Updated one normative paragraph to historical framing, aligned with deprecation - Added explicit sentence that this section remains for migration/backwards compatibility guidance - `CHANGELOG.md` - Added Unreleased/Compatibility entry for deprecating OpenTracing compatibility requirements ## Context and precedent - Addresses: #4849 - Follows the staged approach discussed in #4849 comments - Uses the same deprecation pattern/intent as prior deprecation work in #4715 (Zipkin exporter) ## Scope This PR is intentionally narrow (Stage 1 only): deprecate requirements in spec text. ### Non-goals - No immediate removal of OpenTracing compatibility content - No language-specific implementation mandates - No removal timeline policy in this PR (to be handled in follow-up discussion) ## Validation Local checks run: - `make markdownlint` ✅ - `make markdown-toc && git diff --exit-code ':*.md'` ✅ - `make cspell` ✅ Not run locally due environment limitation: - `make markdown-link-check` (requires Docker daemon) ## Notes for reviewers This is documentation/spec wording only and does not introduce API/SDK interfaces. --------- Co-authored-by: Amol Patil <9298683+adp2201@users.noreply.github.com> Co-authored-by: Carlos Alberto Cortez <calberto.cortez@gmail.com>
This PR intends to gather feedback on Zipkin exporter usage and possible deprecation.
What inspired it:
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).
Public download stats mostly show low usage. e.g.
Availability of experimental OTLP support in zipkin server and zipkin exporter in collector in beta status
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.