Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify handling empty (null) values in Logs Data Model #3835

Closed
pellared opened this issue Jan 19, 2024 · 2 comments · Fixed by #3853
Closed

Clarify handling empty (null) values in Logs Data Model #3835

pellared opened this issue Jan 19, 2024 · 2 comments · Fixed by #3853
Assignees
Labels
[label deprecated] triaged-accepted [label deprecated] Issue triaged and accepted by OTel community, can proceed with creating a PR spec:logs Related to the specification/logs directory

Comments

@pellared
Copy link
Member

pellared commented Jan 19, 2024

The Logs Data Model tells nothing about handling empty (null) values (e.g. for attributes).

See: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#type-any

I think that the specification should include some clarification similarly to: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/README.md#attribute.

I think that in "maps" an empty (null) value SHOULD be an acceptable value (only the key MUST be not null or empty). It is pretty common to have empty field values in complex structures and users would most likely preserved empty data e.g. in log attributes.

Take into consideration that it some languages it is not possible to define an API that would not accept a "null value" (e.g. zero value in Go). The implementation would have to take care of the empty value passed by the caller. Moreover, from https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/common/README.md#attribute:

However, if it is impossible to make sure that no null values are accepted (e.g. in languages that do not have appropriate compile-time type checking), null values within arrays MUST be preserved as-is

CC @open-telemetry/specs-logs-approvers

Related PR: pellared/opentelemetry-go#7

@pellared pellared added the spec:logs Related to the specification/logs directory label Jan 19, 2024
@pellared pellared changed the title Handling empty (null) values in Logs Data Model Clarify handling empty (null) values in Logs Data Model Jan 19, 2024
@yurishkuro
Copy link
Member

The common part is already pretty detailed about what to do with empty attributes. What specifically do you think is missing for 🪵?

@pellared
Copy link
Member Author

Common attributes definition is different from log attributes. I was thinking about putting similar description to Logs Data Model.

@reyang reyang added the [label deprecated] triaged-accepted [label deprecated] Issue triaged and accepted by OTel community, can proceed with creating a PR label Jan 24, 2024
carlosalberto pushed a commit that referenced this issue Mar 8, 2024
Fixes
#3835

## Changes

- Define empty value as an acceptable type for `any`

I think that adding support for additional type is not a breaking
change. I also think that users may also want to preserve the empty
values that are in structured data (e.g. record body and attributes)
that they emit in their applications.

E.g. `slog` a structured logging package which is part of Go standard
library accepts `nil` (null, empty value) as a valid attribute value.
The Bridge API should do its best to carry over as much logging data as
possible until it is can be passed via OTLP . See:
https://go.dev/play/p/KN5Wea6h_f-
carlosalberto pushed a commit to carlosalberto/opentelemetry-specification that referenced this issue Oct 31, 2024
Fixes
open-telemetry#3835

## Changes

- Define empty value as an acceptable type for `any`

I think that adding support for additional type is not a breaking
change. I also think that users may also want to preserve the empty
values that are in structured data (e.g. record body and attributes)
that they emit in their applications.

E.g. `slog` a structured logging package which is part of Go standard
library accepts `nil` (null, empty value) as a valid attribute value.
The Bridge API should do its best to carry over as much logging data as
possible until it is can be passed via OTLP . See:
https://go.dev/play/p/KN5Wea6h_f-
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[label deprecated] triaged-accepted [label deprecated] Issue triaged and accepted by OTel community, can proceed with creating a PR spec:logs Related to the specification/logs directory
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants