🌇 Sunsetting Jaeger clients 🏁

[yurishkuro]

The Jaeger clients have faithfully served our community for several years. We pioneered many new features like remotely controlled samplers and per-operation / adaptive sampling, which were critical to the success of tracing deployments at large organizations. However, now that the larger community in OpenTelemetry has caught up with the Jaeger clients in terms of feature parity and there is full support for exporting data to Jaeger, we believe it is time to retire Jaeger's native clients and refocus the efforts on the OpenTelemetry SDKs.

For new applications, we recommend using the OpenTelemetry APIs and SDKs. For applications that are already instrumented with the OpenTracing API, we recommend replacing the Jaeger client with the corresponding OpenTelemetry SDK and the OpenTracing shim/bridge (available in most languages supported by Jaeger). We published a blog post that shows an example of the migration steps for Java: "Migrating from Jaeger client to OpenTelemetry SDK".

We will announce the deprecation of Jaeger clients at the beginning of November and give people till the end of year to submit any fixes/PRs. Then in January 2022 we will make the final releases of Jaeger clients and stop accepting new PRs (unless a security issue is discovered).

---

This is a tracking issue to make the respective changes in the docs/website and in the Jaeger client repos.

• docs/website https://www.jaegertracing.io/docs/latest/client-libraries/#deprecating-jaeger-clients
• Upgrade HotROD example to use OpenTelemetry SDK #3380
• Upgrade internal use of tracing to OpenTelemetry #3381
• Go client
  • Notice jaegertracing/jaeger-client-go@68a1fa6
• Java client
  • Notice jaegertracing/jaeger-client-java@49d4013
• Python client
  • Notice jaegertracing/jaeger-client-python@a81052e
• Node.js client
  • Notice jaegertracing/jaeger-client-node@ddb639d
• C# client
  • Notice Deprecate C# client jaeger-client-csharp#230
• C++ client
  • Notice Deprecate Jaeger C++ SDK jaeger-client-cpp#292

I would like to get a vote from all maintainers before we proceed.
@albertteoh
@joe-elliott
@jpkrohling
@pavolloffay
@vprithvi

[pavolloffay]

+1

[rbroggi]

In light of this announcement, is the all-in-one code already reflecting the recommended direction? Would it be already (or potentially) a getting started guide to this migration for the go community?

[yurishkuro]

Good point, we could dogfood the upgrade ourselves this way. Also in the hotrod example.

[yurishkuro]

Added

• upgrade HotROD example
• upgrade internal use of Jaeger client

@rbroggi are you interested in giving one of these a try?

[rbroggi]

Added

• upgrade HotROD example
• upgrade internal use of Jaeger client

@rbroggi are you interested in giving one of these a try?

Would love to 🙂

[rbroggi]

Added

• upgrade HotROD example
• upgrade internal use of Jaeger client

@rbroggi are you interested in giving one of these a try?

Would love to slightly_smiling_face

After studying the APIs it seems that there is no native way of representing the jaeger-client config.Metric and config.Logger. My understanding is that we would loose in the all-in-one and HotROD the functionalities carried by those two parameters. Is my assessment right? If it's wrong would you please point me to resources/ideas/documents that show how to reach same features while using open telemetry?

Can you elaborate (or point to code)? I am not sure what dependency on the logger we would have as logging from the SDK itself is not that interesting. For metrics - yes, I can see that might create some challenge, I don't really know if OTEL SDK exposes the same indicators about its performance as Jaeger SDK did. It's not that we have specific dependencies on those indicators though (they should be mentioned in the blog post on HotROD).

Ok I will keep that in mind.

I have also come upon a second concern:

Migrating the all-in-one means that we have to migrate the query service usage of opentrace.Tracer (e.g. method app.NewServer in cmd/query/app/server.go) to trace.Tracer. In other words, it would not be necessarily only a change confined to the all-in-one but also go deep in the query service. Makes sense? Would you advice me to start from HotRod or all-in-one (if any) ?

[yurishkuro]

Can you elaborate (or point to code)? I am not sure what dependency on the logger we would have as logging from the SDK itself is not that interesting. For metrics - yes, I can see that might create some challenge, I don't really know if OTEL SDK exposes the same indicators about its performance as Jaeger SDK did. It's not that we have specific dependencies on those indicators though (they should be mentioned in the blog post on HotROD).

[joe-elliott]

+1

We will personally not be able to move to OTEL clients until they support remote sampling, but I think starting this migration is the right choice.

[rakyll]

Exciting news. Is there any timeline to keep accepting the security fixes? Are there any long-term plans to communicate the deprecation from the SDKs themselves, such as logging that SDKs are deprecated/sunset?

[yurishkuro]

@rakyll good points. Do you have any thoughts on those timelines? I would prefer to go no longer than 6m, because keeping up with dependencies upgrades is also a sizeable effort (especially for doing releases after those upgrades).

[yurishkuro]

Deprecation notices in all client repos (except C#) are made. Documentation is updated: https://www.jaegertracing.io/docs/latest/client-libraries/#deprecating-jaeger-clients

[Falco20019]

Sorry, you seem to missed me when tagging the maintainers in the initial post. I will deprecate C# later today once I'm in the office.

[EronWright]

One aspect that I've found lacking is the documentation about how to setup Jaeger to work with opentelemetry clients. The Jaeger documentation makes mention of using the OpenTracing bridge, but doesn't seem to mention whether any changes are needed on the Jaager server side. It still isn't clear to me whether one would need to run the OTEL collector in addition to the Jaeger server.

[yurishkuro]

@EronWright

1. you only need OpenTracing bridge if your code is still using OpenTracing instrumentation. If you use OpenTelemetry instrumentation, it will work with OTEL SDK directly without a bridge.
2. Whether you need/want OTEL collector depends on your setup. If you configure OTEL SDK to export data in OTEL native format (like OTLP), then you will need OTEL collector for now (in the future Jaeger collector will accept OTLP directly, this is part of Jaeger V2 work). But you can also configure OTEL SDK to use Jaeger exporters and send data directly to Jaeger collector.

[Falco20019]

Sadly not everyone can switch as easy to OTEL. The C# client only supports .NET Framework 4+, .NET Core, .NET and ASP.NET Core. Other platforms, especially Xamarin, are no longer supported. Therefore we are currently stuck using the jaeger-client-csharp (see open-telemetry/opentelemetry-dotnet#3101)

[yurishkuro]

Yes, that's fair, this is why the OpenTelemetry bridge was introduced, to ease the migration. If there are issues with the bridge implementation, please open tickets in the respective OTEL repo.

[Falco20019]

Ticket is open (and linked in my previous post). And it's not the bridge but the full OTEL SDK for dotnet that is sadly unusable. Just wanted to have it here as a note for anyone doing Mobile on .NET.

There is sadly no easy way for solving this. The technique used in the implementation is just not available on those platforms (and won't be in the foreseeable futures AFAIK) and doing it differently would basically mean to have a completely new implementation for .NET.

[yurishkuro]

This issue has been around for almost 2yrs, and all of the planned work has been completed, so closing it and removing from pinned.