✅ Deploy Preview for opentelemetry-cpp-api-docs canceled.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 87.96%. Comparing base (3506a7a) to head (ef72771).
Report is 1 commits behind head on main.

@@            Coverage Diff             @@
##             main    #3245      +/-   ##
==========================================
+ Coverage   87.92%   87.96%   +0.04%     
==========================================
  Files         201      205       +4     
  Lines        6386     6407      +21     
==========================================
+ Hits         5614     5635      +21     
  Misses        772      772              

@marcalff Thanks for the PR. Just a thought—rather than including set-provider methods in the SDK that check for the disabled , wouldn't it be better to offer more granular control within the get_logger/tracer/meter methods, allowing them to return no-op objects when the SDK is disabled? This way, users wouldn't need to use a new api, and it also ensures that new loggers or tracers won't function if the environment variable is disabled after the application starts.

@marcalff Thanks for the PR. Just a thought—rather than including set-provider methods in the SDK that check for the disabled , wouldn't it be better to offer more granular control within the get_logger/tracer/meter methods, allowing them to return no-op objects when the SDK is disabled? This way, users wouldn't need to use a new api, and it also ensures that new loggers or tracers won't function if the environment variable is disabled after the application starts.

@lalib

Thanks for the suggestion.

I considered it as well, but decided against it for the following reasons:

• In terms or robustness, technical risk, and performance overhead,
  it is better to talk to the default Noop provider when the SDK is
  disabled, rather that invoke code in a real SDK implementation that will
  degrade itself to a Noop.

• For SDK code that opentelemetry-cpp has control of, this may work,
  but there are unknowns with SDK classes implemented by third parties,
  which still may not honor OTEL_SDK_DISABLED.

• Implementing a check in the SDK on get_tracer() implies that the SDK
  always honor environment variables defined in the spec.
  This is invalidated by the declarative configuration project
  (config.yaml), because the spec says explicitly that every environment
  variable beside OTEL_EXPERIMENTAL_CONFIG_FILE is to be ignored
  when a yaml configuration file is used.
  Implementing the check inside get_tracer() in the SDK would break this.
  See https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/configuration/sdk-environment-variables.md#declarative-configuration

As a result, the current proposal:

• Puts the test for OTEL_SDK_DISABLED in the SetTracerProvider() code path,
  when a configured SDK is installed by the application main().

• Will work to support declarative configuration later, I plan to add
  opentelemetry::sdk::trace::Provider::SetTracerProviderNoEnv(),
  to be used with a config.yaml file.

• Leaves the SDK execution (Get() code path) unchanged,
  and independent on how the SDK was configured.

As for environment variables changing during the process execution,
I don't think there is any expectation for this to work.
For example, changing an endpoint URL after the SDK is already configured
will have no effect.

In my understanding,
environment variables are meant to be a simple way to change the SDK
configuration without having to change code in the main application,
but are not meant to change during execution.
Honoring a change in OTEL_SDK_DISABLED between start and end span will cause
chaos, for unclear benefit.

Thanks @marcalff for explanation. The changes look good to me - just a comment regarding removal of API provided methods.