Opentelemetry-java: Create a Jaeger Agent Exporter

[MirkoRuggiero]

From my instrumented client I want to send the spans to the agent and than to the collector. They are sent directly to the collector and there is not way to configure this from the code afaik. Am I missing something here? Thanks

[jkwatson]

I don't understand what you're asking for here. Can you explain what you mean by "local agent"?

[MirkoRuggiero]

Sorry I forgot to mention, I mean the jaeger-agent that runs on the same host of the instrumented application.

[jkwatson]

It looks like our JaegerGrpcSpanExporter has all the configuration options you would need to do this. Can you describe what you're doing that you would expect to work, but isn't?

[MirkoRuggiero]

The JaegerGrpcSpanExporter takes a grpc channel as arguments, which is open towards the collector according all the examples I found on the web (e.g. "localhost", "14250" if the collector is running locally). Configuring the exporter in this way, the jaeger-agent is by-passed. To confirm this, the --collector.tags are correctly attached to my spans, while the--agent.tags are not.

I'd want to send my spans to the agent first, and than to the collector. To do so, I imagined I'd need to open an UDP connection towards the agent, and then set some parameters in the exporter. Or at least, enabling the agent communication in the exporter? I'm surely missing something, probably very simple... sorry if that's the case.

Hope I helped to clarify, otherwise would you be so kind to tell me how I can do so via the JaegerGrpcSpanExporter? It might quickly solve my issue^^

Thanks

[jkwatson]

I personally know very little about Jaeger or various deployment architectures. It sounds like maybe we need a different exporter implementation that handles local agent communication? Or more configuration options? As I said, I don't know what's needed here, as I'm not an expert in this.

If what I read on the internet is to be believed, the agent speaks thrift, rather than grpc? In that case, we'd definitely need a new exporter for that use-case.

[MirkoRuggiero]

Yes, I think you got the point.. Could you suggest how to proceed in these cases? Can I myself propose the feature here? Thanks for the help provided though

[jkwatson]

If we create an issue "Create a Jaeger Agent Exporter", (or rename this one), that will be the best way to track it. If you have the expertise, a PR would also be great!

[MirkoRuggiero]

The PR seems to be a little bit out of my comfort zone, but I'll take a look at it nonetheless. Do you see any major issue NOT using the agent configuration offered by Jaeger?
Is the only advantage to reduce the number of open grpc channels towards the collector by a factor of _of_application_per_host>? (considering one agent per host, collecting all the traces from the applications running on that host, then sending everything to the collector via grpc)

[objectiser]

@MirkoRuggiero The OpenTelemetry Collector can be used as an agent (i.e. as a Jaeger agent replacement). In fact, the next major version of the Jaeger agent (currently available in master) is based on the OpenTelemetry Collector. So my suggestion would be to just switch to using the OpenTelemetry Collector as your agent and then you have the option of using Jaeger gRPC or OTLP.

[MirkoRuggiero]

@objectiser Do you mean deploying one collector "as agent" per host, all converging to another "real" collector?

[objectiser]

@MirkoRuggiero yes.

[MirkoRuggiero]

@objectiser Sounds great, thanks for the lead :)

[pavolloffay]

We should consider closing this issue and avoid implementing Jaeger UDP exporters in OTEL SDKs if there are no benefits. As @objectiser mentioned the OTEL collector or Jaeger 2.0 (OTEL based) can be deployed in agent mode and receive data via gRPC in Jaeger or OTLP formats via localhost.

@yurishkuro could you please chime in and summarize if there are any benefits of UDP over gRPC when using it in the agent mode? I valid point has been raised here about number of gRPC connections, are there any upper limits when perf degradation can happen?

[carlosalberto]

+1 for closing the issue if possible.

[yurishkuro]

I don't have any performance data that compares UDP vs. gRPC. Outside of performance, the only benefit of UDP is the lack of dependencies, since it can be implemented via stdlib. The downside of UDP is the lack of ACKs.

Person A: Nobody gets my UDP jokes.
Person B: How would you know?

[pavolloffay]

Let's close this issue with the recommendation of using Jaeger gRPC exporter or OTLP protocols.

If we prove that UDP has perf or other benefits (no 3rd party dependencies) then let's reopen and think about other solutions.