Open yurishkuro opened 12 months ago
cc @vprithvi @jaegertracing/jaeger-maintainers @jaegertracing/helm-charts-maintainers
Thanks for the heads up! Agree with this direction (also, goodbye 64KB UDP packet size limitation)
I'm using the jaeger agent pipeline and have tried moving to the OTLP pipeline, but I am running into a host of issues. The opentelemetry-otlp pipeline doesn't support batching with Tokio, has a wierd Config conflict, and more. Are there any examples of how to switch over without running into all of these issues?
@James-Bartman jaeger-agent does not provide any batching, it is a pass-through proxy. If you are using the classic Jaeger SDKs, they typically would batch spans in the app's memory and export a batch to the backend. You can reconfigure them to export to collector and bypass the agent. Unless your specific SDK does not support non-UDP exports - I don't know since Rust was not officially supported by Jaeger team. The OTEL version does support batching, and can talk to collector: https://docs.rs/opentelemetry-jaeger/latest/opentelemetry_jaeger/
@yurishkuro Thank you! I was able to get implement the opentelemetry_otlp
exporter using tonic
, and then I passed it into my opentelemetry_otlp
pipeline with Tokio
batching. There are a lot of conflicting examples on the web, but the docs you linked a bit of elbow grease got it all working.
Thanks for the heads up! Is it already possible to disable the agent when running the jaeger-operator
with a jaeger
CR using strategy: production
?
The docs currently suggest not to use the agent because it is deprecated, but the configuration does not seem to allow this.
I have installed the jaeger-operator
through the helm chart (v1.49.0
), using image.tag=1.52.0
.
@mrasap good question, this should be part of the deprecation plan. I don't know the answer, so asked here: https://github.com/jaegertracing/jaeger-operator/issues/2401
@yurishkuro It's time to mark the second point in the checklist of ticket. It's been 6+ months
When I am taking a look at this ticket https://github.com/jaegertracing/jaeger/issues/4768 of removing deprecated Jaeger SDK to replace OTEL vars, I found this
The checklists of both tickets seems to be solved together
@yurishkuro PTAL
jaeger-agent
used to be very useful when Jaeger SDKs were in active use with their default UDP-based exporters. Most OTEL SDKs do not support UDP exporter and are phasing out Jaeger exporters altogether. That makesjaeger-agent
an unnecessary component since it is only designed to receive data via UDP.Note that having a host-local agent is still an often desirable deployment model, because it simplifies the SDK configuration (SDK only needs to know localhost:port address). However, OTEL Collector is a more suitable component for a host agent now, especially since it can also serve other functions like logs forwarding, not just trace data proxying.
Migration
See https://www.jaegertracing.io/docs/latest/architecture/ for the recommended deployment configurations.
Proposal
Deprecate
jaeger-agent
and in 6-months remove it from the code base. This will allow removing a large chunk of code that we won't need to maintain anymore.4749
Alternatives considered
Accept OTLP
We could deprecate UDP receivers in the agent and instead mount an OTLP receiver. This will allow
jaeger-agent
to continue to exist close to its current form. But the benefits of doing so are unclear, while the downsides are that we still need to support a chunk of source code and it creates/causes confusion with the users if the agent is required and why.