Logs API and SDK: logs attributes are allowed to have AnyValue values

[lmolkova]

Spec requires log API to support any in attribute types https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#field-attributes

The log attribute model MUST support any type,
a superset of standard Attribute,
to preserve the semantics of structured attributes emitted by the applications.

LogRecord uses the same Attributes type as other signals and does not support any attribute value

opentelemetry-python/opentelemetry-api/src/opentelemetry/util/types.py

Lines 18 to 27 in f639606

	AttributeValue = Union[
	str,
	bool,
	int,
	float,
	Sequence[str],
	Sequence[bool],
	Sequence[int],
	Sequence[float],
	]

The recommendation is to:

1. Keep supporting standard Attributes - see Attributes "hell" opentelemetry-specification#4201 for the context
2. Add log-specific attributes type that can take anyvalue and accept it as well

As long as p2 can be done incrementally, the lack of it should not block logs API/SDK stability.
It might, however block stability of logging handler bridge which should be able to create anyvalue attributes.

Part of open-telemetry/community#1751

[aabmass]

The recommendation is to:

1. Keep supporting standard Attributes - see Attributes "hell" opentelemetry-specification#4201 for the context
2. Add log-specific attributes type that can take anyvalue and accept it as well

We already have AnyValue here

opentelemetry-python/opentelemetry-api/src/opentelemetry/util/types.py

Lines 18 to 30 in 2ddb076

	# This is the implementation of the "Any" type as specified by the specifications of OpenTelemetry data model for logs.
	# For more details, refer to the OTel specification:
	# https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#type-any
	AnyValue = Union[
	str,
	bool,
	int,
	float,
	bytes,
	Sequence["AnyValue"],
	Mapping[str, "AnyValue"],
	None,
	]

IIUC, we should just use that in place of Attributes in the Logs API/SDK?

[lmolkova]

we can't change Attributes definition for spans and metrics - those don't support AnyValue on the API level.
For logs, we should have a way to add AnyValue attribute, but we should make sure it's easy to keep using the same Attributes type as for spans and metrics.

I'm not an expert in Python API design and there could be much nicer ways to achieve it, but I'd create a LogAttributes union (with AnyValue supported) and accepted Union[Attributes | LogAttributes] in LogRecord ctor.

[aabmass]

👍 I'm just proposing to change it for the Logging API only and leave other signals with the existing Attributes type.

I'm not an expert in Python API design and there could be much nicer ways to achieve it, but I'd create a LogAttributes union (with AnyValue supported) and accepted Union[Attributes | LogAttributes] in LogRecord ctor.

Since Attributes is a subset of AnyValue, there shouldn't be any functional different vs using AnyValue directly. Is this more of a readability concern?

[lzchen]

IIUC, we should just use that in place of Attributes in the Logs API/SDK?

I believe we would replace AttributeValue with AnyValue. Isn't that all that is needed?

[lmolkova]

I think it's also important to allow standard Attributes to be populated on logs - see open-telemetry/opentelemetry-specification#4201

I.e. I should be able to write

attributes = Attributes(...)
counter.add(1, attributes=attributes)
logger.emit(LogRecord(..., attributes=attributes)

if LogRecord takes LogAttributes only, users would need to do manual conversion between types (which is inefficient and increases complexity).

PS: please ignore my concern if pythonic implicit type conversions make it irrelevant. In any case, I suggest to write a test that uses standard attributes on a log record and make sure it works and does not raise type-checker errors

[aabmass]

PS: please ignore my concern if pythonic implicit type conversions make it irrelevant.

Ah yes that's the case, Attributes just describes a structural type which is implicit implemented, not a named class.

attributes = {"foo": "bar"}
counter.add(1, attributes=attributes)
logger.emit(LogRecord(..., attributes=attributes)

should work fine

[lzchen]

I believe we would replace AttributeValue with AnyValue. Isn't that all that is needed?

We should probably still do this no?

[xrmx]

Did a PR to check this, it's in draft because I don't want this in the next release.

[xrmx]

Removed draft from #4342