Opentelemetry-go: Export to Jaeger using gRPC

[jpkrohling]

The current preferred way to send data to Jaeger's collector is via gRPC. The current Jaeger exporter is however using Thrift. While Thrift might still be needed for legacy environments, there should be a gRPC option for the Jaeger exporter, potentially being the default option.

[iredelmeier]

Unable to add myself as an assignee but I'm picking this up

[iredelmeier]

@jpkrohling from my understanding, only the collector supports gRPC, and the agent is still Thrift-only. Is this correct? If so, is the idea here that the exporter should skip the agent and connect directly to the collector?

CC @rghetia since I believe you were also interested in getting Jaeger + gRPC in.

[rghetia]

Unable to add myself as an assignee but I'm picking this up

Thanks for picking it up. I have assigned it to you.

[iredelmeier]

Thanks @rghetia!

Did you have more context on the use case? It's currently unclear to me whether we want the exporter to ever communicate directly with the collector instead of the agent.

[rghetia]

Thanks @rghetia!

Did you have more context on the use case? It's currently unclear to me whether we want the exporter to ever communicate directly with the collector instead of the agent.

My understanding is same as yours which is client libraries export spans to Agent and Agent sends it to Collector. Agent only supports HTTP endpoints.
Lets' wait for a response from @jpkrohling .

[jpkrohling]

By default, Jaeger client libraries send spans via UDP in Thrift format to agents. However, most client libraries can be configured to talk to a remote collector via HTTP. Right now, I think we have no clients able to send data via gRPC, but the Jaeger Agent sends data to the Collector via gRPC by default since a couple of releases.

To clarify my original message: this issue here is only about the situation where the library is set to bypass the agent, sending data directly to a remote collector.

[iredelmeier]

@jpkrohling thanks for the clarification!

What are your thoughts on getting this change accomplished upstream in jaeger-client-go first, and then using the client in the exporter? It feels a bit funky to not be consuming it here.

[jpkrohling]

From what I remember, we haven't implemented it in the official libraries yet because we are waiting to see if the OpenTelemetry clients will replace them in the future. I personally prefer to collaborate on the same set of client libraries.

We had a similar discussion as part of open-telemetry/opentelemetry-java#469 and decided to not depend on the Jaeger Java Client there. If the maintainers of opentelemetry-go prefer to consume jaeger-client-go instead, we can probably implement the gRPC transport there first.

[iredelmeier]

Interesting, thanks for that context @jpkrohling!

Speaking strictly on behalf of myself, I agree that it makes more sense for the OpenTelemetry exporters to consume the official clients, preferably with some sort of wrapper on top - something approximately like:

package main

import "go.opentelemetry.io/exporters/jaeger"

options := []jaeger.Option{
  // ...
}
exporter := jaeger.NewExporter(options...)

package jaeger

import (
  "github.com/jaegertracing/jaeger-client-go"
  "github.com/jaegertracing/jaeger-client-go/config"
)

type Exporter struct {
  tracer *jaeger.Tracer
}

type Option func(*config)

type config struct {
  configuration config.Configuration
}

[jpkrohling]

I think it would be good then to have a single strategy for all clients: it will certainly be confusing to developers if the Go client is configured in a way that is different from the Java client.

[rghetia]

Closing stale issue.