Add Attributes to Instrumentation Scope

[tigrannajaryan]

The Instrumentation Scope currently is defined as a pair of (name,version).

This is a proposal to add ability to associate Attributes with the Scope. There are currently 2 known use cases:

• Add support for Meter "short_name", represented as an attribute of Meter's Scope.
• Add support for differentiating the type of data emitted from the scopes that belong to different data domains, e.g. profiling data emitted as log records or client-side data emitted as log records needs to be differentiated so that it can be easily routed and processed differently in the backends. We don't have a good way to handle this today. The type of the data can be recorded as an attribute Logger's Scope.

There are probably other use cases possible for the Scope attributes. Please comments on this issue if you have a use case.

cc @bogdandrutu @dashpole @jmacd

[pmm-sumo]

One concern I have about adding such capability is increased complexity of the overall model.

It might bring confusion on when to associate the attribute with Resource, Scope or Record. We have seen similar issue for log data model (where attributes can be stored within body or as LogRecord attributes) and we ended up with clarifying that body-level attributes are pretty much only needed for compatibility reasons.

On top of the above, adding such such capability will require bringing additional ways to modify/move/filter them and so on. I am concerned that it might be actually easier to instead deal with slight duplication at the record-level than have another layer of Attributes at the Scope level

[tigrannajaryan]

The confusion between Body and Attributes of LogRecord was primarily because they both applied to the same LogRecord and you could easily record the same information in 2 different ways.

This is not the case for Resource, Scope or LogRecord attributes. They each are separately defined concepts, and the attributes field in each applies to that particular concept. I don't think there can be a similar confusion (this assumes Scope and LogRecord are clearly defined different concept, which I hope they are).

On top of the above, adding such such capability will require bringing additional ways to modify/move/filter them and so on. I am concerned that it might be actually easier to instead deal with slight duplication at the record-level than have another layer of Attributes at the Scope level

I think we already have to somehow deal with this, because the Scope already has a name and a version that you can modify/move/filter. We just mostly ignored it so far in the Collector.

[alanwest]

differentiating the type of data emitted from the scopes that belong to different data domains, e.g. profiling data emitted as log records or client-side data emitted as log records needs to be differentiated so that it can be easily routed and processed differently in the backends. We don't have a good way to handle this today.

I'm curious about this use case. I was under the impression that the direction being explored for client-side telemetry was to define semantic conventions that would identify it as such. I can see there being a benefit to end users in that these "client-side telemetry" identifying attributes would not need to be duplicated on every log record.

But, from the standpoint of routing/processing client-side telemetry by a backend, does it really matter if these attributes are on the scope or the log record themselves?

[tigrannajaryan]

But, from the standpoint of routing/processing client-side telemetry by a backend, does it really matter if these attributes are on the scope or the log record themselves?

I think it matters from efficiency perspective. The Scope in OTLP can contain a batch of LogRecords and the processing decision about the entire batch in the Collector can be made by looking at just one scope attribute instead of looking at all LogRecords in the batch and making decisions about each LogRecord individually.

[tsloughter]

This would be the only way to associate some attributes with all spans created by a Tracer, right? Or is there another way already? I think it would be useful for this purpose if it isn't possible another way -- aside from a custom span processor that accesses some global store that maps tracer to attributes that it can lookup and add to each span.

[tigrannajaryan]

This would be the only way to associate some attributes with all spans created by a Tracer, right? Or is there another way already?

I am not aware of a way to do it today.

[tsloughter]

Then a big +1 from me.

[tigrannajaryan]

OTEP submitted: open-telemetry/oteps#201

[tigrannajaryan]

Resolved by #2579