[Feature request]: Support instrumentation scope attributes on ActivitySource

[lmolkova]

When creating a tracer (ActivitySource) users should be able to specify a set of instrumentation scope attributes - https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/api.md#get-a-tracer.
See open-telemetry/opentelemetry-dotnet#4316 for the context.

Instrumentation scope attributes can be used to reduce instrumentation overhead and reduce the over-the-wire size of attributes.

For example, Azure SDK provides Azure resource provider namespace is used by Azure Monitor (and can be used by other backends) to show icons, find corresponding resources in Azure, and allow navigating to them, etc. this value is constant for a given tracer and should be passed as an instr scope attribute rather than span attribute.

.NET does not allow to provide such attributes as of today.

proposal added by @tarekgh

Proposal

namespace System.Diagnostics;

    public sealed class ActivitySource : IDisposable
    {
        public ActivitySource(string name, string? version = "") { ... }
+       public ActivitySource(string name, string? version, IEnumerable<KeyValuePair<string, object?>>? tags) { ... }

+       public IEnumerable<KeyValuePair<string, object?>>? Tags { get; }
    }

Alternative Proposal

namespace System.Diagnostics;

    public class ActivitySourceOptions
    {
        public ActivitySourceOptions(string name) {    }

        public string Name { get; set; }
        public string? Version { get; set; }
        public IEnumerable<KeyValuePair<string, object?>>? Tags { get; set; }
    }

    public sealed class ActivitySource : IDisposable
    {
        ...
        public ActivitySource(ActivitySourceOptions options) { ... }
        
        public IEnumerable<KeyValuePair<string, object?>>? Tags { get; }
    }

[ghost]

Tagging subscribers to this area: @tarekgh, @tommcdon, @pjanotti
See info in area-owners.md if you want to be subscribed.

Issue Details

---

See open-telemetry/opentelemetry-dotnet#2417

When an instrumentation library emits telemetry, it usually follows specific semantic conventions. E.g. HTTP traces should follow Http semconv

However, OTel has yet to declare its first semantic conventions as stable and they change a lot.
Even after stability is declared, new attributes can be added or altered in a non-breaking manner. In the worst case, OTel may introduce breaking changes to semconv and bump a major version.

So, it's important to know which version of OTel semconv instrumentation emits for the consumers of such telemetry.
From otel perspective, instrumentations that don't populate SchemaUrl can't change at all until they start to emit SchemaUrl.

In the absence of SchemaUrl Azure SDKs in .NET populate it as an attribute on all spans using its own custom convention and increasing telemetry size with redundant information (SchemaUrl is passed as part of instrumentation scope, which is sent over the wire per batch of spans).

In addition to SchemaUrl, there are other parameters instrumentations may provide when obtaining tracers(ActivitySources) or meters - https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/api.md#get-a-tracer.

See open-telemetry/opentelemetry-dotnet#4316 for the context.

Instrumentation scope attributes can be used to reduce instrumentation overhead and reduce the over-the-wire size of attributes.

Author:	lmolkova
Assignees:	-
Labels:	area-System.Diagnostics.Tracing, untriaged, needs-area-label
Milestone:	-

[tommcdon]

Assigning to @noahfalk to help coordinate

[tarekgh]

This is a duplicate of #63651. @lmolkova can we close this and continue the discussion on the other one?

CC @cijothomas @reyang

[ghost]

Tagging subscribers to this area: @dotnet/area-system-diagnostics-activity
See info in area-owners.md if you want to be subscribed.

Issue Details

---

See open-telemetry/opentelemetry-dotnet#2417

When an instrumentation library emits telemetry, it usually follows specific semantic conventions. E.g. HTTP traces should follow Http semconv

However, OTel has yet to declare its first semantic conventions as stable and they change a lot.
Even after stability is declared, new attributes can be added or altered in a non-breaking manner. In the worst case, OTel may introduce breaking changes to semconv and bump a major version.

So, it's important to know which version of OTel semconv instrumentation emits for the consumers of such telemetry.
From otel perspective, instrumentations that don't populate SchemaUrl can't change at all until they start to emit SchemaUrl.

In the absence of SchemaUrl Azure SDKs in .NET populate it as an attribute on all spans using its own custom convention and increasing telemetry size with redundant information (SchemaUrl is passed as part of instrumentation scope, which is sent over the wire per batch of spans).

In addition to SchemaUrl, there are other parameters instrumentations may provide when obtaining tracers(ActivitySources) or meters - https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/api.md#get-a-tracer.

See open-telemetry/opentelemetry-dotnet#4316 for the context.

Instrumentation scope attributes can be used to reduce instrumentation overhead and reduce the over-the-wire size of attributes.

Author:	lmolkova
Assignees:	noahfalk
Labels:	enhancement, area-System.Diagnostics.Tracing, area-System.Diagnostics.Activity
Milestone:	9.0.0

[lmolkova]

thanks @tarekgh and sorry I did not find the original issue. The original one still does not cover the instrumentation scope attributes, so I'd prefer to keep it open. I'll modify the description to scope the issue to them.

[tarekgh]

Thanks @lmolkova for clarification. We already done #84321 in .NET 8.0. Is that what you are asking for? or you want to have the same for ActivitySource too?

[lmolkova]

Cool! Yes, I mean ActivitySource, great to know it's addressed on meters.

[tarekgh]

open-telemetry/opentelemetry-dotnet#3636

[terrajobst]

Video

• We should make it simpler
  • Have one method with just the required parameter (name)
  • Have one method that takes all the optional parameters
  • We can't remove methods, but we can hide them and remove all optionality to avoid ambiguity

namespace System.Diagnostics;

public partial class ActivitySource
{
    // Existing, left as-is
    // public ActivitySource(string name);

    // Existing, remove optionality and mark EB never
    [EditorBrowsable(EditorBrowsableState.Never)]
    public ActivitySource(string name, string? version);

    // New
    public ActivitySource(string name, string? version = "", IEnumerable<KeyValuePair<string, object?>>? tags = default);

    public IEnumerable<KeyValuePair<string, object?>>? Tags { get; }
}