(deprecation) Remove jaeger-agent

[yurishkuro]

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 makes jaeger-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.

• add deprecation warnings to the binary, the docs, and Docker Hub repo
  • Add deprecation warning to jaeger-agent #4749
  • Tag jaeger-agent as deprecated in Downloads documentation#656
• wait for 6 months
• remove agent from the build pipeline Remove jaeger-agent from distributions #6081
• mark Docker Hub repo as archived
• remove agent from Helm chart and k8s operator
  • Jaeger agent is no longer avaiablle helm-charts#607
  • Jaeger agent is no longer available jaeger-operator#2714
• remove mentioning of the agent from the docs and diagrams Remove references to jaeger-agent documentation#757
• remove imports of jaeger code from otel contrib Remove UDP receivers using Jaeger agent code open-telemetry/opentelemetry-collector-contrib#35765
• remove the code for the agent
• clean up IDLs

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.

[yurishkuro]

cc @vprithvi @jaegertracing/jaeger-maintainers @jaegertracing/helm-charts-maintainers

[vprithvi]

Thanks for the heads up! Agree with this direction (also, goodbye 64KB UDP packet size limitation)

[James-Bartman]

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?

[yurishkuro]

@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/

[James-Bartman]

@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.

[mrasap]

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.

[yurishkuro]

@mrasap good question, this should be part of the deprecation plan. I don't know the answer, so asked here: jaegertracing/jaeger-operator#2401

[varshith257]

@yurishkuro It's time to mark the second point in the checklist of ticket. It's been 6+ months

[varshith257]

When I am taking a look at this ticket #4768 of removing deprecated Jaeger SDK to replace OTEL vars, I found this

• removing deprecated Jaeger SDK to replace OTEL vars, [Bug]: Docker compose file not working with adaptive Sampling #4768
• remove agent from the build pipeline in this ticket $4739

The checklists of both tickets seems to be solved together

[varshith257]

@yurishkuro PTAL

[chinaran]

jaegertracing/jaeger-operator#2611
The PR for jaeger agent deprecation was Revert.
May I ask if it should be added back?

[yurishkuro]

@chinaran yes we should remove it from the operator, but the description lists the order in which the steps need to be done.

[chinaran]

@chinaran yes we should remove it from the operator, but the description lists the order in which the steps need to be done.

I understand, thanks.