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

Add support for empty values in Logs Data Model #3853

Merged
merged 24 commits into from
Mar 8, 2024

Conversation

pellared
Copy link
Member

@pellared pellared commented Jan 31, 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-

@pellared pellared marked this pull request as ready for review January 31, 2024 11:39
@pellared pellared requested review from a team January 31, 2024 11:39
@pellared pellared requested a review from MrAlias January 31, 2024 17:44
@pellared pellared marked this pull request as draft January 31, 2024 18:19
@pellared pellared changed the title Define handling of empty keys and values in Logs Data Model Add support for empty values in Logs Data Model Jan 31, 2024
@pellared pellared marked this pull request as ready for review January 31, 2024 18:43
specification/logs/data-model.md Outdated Show resolved Hide resolved
specification/logs/data-model.md Outdated Show resolved Hide resolved
specification/logs/data-model.md Outdated Show resolved Hide resolved
specification/logs/data-model.md Outdated Show resolved Hide resolved
@pellared
Copy link
Member Author

@jack-berg @tigrannajaryan I updated the PR. PTAL

@tigrannajaryan
Copy link
Member

I believe this should be treated as a backward compatible change because:

  1. From API callers perspective it widens the API, so no existing code should break.
  2. From data consumers perspective nothing changes since OTLP already explicitly allows empty values, so consumers must be already prepared for this.

Does anyone think this is an incorrect interpretation of our compatibility rules?

Copy link
Member

@trask trask left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

makes sense to me because it's needed for faithfully bridging existing logging systems

@MrAlias MrAlias mentioned this pull request Mar 6, 2024
@carlosalberto carlosalberto merged commit a0aee78 into open-telemetry:main Mar 8, 2024
7 checks passed
carlosalberto pushed a commit to carlosalberto/opentelemetry-specification that referenced this pull request 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
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Clarify handling empty (null) values in Logs Data Model
9 participants