Add OTEL_SDK_DISABLED env var to disable opentelemetry SDK.

[brunobat]

Fixes #2667

Changes

Add OTEL_SDK_ENABLED environment property
This will allow applications to easily deactivate opentelemetry on deployments where it's not supported or needed.
This property is already present in the Java SDK version under experimental status. See: https://github.com/open-telemetry/opentelemetry-java/blob/main/sdk-extensions/autoconfigure/README.md#disabling-opentelemetrysdk

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: brunobat / name: Bruno Baptista (27e70e4)

[brunobat]

Did the requested changes @arminru @joaopgrassi .

[brunobat]

Hi @jmacd, can we move forward with the merge?

[Emily-Jiang]

It seems this PR was blocked from merging as it requires Code Owner to review. Can someone from that group view this and merge this PR? Thanks

[tigrannajaryan]

I advise to circulate this PR in the Maintainers meeting on Monday to make sure there are no languages where peculiarities of env variable querying can impact on how the variable's values should be defined. We have had some issues in this area which resulted in the precise behavior specification for Numbers and Enums.

I think folks brought up important topics since I reviewed that have to be discussed/addressed so I'm reverting it for now.

[brunobat]

The Boolean definition has now been moved to #2729

[robbkidd]

As the review of this spec update has evolved, it seems the title, description, and content of the change have diverged.

The current state of the proposal has the env var name ending with _DISABLED.

✅ That's reflected in the title and the tables in compliance matrix and SDK env vars list.

⚠️ The CHANGELOG still states _ENABLED.

❓ The PR's original description also says _ENABLED which was the original proposal. It could help people reviewing this PR for the first time after all the discussion for the PR description to be edited to include an update describing the current state of the proposal.

[jmacd]

@MrAlias do you accept the current contents of this PR? I believe the goal of specifying a "DISABLED" variable with exactly one meaningful value ("true") was to avoid the general problem you described with interpreting booleans.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[carlosalberto]

Ping @MrAlias

[MrAlias]

@MrAlias do you accept the current contents of this PR? I believe the goal of specifying a "DISABLED" variable with exactly one meaningful value ("true") was to avoid the general problem you described with interpreting booleans.

This is the correct direction, but a boolean value is still under-specified in this PR. It looks like #2729 needs to be resolved before this can progress, as was discussed in the spec SIG meeting two weeks ago.

[marcalff]

Ok in principle, this will allows to disable telemetry in every applications the same way, without application specific options, or no options at all when the application forgot to provide one: very desirable feature.

About the naming:
OTEL_SDK_DISABLED=False, the default behavior, is a double negation

This is equivalent to:
OTEL_SDK_ENABLED=True

with no OTEL_SDK_ENABLED environment variable provided meaning True.

The concern about the double negation is the confusion it can create, in particular for non English speakers.

It seems the PR started with OTEL_SDK_ENABLED=True, then later changed to OTEL_SDK_DISABLED=False, but I can't find a comment or a rationale for it, so not sure who requested that, and why.

This is minor (or bikeshed even), feel free to ignore.
Looking to support this in opentelemetry-cpp.

[jack-berg]

@marcalff see this comment. The current thinking is that any boolean environment variable should be named *_ENABLED_* or *_DISABLED_* such that if a default value of false aligns with the desired default behavior.

[marcalff]

@marcalff see this comment. The current thinking is that any boolean environment variable should be named *_ENABLED_* or *_DISABLED_* such that if a default value of false aligns with the desired default behavior.

Thanks @jack-berg for the clarification.

I think this is a dangerous path to take : if somehow, for a given variable, we decide to change the default for whatever reason, the variable will not be renamed, creating a weird state.

In other words, it could be desirable to decouple the variable name (immutable to avoid breaking configuration for users) from the default value (possibly subject to change other time). This convention creates coupling.

Regards,
-- Marc

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[brunobat]

This is still waiting for #2729

[reyang]

This is still waiting for #2729

#2729 is resolved by #2755.