search

jaegertracing / jaeger

CNCF Jaeger, a Distributed Tracing Platform
https://www.jaegertracing.io/
Apache License 2.0
20.15k stars 2.4k forks source link

🌇 Sunsetting Jaeger clients 🏁 #3362

Closed yurishkuro closed 11 months ago

yurishkuro commented 2 years ago

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.

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

pavolloffay commented 2 years ago

+1

rbroggi commented 2 years ago

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 commented 2 years ago

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

yurishkuro commented 2 years ago

Added

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

rbroggi commented 2 years ago

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:

rbroggi commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

+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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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 https://github.com/open-telemetry/opentelemetry-dotnet/issues/3101)

yurishkuro commented 2 years ago

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 commented 2 years ago

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 commented 11 months ago

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