Better alignment with OpenTelemetry by focusing on OTLP

TL;DR: proposal (and a ) to deprecate native Jaeger exporters in OpenTelemetry SDKs in favor of OTLP exporters.

Photo by on

This is a re-post from the .

By (Splunk) | Thursday, November 03, 2022

Back in May of 2022, the Jaeger project announced native support for the OpenTelemetry Protocol (OTLP). This followed a for the Jaeger client libraries across many languages. With these changes, OpenTelemetry users are now able to send traces into Jaeger with industry-standard OTLP, and the Jaeger client library repositories have been finally archived.

We intend to deprecate Jaeger exporters from OpenTelemetry in the near future, and are looking for your feedback to determine the length of the deprecation phase. The best way to provide feedback is by or commenting on .

OpenTelemetry Support

This interoperability is a wonderful victory both for Jaeger users and for OpenTelemetry users. However, we’re not done yet. The OpenTelemetry specification still requires support for Jaeger client exporters across languages.

This causes challenges for both Jaeger users and OpenTelemetry maintainers:

1. Confusing Choices: Currently, users are faced with a choice of exporter (Jaeger or OTLP), and this can be a source of confusion. A user might be inclined, when exporting telemetry to Jaeger, to simply choose the Jaeger exporter because the name matches (even though Jaeger now actively encourages the use of OTLP).
   If we can eliminate this potentially confusing choice, we can improve the user experience and continue standardizing on a single interoperable protocol. We love it when things “just work” out of the box!
2. Maintenance and duplication: Because the Jaeger client libraries are now archived, they will not receive updates (including security patches). To continue properly supporting Jaeger client exporters, OpenTelemetry authors would be required to re-implement some of the functionality it had previously leveraged from the Jaeger clients.
   Now that Jaeger supports OTLP, this feels like a step backwards: It results in an increased maintenance burden with very little benefit.

User Impact

The proposal is to deprecate the following exporters from OpenTelemetry in favor of using native OTLP into Jaeger:

• Jaeger Thrift over HTTP
• Jaeger Protobuf via gRPC
• Jaeger Thrift over UDP

In addition to application configuration changes, there could be other architectural considerations. HTTP and gRPC should be straightforward replacements, although it may require exposing ports 4317 and 4318 if they are not already accessible.

Thrift over UDP implies the use of the . Users with this deployment configuration will need to make a slightly more complicated change, typically one of the following:

1. Direct ingest. Applications will change from using Thrift+UDP to sending OTLP traces directly to their jaeger-collector instance. This may also have sampling implications.
2. Replacing the Jaeger Agent with a sidecar instance. This could have sampling implications and requires changes to your infrastructure deployment code.

Intent to Deprecate — We’d Like Your Feedback!

In order to better support users and the interop between OpenTelemetry and Jaeger, we intend to deprecate and eventually remove support for Jaeger client exporters / Jaeger native data format in OpenTelemetry.

We would like your feedback! We want to hear from users who could be impacted by this change. To better make a data-informed decision, .

Your input will help us to choose how long to deprecate before removal.

A to support this deprecation. If would like to contribute and provide feedback, visit the link above and add some comments. We want to hear from you.