Select instrumentation libraries via OTEL_DOTNET_AUTO_*_INSTRUMENTATION_ENABLED

[pellared]

Instead of OTEL_DOTNET_AUTO_[SIGNAL]_ENABLED_INSTRUMENTATIONS and OTEL_DOTNET_AUTO_[SIGNAL]_DISABLED_INSTRUMENTATIONS we could support OTEL_INSTRUMENTATION_[NAME]_ENABLED and OTEL_INSTRUMENTATION_COMMON_DEFAULT_ENABLED like the OTel Java Agent does.

I think it may be good to be consistent with Java.

If we agree on it we should first try to bring it to the https://github.com/open-telemetry/opentelemetry-specification.

[pellared]

Another reason to have OTEL_INSTRUMENTATION_[NAME]_ENABLED instead of env var which accepts a CSV value is that it is easier to create "layers" with Dockerfiles, K8s configuration, or even copy/paste snippets to e.g. disable some instrumentation library.

There is also a proposal to have a pattern OTEL_DOTNET_AUTO_[SIGNAL]_INSTRUMENTATION_[NAME]_ENABLED to be more precise.

[pellared]

@dmitryax shared with me a clean proposal (which he also recommends to try to add into the OTel Spec):

OTEL_INSTRUMENTATION_ENABLED=true|false for everything
OTEL_DOTNET_INSTRUMENTATION_ENABLED=true|false for all .NET instrumentation libraries
OTEL_DOTNET_TRACES_INSTRUMENTATION_ENABLED=true|false for all .NET tracing instrumentation libraries
OTEL_DOTNET_TRACES_[lib-name]_INSTRUMENTATION_ENABLED=true|false for one .NET instrumentation library.

So if the user wants all the instrumentation except for GraphQL tracing instrumentation:

OTEL_DOTNET_TRACES_GRAPHQL_INSTRUMENTATION_ENABLED=false

If the user wants to enable only GraphQL tracing instrumentation:

OTEL_INSTRUMENTATION_ENABLED=false
OTEL_DOTNET_TRACES_GRAPHQL_INSTRUMENTATION_ENABLED=true

He suggests avoiding having both ENABLED and DISABLED env vars.

[pellared]

Related open-telemetry/opentelemetry-specification#2891

[pellared]

@carlosalberto discussed it with the OTel spec SIG and/or with OTel Config WG. There is not agreement that these env vars should land into to OTel Spec until the OTel Config Spec becomes more mature. Therefore, we should add the OTEL_DOTNET_AUTO prefix and probably mark these env vars as experimental as maybe this will be addressed later in OTel Config Spec.

Therefore my current proposal is to have:

OTEL_DOTNET_AUTO_INSTRUMENTATION_ENABLED=true|false for all .NET instrumentation libraries.
OTEL_DOTNET_AUTO_TRACES_INSTRUMENTATION_ENABLED=true|false for all .NET traces instrumentation libraries.
OTEL_DOTNET_AUTO_TRACES_[lib-name]_INSTRUMENTATION_ENABLED=true|false for one .NET traces instrumentation library.

[mateuszrzeszutek]

Oops, forgot about this issue. FYI @trask, this might be something we want to approach in the javaagent too.

OTEL_DOTNET_TRACES_INSTRUMENTATION_ENABLED=true|false for all .NET tracing instrumentation libraries
OTEL_DOTNET_TRACES_[lib-name]_INSTRUMENTATION_ENABLED=true|false for one .NET instrumentation library.

On the Java side of things, we don't really differentiate between tracing/metrics/any-other-signal instrumentation - it's a whole package, you either get everything or have to configure views/samplers that filter particular data out. (Which I think is kinda the point of OpenTelemetry, to have correlated different signals)

Oh, and I like the OTEL_INSTRUMENTATION_ENABLED - it's a bit terser than the javaagent's OTEL_INSTRUMENTATION_DEFAULT_ENABLED