[Sdk] Added options for disabling signals

[CodeBlanch]

This is an alternative design for #3583 which fixes #3455.

Changes

We have a lot of environment variables sprinkled around the repo. There are issues like #2980 which are because we access envvars directly instead of through IConfiguration. This PR builds on top of #3533 to make it possible to use IConfiguration to access settings.

What I did here is introduce SdkOptions which contains flags for disabling the signals. SdkOptions can be bound to IConfiguration for users that want to drive it through JSON (or whatever). It will also look for OTEL_SDK_DISABLED key using IConfiguration which means users can specify the flag through envvars, command-line, json, whatever. @alanwest I would imagine things like attribute limits would also go here and piggyback on the IConfiguration stuff?

Users calling the "Sdk.Create*ProviderBuilder" methods directly (including .NET Framework) will just get an IConfiguration automatically created from envvars.

Essentially what I'm trying to do here is establish a better options pattern we can use throughout the repo (for exporters, instrumentation, etc.).

For auto-instrumentation case, I added a static registration method so it can disable the flags at runtime. Not the most elegant mechanism, but probably the easiest for consumption.

Examples

• Auto-instrumentation disabling SDK builders

// Note: Must be done AFTER auto-instrumentation has made its providers, before users have made theirs
SdkOptions.RegisterConfigureCallback(options =>
{
    options.TracingEnabled = false;
    options.MetricsEnabled = false;
    options.LoggingEnabled = false;
});

• Binding SdkOptions to some IConfiguration section

builder.Services.Configure<SdkOptions>(builder.Configuration.GetSection("OpenTelemetry"));

{
   "OpenTelemetry": {
       "TracingEnabled": false,
       "MetricsEnabled": false,
       "LoggingEnabled": false
   }
}

• Setting OTEL_SDK_DISABLED through IConfiguration

Lot's of ways to do this. Command-line, using environment variables, etc. This is how it would look through appSettings.json:

{
   "OTEL_SDK_DISABLED": true
}

Final IConfiguration will be a composite of all the sources users have configured. SdkOptions will look for that key, basically.

What to consider when comparing to the alternative design...

The issue I saw with #3583 is it is kind of a one-off thing. Auto-instrumentation would be tied to private bools via reflection. It would need to be changed if open-telemetry/opentelemetry-specification#2679 gets merged. It also seemed like a useful feature for users to be able to toggle SDK on/off via config. I tried to enable all of these things while also setting the foundation for better options/settings going forward.

[CodeBlanch]

@rajkumar-rangaraj Your design was returning the TracerProvider.Default for this case. I had that, but decided to add a no-op instance instead. The reason being: User's code is probably calling dispose/shutdown on the instance returned from build invocation. Seemed risky to return them something shared which they might kill accidentally?

[CodeBlanch]

Don't love adding this dependency, but we do make heavy use of environment variables so it didn't seem totally unreasonable?

[alanwest]

I'm not personally super concerned, but I have heard concern from end users regarding dependency bloat...

We could experiment with breaking out SDK configuration into its own package. This is kind of similar to what Java has with their auto-config module https://github.com/open-telemetry/opentelemetry-java/tree/main/sdk-extensions/autoconfigure

[alanwest]

@alanwest I would imagine things like attribute limits would also go here and piggyback on the IConfiguration stuff?

Yes! This is exactly what I had envisioned. I'd noted this in the description of #3376. The classes I put here https://github.com/open-telemetry/opentelemetry-dotnet/tree/main/src/OpenTelemetry.Exporter.OpenTelemetryProtocol/Configuration was meant to be temporary. The class you introduce in this PR is effectively what I had in mind. I can move this stuff to unify things once your PR lands.

[alanwest]

We have a lot of environment variables sprinkled around the repo. There are issues like #2980 which are because we access envvars directly instead of through IConfiguration.

Regarding the sprinkling... this class is an idea I had for centralizing our env var config in one more easily maintainable place.

https://github.com/open-telemetry/opentelemetry-dotnet/blob/main/src/OpenTelemetry.Exporter.OpenTelemetryProtocol/Configuration/EnvironmentVariableConfiguration.cs

[codecov]

Codecov Report

Merging #3639 (4232a7c) into main (960908c) will increase coverage by 0.13%.
The diff coverage is 75.00%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3639      +/-   ##
==========================================
+ Coverage   87.54%   87.67%   +0.13%     
==========================================
  Files         283      284       +1     
  Lines       10283    10312      +29     
==========================================
+ Hits         9002     9041      +39     
+ Misses       1281     1271      -10     

Impacted Files	Coverage Δ
src/OpenTelemetry/SdkOptions.cs	60.00% <60.00%> (ø)
...lemetry/Trace/Builder/TracerProviderBuilderBase.cs	90.83% <88.23%> (-0.68%)	⬇️
...emetry.Api/Internal/OpenTelemetryApiEventSource.cs	73.52% <0.00%> (-8.83%)	⬇️
...Telemetry/Internal/SelfDiagnosticsEventListener.cs	97.65% <0.00%> (+0.78%)	⬆️
....Prometheus.HttpListener/PrometheusHttpListener.cs	80.00% <0.00%> (+1.33%)	⬆️
src/OpenTelemetry/Logs/Pool/LogRecordSharedPool.cs	100.00% <0.00%> (+2.63%)	⬆️
...ter.ZPages/Implementation/ZPagesActivityTracker.cs	100.00% <0.00%> (+2.85%)	⬆️
...metryProtocol/Implementation/ActivityExtensions.cs	96.15% <0.00%> (+4.39%)	⬆️
...ZPages/Implementation/ZPagesExporterEventSource.cs	62.50% <0.00%> (+6.25%)	⬆️
... and 2 more

[github-actions]

This PR was marked stale due to lack of activity and will be closed in 7 days. Commenting or Pushing will instruct the bot to automatically remove the label. This bot runs once per day.

[github-actions]

Closed as inactive. Feel free to reopen if this PR is still being worked on.