search

open-telemetry / opentelemetry-dotnet

The OpenTelemetry .NET Client
https://opentelemetry.io
Apache License 2.0
3.12k stars 745 forks source link

Support OTLP related environmental variables #4154

Open Kielek opened 1 year ago

Kielek commented 1 year ago

Feature Request

Support for following environmental variables

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

Additional Context

Found while working on https://github.com/open-telemetry/opentelemetry-dotnet-instrumentation/issues/2009

cijothomas commented 1 year ago

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 commented 1 year ago

Partially duplicates https://github.com/open-telemetry/opentelemetry-dotnet/issues/2923

CodeBlanch commented 1 year ago

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 commented 1 year ago

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

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 week ago

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

CodeBlanch commented 1 week ago

@pawel-ta

If you call the cross-cutting "UseOtlpExporter" extension (https://github.com/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://github.com/open-telemetry/opentelemetry-dotnet/blob/main/src/OpenTelemetry.Exporter.OpenTelemetryProtocol/Implementation/OtlpSpecConfigDefinitions.cs