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.
• Allow attribute collections to contain duplicate keys via an opt-in configuration (as this is allowed for log attributes).
• 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.

Closes #4460 (no longer needed - feature is removed)

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.

Comments to be addressed as followups

I am going to create issues to be created after this is PR merged:

• Extend the set of attribute value types #4651 (comment)
• Extend the set of attribute value types #4651 (comment)
• Extend the set of attribute value types #4651 (comment)

[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.}