Define attributes equality and make all fields as identifying for Tracer, Meter, Logger, EventLogger

[pellared]

Fixes #4160 (prior art: #4146)

Python SDK, PHP SDK look to be compliant with the proposal. AFAIK these are the only languages which handle scope attributes in their stable releases.

Additional note: I do not want to merge it before I prototype it in the Go SDK. However, I want to have some "acceptance" before writing the prototype. PoC in Go: open-telemetry/opentelemetry-go#5806

Remarks: I do not feel competent to handle similar issue for instruments in metrics. Especially how to refine the duplicate instrument registration section. I decided to leave this section untouched.

[pellared]

@yurishkuro, you can take a look if this is inline with your #4146 (comment)

[pellared]

PTAL @jmacd @tigrannajaryan

[tigrannajaryan]

@open-telemetry/specs-approvers

This is a change in Stable docs. We need to decide if it is allowed.

We are essentially saying that a behavior that was previously a user error (repeatedly obtain Tracer/Meter/Logger with the same name/version/schema_url and different attributes) is now valid.

Can we treat this as a backward compatible, non-breaking enhancement that fits our stability guarantees?

[pellared]

@open-telemetry/specs-approvers

This is a change in Stable docs. We need to decide if it is allowed.

We are essentially saying that a behavior that was previously a user error (repeatedly obtain Tracer/Meter/Logger with the same name/version/schema_url and different attributes) is now valid.

Can we treat this as a backward compatible, non-breaking enhancement that fits our stability guarantees?

For reference, From mentioned issue description:

It is also unclear why scope attributes are not taking part of being one of the "identifying fields" and why all fields cannot be used to identify an instrument. From my database experience adding a column to a primary key it is an acceptable change/migration.

[yurishkuro]

We are essentially saying that a behavior that was previously a user error (repeatedly obtain Tracer/Meter/Logger with the same name/version/schema_url and different attributes) is now valid.

That is generally considered a backwards compatible change, because it relaxes the input requirements of the API. A step in the opposite direction (error where there wasn't one previously) would be a breaking change.

[pellared]

Status update:
In August, I am on vacation. I am perfectly fine if someone takes the issue/PR after me to keep the momentum.
In September, I plan to make a [draft] PR in OTel Go.

[dashpole]

I think this needs updates to some of the compatibility docs (at least prometheus). Currently, Prometheus adds scope name and scope version as labels to ensure we don't end up with duplicate timeseries, and we are able to put scope attributes in a separate otel_scope_info metric. With this change, we will need to update this to instead add the scope name, scope version, and scope attributes to all metrics.

TIL schema_url is also identifying, so that is something we will need to handle in Prometheus export and other "non-OTLP" compatibility documents.

[pellared]

I think this needs updates to some of the compatibility docs (at least prometheus). Currently, Prometheus adds scope name and scope version as labels to ensure we don't end up with duplicate timeseries, and we are able to put scope attributes in a separate otel_scope_info metric. With this change, we will need to update this to instead add the scope name, scope version, and scope attributes to all metrics.

TIL schema_url is also identifying, so that is something we will need to handle in Prometheus export and other "non-OTLP" compatibility documents.

@dashpole, are you able to help with it? Do you think that it could be done in a separate PR? Should it be blocking this PR or can it be handled afterwards?

Side note: Zipkin exporter does not export scope info at all (name, version, schemeURL, attributes).