Introduce Scope Attributes

[tigrannajaryan]

There are a few reasons why adding Scope attributes is a good idea:

• There are 2 known use cases where Scope attributes can solve specific problems:
  • 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.
• It makes Scope consistent with the other primary data types: Resource, Span, Metric,
  LogRecord.

See additional discussion here.

[tedsuo]

Are there prototypes available for review?

[tsloughter]

I assume different attributes, or no attributes, means it is a different Tracer?

My only concern with this is more related to implementation in languages without globals where sharing a Tracer variable isn't possible. Having to supply the attributes every time get_tracer is called would hurt the purpose as Tigran notes #201 (comment)

If attributes are treated the same as name/version/schema_url then it may be useful for us to have another operation that is for "registering" a tracer or scope so the attributes can be only set once. But this may be more implementation specific and not a concern for the spec itself.

[tigrannajaryan]

All, I made an important amendment to the OTEP.

Now it says that "The implementation MUST NOT return the same Tracer when called repeatedly with different values of parameters."

This is necessary, otherwise our use cases will not work.

Note that this is not a breaking change. Previously it was an undefined behavior, now it is defined more precisely. It is acceptable to change undefined behavior into defined and it is not a breaking change since the caller were not allowed to rely on any undefined behavior.

cc @bogdandrutu @yurishkuro @alanwest @scheler @arminru @blumamir @jack-berg

[tigrannajaryan]

I assume different attributes, or no attributes, means it is a different Tracer?

@tsloughter yes. I made a clarification here.

[tigrannajaryan]

@bogdandrutu @yurishkuro @alanwest I made an important change in a new commit. I will re-request your review to make sure you saw the change.

[tigrannajaryan]

@tedsuo I agree with you.

The Scopes attributes as they are defined by this OTEP are not a very good fit for capturing the session id. The Scope attributes API defined by this OTEP is targeted for use-cases, which know upfront, at the time of Tracer/Meter/LogEmitter creation what the attributes values should be and sets them once and for the entire lifetime of the Tracer/Meter/LogEmitter.

The session id appears to be a different beast. It can change any time and these changes are not synchronized in any way to the lifetime of the Tracer/Meter/LogEmitter as it is understood by Otel APIs today.

I think you do need a different mechanism for session ids. Perhaps the right framing for session id is "enrichment" or "on the fly modification". All emitted telemetry is enriched by an attribute called "session_id", the value of which can be provided by a user-defined function. From this perspective it appears the notion of the "Provider" that you suggest can be the right approach.

I think we can continue the session id discussion in its own thread (your doc or in a new OTEP). I am happy to keep this OTEP open for a while. I want to make sure we find a good, different solution for sessions ids, a solution which does not rely on Scope Attributes and does not require changes to this OTEP.

[tedsuo]

Great, sounds good.

[Oberon00]

@tedsuo I had similar thoughts at first: #201 (comment)

While this is for sharing attributes that apply to all emitters, there are more "scopes" thinkable over which you could share attributes, e.g. open-telemetry/opentelemetry-specification#335 / open-telemetry/opentelemetry-specification#1143 would probably call for sharing attributes on some subtree of a trace, or on a subset of spans created by an telemetry producer (e.g. something like open-telemetry/opentelemetry-specification#579)

[tigrannajaryan]

We have a confirmation from Go maintainer that the OTEP is implementable in Go.

[tigrannajaryan]

@jack-berg since you approved can I assume that it means you think the OTEP is implementable in Java?

[tigrannajaryan]

@blumamir do you think the OTEP is implementable in a reasonably performant way in JS SDK?

[tigrannajaryan]

We have a confirmation from Java maintainers that this OTEP is implementable.

[tigrannajaryan]

We have a confirmation from Python maintainers that this OTEP is implementable.

[tigrannajaryan]

We have a confirmation from Ruby maintainers that this OTEP is implementable.

[tigrannajaryan]

I think we now have sufficient confirmations from many maintainers to be confident that the OTEP is implementable.

If you still have any concerns please comment.

[tigrannajaryan]

I resolved all comments. I will keep this open for a bit longer to give people time to object. Unless I hear objections I will merge it.

[carlosalberto]

We have had this open enough time and have enough approvals/confirmation. Let's merge.