opentelemetry-specification
opentelemetry-specification copied to clipboard
Deprecate jaeger exporters.
Earlier this year, jaeger acquired native support for trace ingest via OTLP. Additionally, the language-specific client libraries that contained the jaeger thrift exporter implementations were EOLed via archival. At the top of the READMEs for those archived clients, Jaeger recommends switching to OpenTelemetry.
Since the client repos were archived, they will not receive security updates. Otel languages whose jaeger exporters depend on those clients will therefore need to reimplement the exporters or drop support for them. Because jaeger is actively urging users to switch to OpenTelemetry clients, I think that deprecation makes sense.
Continued support for jaeger exporters is a maintenance burden for otel language maintainers. Furthermore, the existence of so many exporter choices often serves to confuse users (eg. "I'm running jaeger and there's an otel jaeger exporter, so I should use that one?") and makes understanding otel <-> jaeger interoperation more difficult.
Related issue: https://github.com/open-telemetry/opentelemetry-specification/issues/2859
cc @yurishkuro
@yurishkuro Ping
@carlosalberto discussion still ongoing in https://github.com/open-telemetry/opentelemetry-specification/issues/2859
This PR was marked stale due to lack of activity. It will be closed in 7 days.
Definitely not stale. Finishing up blog post here https://github.com/open-telemetry/opentelemetry.io/pull/1892 and looking into cross posting with Jaeger blog.
This PR was marked stale due to lack of activity. It will be closed in 7 days.
This PR was marked stale due to lack of activity. It will be closed in 7 days.
Approving assuming that the PR will switch to Ready for Review after the communications are done.
Yeah, and I think we're close...just need some additional input on deprecation period length on #2859.
We are almost ready to merge this one. I'd like a final review cycle by @yurishkuro and we are good to go.