[Blocked] Add empty value attribute

[pellared]

Blocked by:

• Allow adding new attribute types #4602

Related OTEP: https://github.com/open-telemetry/opentelemetry-specification/blob/main/oteps/4485-extending-attributes-to-support-complex-values.md

To be precise:

opentelemetry-specification/oteps/4485-extending-attributes-to-support-complex-values.md

Lines 40 to 48 in 8aa1d27

	- **Complex attributes** include all other values supported by the `AnyValue` proto,
	such as null (empty) value, maps, heterogeneous arrays, and combinations of those with primitives.
	Byte arrays are also considered complex attributes, as they are excluded from
	the current definition of *standard* attributes.
	- **AnyValue** represents the type of *any* (simple or complex) attribute value on
	the API, SDK, and [proto level](https://github.com/open-telemetry/opentelemetry-proto/blob/42319f8b5bf330f7c3dd4a097384f9f6d5467450/opentelemetry/proto/common/v1/common.proto#L28-L40).
	It's also known as `any` in the [Log data model](https://github.com/open-telemetry/opentelemetry-specification/blob/v1.44.0/specification/logs/data-model.md#type-any)

It is also worth mentioning that it is already allowed by OTLP:

message AnyValue {
  // The value is one of the listed fields. It is valid for all values to be unspecified
  // in which case this AnyValue is considered to be "empty".
  oneof value {

Prototype:

• [Prototype] attribute: add complex value types opentelemetry-go#6809

Also fixes #4468

as it removes the portion which said that extending the attribute types is a breaking change as it was already approved via #4485.

This is necessary to be able to represent an empty (that is the default) Log Record Body using "Standard Attributes".

This is needed towards stabilization of OTel Go Logs API and SDK (we need it "stable" though; not only "development"); more:

• Logs to reuse attribute.[Key]Value and remove log.[Key]Value types opentelemetry-go#7034

I also checked the stable Logs API implementations (according to https://opentelemetry.io/status) and none of them seem to be strictly compliant with the specification in regards of Log Record Body value:

• in Java it is an optional String or Value<T> which does not support setting an empty value: https://github.com/open-telemetry/opentelemetry-java/blob/dc2874e2fa4696bf15c31ae60644bac2dfc546b9/api/all/src/main/java/io/opentelemetry/api/logs/LogRecordBuilder.java#L76-L91; therefore I think this change would be also very welcome for OTel Java, CC @open-telemetry/java-approvers
• in .NET Body is an optional string?: https://github.com/open-telemetry/opentelemetry-dotnet/blob/361a1655b9ac239b88fbd7ae51048ec9066774d9/src/OpenTelemetry/Logs/LogRecord.cs#L251
• PHP is allowing setting any value (therefore also values that are not valid): https://github.com/open-telemetry/opentelemetry-php/blob/2421c64c51c1a5f7e13cd48bc4bf09d263233b3a/src/API/Logs/LogRecord.php#L84-L92

[pellared]

CC @open-telemetry/go-maintainers

[lmolkova]

I think we need to start with proto changes and replace comments like https://github.com/open-telemetry/opentelemetry-proto/blob/be5d58470429d0255ffdd49491f0815a3a63d6ef/opentelemetry/proto/trace/v1/trace.proto#L209-L213

// The OpenTelemetry API specification further restricts the allowed value types:
// https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/README.md#attribute
// Attribute keys MUST be unique (it is not allowed to have more than one
// attribute with the same key).

(as per https://github.com/open-telemetry/opentelemetry-specification/blob/main/oteps/4485-extending-attributes-to-support-complex-values.md#proto)

we probably need to replace it with comment that they are going to be allowed in 6 months

opentelemetry-specification/oteps/4485-extending-attributes-to-support-complex-values.md

Lines 111 to 112 in 8aa1d27

	- Stable exporters will be prohibited from emitting complex attributes by default on signals
	other than Logs until at least 6 months after this OTEP is merged.

---

Or, at least, leave a note here that complex attributes are coming and their support is in development, nobody should stabilize them in the next 6 month.

[pellared]

we probably need to replace it with comment that they are going to be allowed in 6 months

I feel like this is an orthogonal PR given the changes of https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/README.md#attribute are marked with Development status.

Moreover, this PR does not make the existing comment invalid and should block this PR.

Therefore, I think a PR in proto repo can be done in parallel.
I am not sure how we want to update the comment in proto repo as of today.
Are you able to help with it?

EDIT: I tried to come up with a PR in the proto repo. PTAL:

• all: add notes about the attribute values restrictions opentelemetry-proto#683

[pellared]

As discussed in the SIG meeting, we agreed to reintroduce this "note" in this PR, since it’s clearer to handle the broader change in a separate PR. That separate PR will:

• communicate that we’ve revised the decision and will now allow the addition of new attribute types (which is not considered a major change),
• clarify that introducing new attribute types will require a minor version bump in the OTLP (proto) repository.

This PR will be blocked until that separate PR is merged.

[pellared]

I created #4602 for tracking.

[pellared]

@lmolkova, can you please block this PR (request changes) with e.g. following comment:

Blocked by:
- https://github.com/open-telemetry/opentelemetry-specification/issues/4602

so that it is not accidentally merged?

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[aabmass]

Looks like this addresses #4392, but maybe some of the concerns like a KeyValue with null value are still left up to interpretation.

[pellared]

Looks like this addresses #4392, but maybe some of the concerns like a KeyValue with null value are still left up to interpretation.

Please see my answer in #4392

[pellared]

I prefer to go forward with #4651 instead of this one (to hopefully move a little faster).