Consider removing jaeger-thrift exporter from default agent

[anuraaga]

The official and recommended protocol between an agent and a collector is gRPC.

https://www.jaegertracing.io/docs/1.21/apis/#protobuf-via-grpc-stable

Actually, thrift is meant for use with UDP on localhost, something we don't support in Java

https://www.jaegertracing.io/docs/1.21/apis/#thrift-over-udp-stable

Thrift over HTTP is the legacy format for sending data to non-localhost from what I understand.

I feel as if bundling thrift into our agent is a bit much considering it's legacy, and figure Splunk's distribution, which I believe is the main user of this exporter, can include it instead?

Otherwise, we should get it added to the environment variables spec

https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/sdk-environment-variables.md

Not only is jaeger_thrift not there, but more problematically, jaeger and jaeger_thrift can't be enabled together because of tension in the endpoint argument, one must be something like localhost:1234, the other must be something like http://localhost:14268/api/traces but we use the same endpoint variable for both. While there is likely little use case for setting both, I don't see a reason our config should just ban that completely due to a corner case in variable parsing.

We would also want to rename to jaeger_thrifthttp I think to remove confusion with UDP.

I'm not interested in making this spec change and am inclined to delete our integration unless someone volunteers to spec this :) I do very much want the endpoint parsing tension to be resolved if we do go with including it.

@jkwatson @breedx-splk

[breedx-splk]

I think @iNikem put in the original request to add it...I wonder what he thinks about this idea.

[trask]

Removing it makes sense to me, but we'll definitely wait for @iNikem to chime in.

[iNikem]

I don't oppose it.

[noahseger]

Hey all, sorry to comment on such an old issue but my reading of the documentation is different. To me it looks like the gRPC recommendation is for the Agent forwarding spans to the Collector, not the protocol that Java exports. We're currently integrating with Jaeger for the reason that the UDP-based agents have an low profile for our various runtimes, and can resiliently batch and retry span collection without a single point of failure.

Is it possible to revisit this decision?

[trask]

hi @noahseger, we can definitely discuss, do you mind opening a fresh issue for it and referencing this one where the original decision was made?