Update Attributes field type in Logs Data Model

[pellared]

Changes

Change the type of Attributes to reference the common definition of attributes collection.

Why

None language currently supports "nested values" in log attributes. All of them represent attributes in the same way for all signals.

• Java (stable logs): reuses a common attribute type and a map as value is not supported
• .NET (stable logs): models attributes (for all signals) as KeyValuePair<string, object?> and a map as value is not supported by OTLP exporter
• C++ (stable logs): reuses a common attribute type and a map as value is not supported
• Python (experimental logs): reuses a common attribute type and a map as value is not supported

I feel it would be awkward if attributes in different signals would be modeled differently especially that attributes are defined in the specification separately in a "common" directory. Moreover, the common definition of attributes collection even mentions logs attributes:

opentelemetry-specification/specification/common/README.md

Line 128 in 12cd1b1

[Log Records](../logs/data-model.md) may contain a collection of attributes. The

If we would like to have "nested values" in attributes then I think that it should be addressed as part of #376.

I think that the most important thing is to handle "nested values" in Body so that logs can handle structured log records (events).

EDIT: However, a lot of logging attributes allow adding nested/structured attributes to the log records.

These changes can be seen as breaking. However, there is 100% precedence of how log attributes and resource are currently handled in all languages that have logs marked as stable and experimental (except Erlang which I have not checked).

Related PRs:

• Support maps and heterogeneous arrays as attribute values #2888
• log: Add design doc opentelemetry-go#4809

[pellared]

SIG meeting notes:

1. The languages' Bridge API can (probably) still add support for log attributes in a backwards compatible way (e.g. by making it possible to set LogAttributes (which can support nested values) and Attributes (which are the "common" attributes).
2. Some called out that nested attributes for logs are problematic (and unwelcome) for backends as they cannot be handled as efficiently as common attributes.

[pellared]

After digesting all the information I decide to mark the PR as draft and wait until the resolution of #2888. If it is merged then this PR could be probably stay as it is. Otherwise, it would be probably good to add notices that log attributes are different from (a superset of) common attributes.

[github-actions]

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