-
Notifications
You must be signed in to change notification settings - Fork 893
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
Support complex attributes in the Event API #4334
base: main
Are you sure you want to change the base?
Conversation
19dc563
to
115a189
Compare
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.
A prototype in OTel Go: open-telemetry/opentelemetry-go#6017
The Go SIG strongly prefers: open-telemetry/opentelemetry-go#6018. However, it is also using supporting complex log attributes. Therefore, still an approval from my side as it makes this prototype more aligned.
Quick question/clarification - since this strikes me as extending the common attribute definition (https://opentelemetry.io/docs/specs/otel/common/), are we limiting the depth of complex attributes? |
We have limits on the number of attributes https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/sdk.md#readablelogrecord. This PR would give people a workaround if they just add everything to a single complex attribute - which is concerning from reliability/performance/security perspective. |
The attribute limiting issue is already present in the existing Logs (Bridge) API. What is more there are no limits for the Body. More: |
We discussed in the Log SIG yesterday and decided that these both need to be addressed before stabilizing Events:
I'll open a tracking issue. EDIT #4335 But we don't think it's a blocker for this PR since it's a pre-existing issue for Log attributes. |
+1 |
@@ -185,8 +185,7 @@ formatted as an [event](./data-model.md#events). | |||
* [Severity Number](./data-model.md#field-severitynumber) (optional) | |||
* [Severity Text](./data-model.md#field-severitytext) (optional) | |||
* [Body](./data-model.md#field-body) (optional) | |||
* [Attributes](./data-model.md#field-attributes) (optional) Event `Attributes` conform | |||
to the [standard definition](../common/README.md#standard-attribute) of an attribute. | |||
* [Attributes](./data-model.md#field-attributes) (optional) |
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.
I wonder if we can limit this to standard attributes plus "maps" and "arrays of maps"
where map values can be
- primitives
- heterogenous array of primitives
- maps
- array of maps
in other words, do we need these?
- non-heterogeneous arrays
- arrays of arrays
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.
I think that such limitation would just add more complexity given that EmitLogRecord needs to support it.
Having different abstractions for log and event attributes seems an overkill.
Fixes #4199
Allow complex attributes on Events.
Based on discussion in open-telemetry/semantic-conventions#1651 and in today's Specification SIG meeting (recording).
The biggest struggle currently for launching the Event API is the "two property bags" problem, also known as "do I put my event key/value pairs into event attributes or into the event body?"
The Log SIG has been trying to figure out a satisfactory answer to this for a month.
The proposal from @lmolkova is to put everything into event attributes, eliminating one of these "property bags" and answering the question of where to put event key/value pairs.
The event body could still potentially be used for dumping unstructured (or possibly very large) data.
To make this work, we need complex attributes on Events.
This would allow for example "locally scoped" attributes on an event to be defined as a complex attribute in the semantic conventions, e.g. an event named
browser.page_navigation_timing
could define a complex attribute in the semantic conventions namedbrowser.page_navigation_timing
(could be the same as the event name or different), which would contain it's "locally scoped" event attributes underneath it, e.g.