SDK configuration from ENV Variable

[cijothomas]

Spec has documented a list of ENV variable names from which SDK should read config, if SDK chose to support ENV var based config.
https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/sdk-environment-variables.md

[cijothomas]

Given this is not a MUST, we can add this after-ga.

[pellared]

I would like to discuss the potential API and behavior changes that are expected as part of this issue.

I see two "types" of configuration that can be done via environmental variables.

The first one is about configuring a specific component like Zipkin Exporter configuration. The logic here can be simply encapsulated into existing packages like https://www.nuget.org/packages/OpenTelemetry.Exporter.Zipkin/. No API changes needed.

The second one is harder as it is about enabling components e.g. Exporter selection. I think this type of setting may even need some at least high-level design to make sure we have something that covers OTEL_PROPAGATORS. Taking the OTEL_TRACES_EXPORTER as an example I imagine we could add a new extension method to https://www.nuget.org/packages/OpenTelemetry.Exporter.Zipkin/ with something like (I am bad at naming):

public static TracerProviderBuilder RegisterZipkinExporterEnvVar(TracerProviderBuilder builder) {
    return builder.RegisterExporter("zipkin", () => builder.AddZipkinExporter());
}

Also, it may be worth creating a convenience NuGet package with a method like AddCommonEnvVarSelections which would "register" all env vars defined by the specs.

[pellared]

opentelemetry-dotnet/src/OpenTelemetry.Exporter.OpenTelemetryProtocol/Implementation/ActivityExtensions.cs

Line 199 in 6b7f2dd

// Activity does not limit number of attributes, events, links, etc so drop counts are always zero.

Does it mean that we cannot limit them and support *_LIMIT env vars?

[pellared]

By @reyang from Slack thread:

Environmental variables handling:

1. If we don't have access to the environment variable (due to security reason), we'll proceed as if nothing is set in the env vars (just log)
2. When we process the environment variables, anything that wouldn't make logical sense (e.g. we expect int, but we got a string that doesn't look like int) would result in exceptions
3. We only process environment variables during the SDK initialize (e.g. by taking a snapshot), any env vars change later will not be used or picked up.

Reference: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/error-handling.md#basic-error-handling-principles

[srogovtsev]

Am I right in understanding that as of 1.6.0 the OTEL_TRACES_EXPORTER variable is still not supported? I tried to find it in the code and couldn't.

[martinjt]

https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/configuration/sdk-environment-variables.md

That's the updated link for the environment variables.

I'm not sure we have plans in place to start supporting the full list right @alanwest ?

[gfaraj]

Howdy, I'm also wondering about OTEL_TRACES_EXPORTER support. Is that in the plans?

[cijothomas]

Howdy, I'm also wondering about OTEL_TRACES_EXPORTER support. Is that in the plans?

not in the immediate plan. supporting that would likely need to create a distro or meta package and is not explored yet.