-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
[elasticsearchexporter] Consistently store the structured body of logs and events in otel
mode
#37387
base: main
Are you sure you want to change the base?
Conversation
otel
modeotel
mode
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
code change lgtm, thanks
Co-authored-by: Carson Ip <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, thanks!
Hey @andrzej-stencel, I think this is ready to be merged. Could you have a look? 🙂 |
# Use this changelog template to create an entry for release notes. | ||
|
||
# One of 'breaking', 'deprecation', 'new_component', 'enhancement', 'bug_fix' | ||
change_type: breaking |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The otel
mapping mode used to be unstable, but that warning has been removed in the latest version, v0.118.0. This change is now a breaking change in a Beta stability component. What are the consequences to users upgrading the collector? Will this cause the data to be rejected by Elasticsearch? Can this be somehow alleviated by the user?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Data will still be ingested, no rejections. It will just be mapped differently. The field body.structured
already exists, it will just be used for all kinds of bodies.
The OTel community has reached a consensus that all structured data for events defined by semantic conventions should be stored in attributes (open-telemetry/semantic-conventions#1651 (comment)). The body for events may contain opaque/external data, which sounds like a job for the flattened field type.
Therefore, it no longer makes sense to map the body for logs and events differently.
The corresponding Elasticsearch mapping change has been merged already: elastic/elasticsearch#120547