Consider some way (env. variable/property?) to disable autoconfiguration or force a "Opentelemetry.noop()" instance

[evantorrie]

Is your feature request related to a problem? Please describe.

I have applications that are manually instrumented using the Java Otel API but also include the Autoconfiguration SDK extension class so that it's easy to configure the SDK via environment variables and '-D' switches.

However, there are times when we want to completely disable OpenTelemetry (e.g. to check whether any issues in our application are caused by OpenTelemetry, or compare performance with/without OpenTelemetry enabled).

For auto-instrumentation via the javaagent, there is a single "kill switch", namely -Dotel.javaagent.enabled=false that disables any SDK initialization, etc. However, there is no equivalent for disabling autoconfiguration SDK completely if the "autoconfiguration" SDK extension class exists on the application classpath.

Describe the solution you'd like

A property or environment variable that can be used to disable OpenTelemetry autoconfiguration completely, e.g. -Dotel.autoconfiguration.enabled=false.

Describe alternatives you've considered
Even if we have our own flag to prevent any calls to the Otel autoconfigure API, any library we include which makes use of GlobalOpenTelemetry.get() will end up autoconfiguring the Otel SDK if the autoconfig extension class exists. By default, the autoconfigured SDK is a "working" SDK with OTLP exporters enabled for metrics and traces, rather than a "noop" OpenTelemetry instance.

Additional context
This issue was brought up at the May 10th 2022 Java SIG meeting. https://docs.google.com/document/d/1WK9h4p55p8ZjPkxO75-ApI9m0wfea6ENZmMoFRvXSCw/edit#heading=h.wtapn135xim7

[jack-berg]

I'd like to prototype this in java, and then open up an issue in the specification to formalize this.

I propose adding otel.experimental.enabled=true|false, where "experimental" would go away if / when this is accepted to the specification.

[jkwatson]

I'd like to prototype this in java, and then open up an issue in the specification to formalize this.

I propose adding otel.experimental.enabled=true|false, where "experimental" would go away if / when this is accepted to the specification.

maybe, otel.experimental.sdk.enabled ? Since the API/Context/Context propagation will still work?