Jaeger: Support for HTTP/1 agent reporter for communication with Collector

[piyush-pruthi]

Requirement - what kind of business use case are you trying to solve?

If some platforms do not support either TCP or HTTP/2, will need a HTTP/1 Agent Reporter.

Problem - what in Jaeger blocks you from solving the requirement?

Currently, communication between Agent and Collector can be achieved only via TChannel or grpc.

Proposal - what do you suggest to solve the problem or improve the existing situation?

Having a reporter.type="http" option which sends spans over HTTP/1.

https://github.com/jaegertracing/jaeger/compare/master...piyush-pruthi:agent-reporter-http-support?expand=1

Most of the work is done in this repository.
If it sounds good, I can raise a separate PR after having discussions.
Thanks

Any open questions to address

[yurishkuro]

Please elaborate why your environment cannot support http/2.

[piyush-pruthi]

@yurishkuro
We have a PAAS environment in which we use Cloud Foundry and gorouter for routing purposes.
gorouter currently doesn't support HTTP/2 packets.

https://github.com/cloudfoundry/gorouter/issues/195

So, if anyone wants to run jaeger on current CF installations, a HTTP/1 based reporter will help.

[yurishkuro]

There is still an option to use HTTP directly from Jaeger clients to collector. Or using Envoy instead of gorouter. It feels unwise developing new feature in Jaeger to support clearly legacy issue in CF.

Did you already make the change? How big is it? How much does it reuse existing code?

[piyush-pruthi]

Here are the changes @yurishkuro

https://github.com/jaegertracing/jaeger/compare/master...piyush-pruthi:agent-reporter-http-support?expand=1
This pretty much aligns with existing reporters design and http client from jaeger-client-go.

[yurishkuro]

The problem is that strategically we want to have fewer comms method, not more. We want to converge all comms to grpc and decomm tchannel; this change would take us in the opposite direction, supporting flexibility for transports where we don't want it.

[piyush-pruthi]

Sure..
Having a single communication channel makes sense.
We will try to explore some other things then for old CF installations.

Thanks

[stale[bot]]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[Lercher]

Hi, I like to +1 the request, b/c I‘d like to run the collector as a svc behind an OpenShift route. In V4 there is apparently no support to expose gRPC or http2 endpoints.

The problem is that strategically we want to have fewer comms method, not more. We want to converge all comms to grpc and decomm tchannel; this change would take us in the opposite direction, supporting flexibility for transports where we don't want it.

I understand that intention, however it appears that there is a real need for http communication and it can be seen with practically all official clients supporting http communication. Moreover the server, i.e. the collector supports that, why then not it’s own client?

All language clients needed to be implemented with http separately, imho b/c the agent won’t do it. My argument is, why should some instrumented Java application be more versatile in communication than the product itself?