Jaeger exporter support vs OTel specification

[pellared]

For OTEL_TRACES_EXPORTER, jaeger is reserved for an Jaeger exporter using Protobuf via http/thirft or gRPC

References:

• https://opentelemetry.io/docs/reference/specification/sdk-environment-variables/#exporter-selection
• https://github.com/open-telemetry/opentelemetry-dotnet/tree/main/src/OpenTelemetry.Exporter.Jaeger

Possible actions

1. rename to jaeger-dotnet (sic!) or something similar
2. keep jaeger. just add some remark that the using jaeger does NOT default to gRPC but UdpCompactThrift protocol (also there is no support for gRPC at the moment)
3. remove support for Jaeger expoter

Also USAGE.md is outdated and misses info about the OTEL_EXPORTER_JAEGER_ENDPOINT , OTEL_EXPORTER_JAEGER_PROTOCOL env vars.

Related issue: #255

Origin: https://github.com/open-telemetry/opentelemetry-dotnet-instrumentation/pull/353/files#r803609447

[pellared]

We can also propose to add OTEL_EXPORTER_JAEGER_PROTOCOL to the specification with grpc as a default value. Especially since the .NET SDK already uses this env var. WDYT?

[pjanotti]

We can also propose to add OTEL_EXPORTER_JAEGER_PROTOCOL to the specification with grpc as a default value. Especially since the .NET SDK already uses this env var. WDYT?

Sounds more in line with what is already done for OTLP.

[nrcventura]

We can also propose to add OTEL_EXPORTER_JAEGER_PROTOCOL to the specification with grpc as a default value. Especially since the .NET SDK already uses this env var. WDYT?

Do we want to use one of our own OTEL_AUTO environment variables to handle this in the short term, while things are still being discussed in the spec? Or do we think it's ok to go with what we think the variable will be since we are still in a prerelease state?

[nrcventura]

Two things of interest that may influence our decision.

1. In Java specifying "jaeger" results in configuring the jaeger exporter to use grpc to export to jaeger.
2. In JS specifying "jaeger" results in exporting using UDP Thrift.
3. In Go there's only a jaeger thrift exporter.

I suspect that the protocol environment variable is not in the spec because most languages implemented just one protocol. As a result, I think that we only need to be consistent with the .NET SDK.

So maybe we should just rely on the protocol environment variable and say that you need to both set the exporter to jaeger and to set the protocol. And then document that if you don't set the protocol, that grpc will be used, and you will also need to ensure that your application is updated to include the necessary grpc dependencies.

[pellared]

Just a note that Jaeger exporter over gRPC is not implemented in .NET SDK. So it could e.g. throw an error until it is implemented 🤷 However I would expect to have http/thrift as the default protocol for similar reasons that http/protobuf is favored over grpc for OTLP exporter.

[pellared]

SIG meeting notes

We will use jaeger as the exporter name and just use what the SDK provides.

Closing this issue as know it is on spec+.NET SDK side.