Open lmolkova opened 4 months ago
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.
@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!
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
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.*
(orAzure.Messaging.ServiceBus.*
) but disable theAzure.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 andAzure.CosmosDb.Request
would contain more verbose network traces that users should be able to opt into. WithMetricsBuilder
-like API this would look likeIt'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.
ActivitySource
supports scope attributes dotnet/runtime#93795, they could be useful inEnableSource
to enable/disable based on. Same is already the case for meter - scope attributes and version could be useful inIMetricsBuilder.EnableMetrics
It would be great to support some form of
EnableSource(Predicate<ActivitySource>)
or a list ofEnableSource(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 https://github.com/open-telemetry/opentelemetry-dotnet/pull/5353 for more details.