Extend the set of attribute value types

[pellared]

Changes

• Introduce of AnyValue type supporting complex data structures (empty value, byte arrays, heterogeneous arrays and maps).
• Consolidate of attribute definitions across signals to use the unified AnyValue type.
• Update attribute limits to accommodate new value types.
• Remove "standard attribute" terminology in favor of general "attribute".

Extend attribute types

Prior-art (this PR guides towards this): #4636

Prototype: open-telemetry/opentelemetry-go#6809

Follows #4614

Related to #4602

Related proto PR: open-telemetry/opentelemetry-proto#707

https://github.com/open-telemetry/opentelemetry-specification/blob/main/oteps/4485-extending-attributes-to-support-complex-values.md#how describes how languages should add support for new attribute value types.

OTEP changes

Notice that this PR has changed the strategy for https://github.com/open-telemetry/opentelemetry-specification/blob/main/oteps/4485-extending-attributes-to-support-complex-values.md#api from:

OTel API MAY support setting complex attributes on metrics, resources, instrumentation scope, span events, and as identifying entity attribute

to simply:

OTel API MUST support setting complex attribute.

This is the agreement up to this point: #4651 (comment)

The other change in the OTEP is because of #4651 (comment).

Attribute limit updates

Towards #4487

This also proposes minimal and non-breaking additions for the attribute limits: https://github.com/open-telemetry/opentelemetry-specification/blob/main/oteps/4485-extending-attributes-to-support-complex-values.md#attribute-limits.

The proposal for attribute count limit is proposed because of #4651 (comment).

• Predictability: Users can more easily understand and predict when they'll hit the limit. Especially given the existing behavior of attribute count limit.
• Practical usage: Maps are typically used as cohesive units of related data, so counting them as single attributes aligns with their semantic purpose. Without this rule, a single map attribute with many internal key-value pairs could quickly exhaust the attribute count limit, which would be surprising behavior for users.

The proposal for attribute value length limit seems the most logical to me.

[tigrannajaryan]

This is partially duplicated above on line 80. Can we have this requirement consolidated in one place?

[pellared]

We can do it after the part where line 80 is located is stable. Right now it is hard to consolidate.

[tigrannajaryan]

Applies only to the "value" of the map but not the "key" of the map?

[pellared]

Correct. We were never applying limits for the keys. Moreover, the limit is called "attribute value limit".

[Copilot]

Pull Request Overview

Copilot reviewed 22 out of 22 changed files in this pull request and generated 4 comments.

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[tsloughter]

Why is this changing to now support null? It isn't able to be represented by the protos still, right? I know below it says to then convert to a value like 0 or false, but why allow it for AnyValue in the first place?

And can it change to say, "if supported by the language"? There is not a true null or undefined in Erlang and as this is written it sounds like there is need to support representing this rather than putting it on the user to do their own mapping to an allowed value like 0 or "" if they don't want a string representation of the atom they used to represent the lack of a value.

[pellared]

Why is this changing to now support null?

It is currently supported by any from the Logs Data Model.

More context: #3853

And can it change to say, "if supported by the language"?

Personally, I am fine with this.

[pellared]

See #4651 (comment)

EDIT: 6c8418e