Tracing configuration similar to MetricsBuilder

[lmolkova]

When configuring distributed tracing, it's useful to be able to enable and disable sources based on name(space) and other properties.

For example, Azure SDKs create multiple sources per library:

• Azure.Messaging.ServiceBus.SenderClient,
• Azure.Messaging.ServiceBus.ReceiverClient
• .. but also also to trace individual message via Azure.Messaging.ServiceBus.Message.

Some customer want per-message tracing, some don't, and we need to be able to tell them to enable Azure.* (or Azure.Messaging.ServiceBus.*) but disable the Azure.Messaging.ServiceBus.Message.

Another example is more common: client libraries want to report logical operations (that trace public API surface calls), but want to make protocol level opt-in. E.g. Azure.CosmosDb.Operation is a source for logical operations that we want users and OTel distros to enable by default and Azure.CosmosDb.Request would contain more verbose network traces that users should be able to opt into.
With MetricsBuilder-like API this would look like

builder.Services.AddDistributedTracing(b => b.EnableTracing("Azure.")
                                  .DisableTracing("Azure.CosmosDb.Request"));

It's not super-convenient for end-users but should be reasonable for OTel Distros. OTel might provide better ways to do it (see below).

So, it would be great to have parity with metrics and provide builder-like API allowing to enable and disable sources.

At the same time, name is not enough/future-proof in both (tracing and metrics) cases.

• When ActivitySource supports scope attributes [Feature request]: Support instrumentation scope attributes on ActivitySource #93795, they could be useful in EnableSource to enable/disable based on. Same is already the case for meter - scope attributes and version could be useful in IMetricsBuilder.EnableMetrics
• OTel at some point might introduce some concepts like verbosity and mechanism to enable/disable tracers/sources based on it. See Turn off spans from a scope while retaining downstream spans and without breaking traces open-telemetry/opentelemetry-specification#3867 for the context.

It would be great to support some form of EnableSource(Predicate<ActivitySource>) or a list of EnableSource(string name, string? version, IEnumerable<>? scopeAttributes, ....) overloads.

Separate from this issue, but it would be great to have consistent IMetricsBuilder.Enable|Disable(Func<Meter, Instrument, bool>) API or something else that allows to control metrics based on all meter properties.

See open-telemetry/opentelemetry-dotnet#5353 for more details.

[lmolkova]

based on the discussion with otel-dotnet people, they are not open to take contributions and are not ready to take "maintenance burden".

Given that it's problematic for any big set of libraries and turning of sources is one of a common asks we have on Azure SDKs specifically in .NET, I'd like to check if we can provide ability to turn off sources on the BCL level.

[lmolkova]

@jeffschwMSFT @mkArtakMSFT I think it belongs in dotnet/runtime repo (Microsoft.Extensions.Diagnostics component) and the area should be diagnostics. Could you please check?
Thanks!