Closed yurishkuro closed 11 months ago
+1
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?
Good point, we could dogfood the upgrade ourselves this way. Also in the hotrod example.
Added
@rbroggi are you interested in giving one of these a try?
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:
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) ?
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).
+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.
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?
@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).
Deprecation notices in all client repos (except C#) are made. Documentation is updated: https://www.jaegertracing.io/docs/latest/client-libraries/#deprecating-jaeger-clients
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.
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.
@EronWright
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)
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.
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.
This issue has been around for almost 2yrs, and all of the planned work has been completed, so closing it and removing from pinned.
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