Semantic conventions for browser navigation/resource events #1
Conversation
|
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
|
|
||
| Additional attributes are mapped from the [Navigation Timing API](https://www.w3.org/TR/navigation-timing-2/#sec-PerformanceNavigationTiming). | ||
|
|
||
| This list is not exhaustive and is listed as an example. All numeric and string values thar are provided by the Navigation Timing API SHOULD be included. |
There was a problem hiding this comment.
We should call out that this should be included the event.data attribute.
|
|
||
| Additional attributes are mapped from the [Resource Timing API](https://www.w3.org/TR/resource-timing-2/#sec-performanceresourcetiming). | ||
|
|
||
| This list is not exhaustive and is listed as an example. All numeric and string values thar are provided by the Resource Timing API SHOULD be included. |
There was a problem hiding this comment.
We should call out that this should be included the event.data attribute.
There was a problem hiding this comment.
Should all events always add their attributes in event.data? If yes, then I think we should add it to the spec for the event.* attributes, which is currently proposed in open-telemetry#2676.
There was a problem hiding this comment.
My thoughts are yes, they should always be added.
There was a problem hiding this comment.
Its also a case that as part of the "Nested Attribute" support I included wording about effectively exporters needing to use a strategy to handle when they receive nested attributes, which includes the default (already mentioned as an option) using JSON.stringify()
| |---|---|---|---|---| | ||
| | `event.name` | string | The event name that uniquely identifies the type of the event within the domain. | `exception`; `interaction` | Required | | ||
| | `event.domain` | string | Identifies the group of related events. Each event within a domain MUST have a unique value for the event.name attribute. | `browser`; `mobile` | Recommended | | ||
| | `event.data` | any | It is recommended that event attributes are sent as a nested object value in this attribute. [1] | Recommended | |
There was a problem hiding this comment.
Because of the way that JSON will support nested attributes (causing an explosion), perhaps we should also support having this as a JSON encoded string?? As this could then also be used for a span.event as it's looking VERY likely that it will be a loooong time (if ever) before we could update span events to support nesting (at least at this point)
But lets leave the JSON string out for now -- just calling this out as a fallback position.
|
Closed as inactive. Feel free to reopen if this PR is still being worked on. |
|
Closed as inactive. Feel free to reopen if this PR is still being worked on. |
|
Closed as inactive. Feel free to reopen if this PR is still being worked on. |
|
Closed as inactive. Feel free to reopen if this PR is still being worked on. |
This is a draft of semantic conventions for browser navigation and resource events. It proposed a template for defining semantic conventions for events.
In summary:
eventssubfolder under /logs/semantic_conventionsevents.*attributes, which are required to be present for any event/logs/semantic_conventions/events/browserfor all browser-related eventsevent.nameandevent.domainattributes