Add OTEL_EXPORTER_JAEGER_PROTOCOL and improve description of other OTEL_EXPORTER_JAEGER_* env vars

[pellared]

Follow-up of #2333

Changes

Preview here

• Add the OTEL_EXPORTER_JAEGER_PROTOCOL environment variable to select the protocol used
  by the Jaeger exporter.
• More explicit description of the rest of the OTEL_EXPORTER_JAEGER_* environment variables (e.g. when they are applicable - it also represents the current state of SDKs)

Here are the following reasons for this change

1. Enable the possibility of selecting the protocol when the Jaeger exporter is set via env var OTEL_TRACES_EXPORTER=jaeger (instead of supporting values like OTEL_TRACES_EXPORTER=jaeger-udp).
2. This resembles the configuration of the OTLP exporter which has OTEL_EXPORTER_OTLP_PROTOCOL
3. The newest OTel .NET SDK RC version supports this env var. See here. I feel that it is safer to standardize it (especially the supported values) before it is released
4. We want to take advantage of it in OTel .NET AutoInstrumentation. However, I believe this could be useful in other places as well.
5. Node.js SDK uses 6832 as the default Agent port because it uses a different protocol

Related issues:

• Jaeger exporter support vs OTel specification opentelemetry-dotnet-instrumentation#355

FYI (all SIG maintainers where I see that OTEL_EXPORTER_JAEGER_ENDPOINT is used) @open-telemetry/dotnet-maintainers @open-telemetry/dotnet-instrumentation-maintainers @open-telemetry/java-instrumentation-maintainers @open-telemetry/python-maintainers @open-telemetry/go-maintainers @open-telemetry/php-maintainers @open-telemetry/java-maintainers @open-telemetry/ruby-maintainers @open-telemetry/rust-maintainers

Alternative

Instead of adding OTEL_EXPORTER_JAEGER_PROTOCOL we can specify more specific values for OTEL_TRACES_EXPORTER like jaeger/http/thrift.binary but this would be inconsistent with the OTLP exporter configuration.

TODO in next PR

• reformatting the table to make it more readable
  • Add OTEL_EXPORTER_JAEGER_PROTOCOL and improve description of other OTEL_EXPORTER_JAEGER_* env vars #2341 (comment)
  • Add OTEL_EXPORTER_JAEGER_PROTOCOL and improve description of other OTEL_EXPORTER_JAEGER_* env vars #2341 (comment)
  • Add OTEL_EXPORTER_JAEGER_PROTOCOL and improve description of other OTEL_EXPORTER_JAEGER_* env vars #2341 (comment)

[pellared]

Going to address @yurishkuro comments tomorrow

[pellared]

Ready for another review round.

[tigrannajaryan]

Side note: the formatting of this page makes Github diffs difficult to read. Perhaps we need to reformat it similar to #2345 (can be done in a separate, future PR).

[tigrannajaryan]

Why does this say MAY? This is not a recommendation, it is a strict list. Should it say: MUST be one of ... instead?.

[pellared]

Taken from https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/protocol/exporter.md. The same wording is used in #2345

I would prefer to address it in a separate PR

[tigrannajaryan]

I still think MAY is not the right word here and other similar places that you found, but I am fine if it is addressed in a future PR.

[pellared]

I will create issues for it once this PR is merged and assign it to myself.

[MrAlias]

Addressing this addition in a future PR could potentially lead to compatibility issues. Reviewers of the future PR may not know if this change was released and "upgrading" from an option to a requirement would be a backwards incompatible change. Or, even worse, this would be released prior to the follow on PR being merged. Given this section of the doc is marked stable, this seems like a valid concern.

Can we address the change from MAY to MUST for these changes in this PR instead? That way it will be a cohesive and complete change that is not copying prior errors.

[pellared]

@tigrannajaryan @MrAlias PTAL e2c4178

[carlosalberto]

Ping @owais ;)