Support OTLP related environmental variables

[Kielek]

Feature Request

Support for following environmental variables

• OTEL_EXPORTER_OTLP_TRACES_ENDPOINT
• OTEL_EXPORTER_OTLP_METRICS_ENDPOINT
• OTEL_EXPORTER_OTLP_LOGS_ENDPOINT
• OTEL_EXPORTER_OTLP_INSECURE
• OTEL_EXPORTER_OTLP_METRICS_INSECURE
• OTEL_EXPORTER_OTLP_LOGS_INSECURE
• OTEL_EXPORTER_OTLP_SPAN_INSECURE
• OTEL_EXPORTER_OTLP_METRIC_INSECURE
• OTEL_EXPORTER_OTLP_CERTIFICATE
• OTEL_EXPORTER_OTLP_TRACES_CERTIFICATE
• OTEL_EXPORTER_OTLP_METRICS_CERTIFICATE
• OTEL_EXPORTER_OTLP_LOGS_CERTIFICATE
• OTEL_EXPORTER_OTLP_CLIENT_KEY
• OTEL_EXPORTER_OTLP_TRACES_CLIENT_KEY
• OTEL_EXPORTER_OTLP_METRICS_CLIENT_KEY
• OTEL_EXPORTER_OTLP_LOGS_CLIENT_KEY
• OTEL_EXPORTER_OTLP_CLIENT_CERTIFICATE
• OTEL_EXPORTER_OTLP_TRACES_CLIENT_CERTIFICATE
• OTEL_EXPORTER_OTLP_METRICS_CLIENT_CERTIFICATE
• OTEL_EXPORTER_OTLP_LOGS_CLIENT_CERTIFICATE
• OTEL_EXPORTER_OTLP_COMPRESSION
• OTEL_EXPORTER_OTLP_TRACES_TIMEOUT
• OTEL_EXPORTER_OTLP_METRICS_TIMEOUT
• OTEL_EXPORTER_OTLP_LOGS_TIMEOUT
• OTEL_EXPORTER_OTLP_TRACES_PROTOCOL
• OTEL_EXPORTER_OTLP_METRICS_PROTOCOL
• OTEL_EXPORTER_OTLP_LOGS_PROTOCOL

Requirements from https:/open-telemetry/opentelemetry-specification/blob/dd47c009da1de335c540decc5d5930e46ea61916/specification/protocol/exporter.md

Additional Context

Found while working on open-telemetry/opentelemetry-dotnet-instrumentation#2009

[cijothomas]

1st priority:
OTEL_EXPORTER_OTLP_TRACES_PROTOCOL
OTEL_EXPORTER_OTLP_METRICS_PROTOCOL
OTEL_EXPORTER_OTLP_LOGS_PROTOCOL
OTEL_EXPORTER_OTLP_TRACES_ENDPOINT
OTEL_EXPORTER_OTLP_METRICS_ENDPOINT
OTEL_EXPORTER_OTLP_LOGS_ENDPOINT
2nd priority
OTEL_EXPORTER_OTLP_TRACES_TIMEOUT
OTEL_EXPORTER_OTLP_METRICS_TIMEOUT
OTEL_EXPORTER_OTLP_LOGS_TIMEOUT

^ From @Kielek

[pellared]

Partially duplicates #2923

[CodeBlanch]

This might be really hard to do at the moment because logs/traces/metrics share a single options class. We have talked in the past about splitting up the OtlpExporter into projects based on the transport. If we do that we could introduce dedicated options classes for each signal which would make this easier to achieve. It would also allow us to clean up some hacks we use to make the single class safe to use with Options API.

/cc @alanwest

[Kielek]

@CodeBlanch, before we start work and split the packages for separate transport protocols support for following env. vars should be considered

• OTEL_EXPORTER_OTLP_PROTOCOL
• OTEL_EXPORTER_OTLP_TRACES_PROTOCOL
• OTEL_EXPORTER_OTLP_METRICS_PROTOCOL
• OTEL_EXPORTER_OTLP_LOGS_PROTOCOL

Lets consider only Traces only:
We should end up with OpenTelemetry.Exporter.OpenTelemetryProtocol.Grpc and OpenTelemetry.Exporter.OpenTelemetryProtocol.Http.

I expect that we ends up with at least

static OpenTelemetry.Trace.Grpc.OtlpTraceExporterHelperExtensions.AddGrpcOtlpExporter(this OpenTelemetry.Trace.TracerProviderBuilder! builder) -> OpenTelemetry.Trace.TracerProviderBuilder!
static OpenTelemetry.Trace.Http.OtlpTraceExporterHelperExtensions.AddHttpOtlpExporter(this OpenTelemetry.Trace.TracerProviderBuilder! builder) -> OpenTelemetry.Trace.TracerProviderBuilder!

How HTTP version should behave when OTEL_EXPORTER_OTLP_PROTOCOL or OTEL_EXPORTER_OTLP_TRACES_PROTOCOL is set to grpc? Same for Grpc.
I can imagine that we have some metapackage handling this scenario, but is this expected solution?

[CodeBlanch]

I think a meta package would be fine. Or perhaps it could be something only auto-instrumentation supports? @alanwest and I have talked about having an "auto-configuration" package (I did some exploration of that idea a while back). Java has similar, from what I'm told.

[alanwest]

How HTTP version should behave when OTEL_EXPORTER_OTLP_PROTOCOL or OTEL_EXPORTER_OTLP_TRACES_PROTOCOL is set to grpc?

I think a NotSupportedException would be appropriate in these cases.

[Kielek]

How HTTP version should behave when OTEL_EXPORTER_OTLP_PROTOCOL or OTEL_EXPORTER_OTLP_TRACES_PROTOCOL is set to grpc?

I think a NotSupportedException would be appropriate in these cases.

My understating otel-spec is that we should avoid throwing any exception influencing process start while configuring OTel.
Event-log with appropriate message will be better option (or fully ingnoring it and relay on meta-package).

[pellared]

I suggest "fully ignoring it" as a distribution may support this env var. Getting an event-log would be misleading for the user.

[pawel-ta]

Hello, is there any update on this? Specifically for signal-specific exporter variables? It would be extremely valuable

[CodeBlanch]

@pawel-ta

If you call the cross-cutting "UseOtlpExporter" extension (https:/open-telemetry/opentelemetry-dotnet/tree/main/src/OpenTelemetry.Exporter.OpenTelemetryProtocol#enable-otlp-exporter-for-all-signals) some of the spec signal-specific env vars are now supported!

Here is the list of currently supported keys: https:/open-telemetry/opentelemetry-dotnet/blob/main/src/OpenTelemetry.Exporter.OpenTelemetryProtocol/Implementation/OtlpSpecConfigDefinitions.cs