Skip to content

Latest commit

 

History

History
112 lines (88 loc) · 6.01 KB

events.md

File metadata and controls

112 lines (88 loc) · 6.01 KB
Raw

Semantic Conventions for Events

Status: Experimental

This document describes the characteristics of standalone Events that are represented in the data model by LogRecords.

Semantically, an Event is a named occurrence at an instant in time. It signals that "this thing happened at this time" and provides additional specifics about the occurrence. Examples of Events might include things like uncaught exceptions, button clicks, user logout, network connection severed, etc.

In OpenTelemetry, Events are implemented as a specific type of LogRecord that conforms to the conventions included here, and Events have their own API. The API abstracts away knowledge of LogRecord so that users only deal with Event semantics.

In addition to a required name, an Event may contain a payload (data) of any type permitted by the LogRecord body. In its implementation, the Event payload (data) will constitute the Body of the LogRecord. Like all other OpenTelemetry signals, an Event has optional attribute metadata that helps describe the event context.

Over time, some Events will be specified by OpenTelemetry and will have documented payload structure, field semantics, and stability and requirement levels. Other events may be user-defined and carry bespoke user semantics. When an Event name exists in the semantic conventions, its payload structure and semantics will also be defined.

Event definition

Attribute Type Description Examples Requirement Level Stability
event.name string Identifies the class / type of event. [1] browser.mouse.click; device.app.lifecycle Required Experimental

[1]: Event names are subject to the same rules as attribute names. Notably, event names are namespaced to avoid collisions and provide a clean separation of semantics for events in separate domains like browser, mobile, and kubernetes.

General event semantics

  • An event MUST have an event.name attribute that uniquely identifies the event.
  • It MAY have standard attributes that provide additional context about the event.
  • It MAY contain a payload (data) that describes the specific details of the named event.
  • The event name uniquely identifies event structure / type of the payload (data) and the set of attributes.
  • The payload (data) MAY contain any type supported by the OpenTelemetry data model for the log body and the semantic conventions will define the expected structure of the payload (data) for the event.
  • The payload (data) SHOULD be used to represent the structure of the event.

Recommendations for defining events:

  • Use the payload (data) to represent the details of the event instead of a collection of standard attributes.
  • Events SHOULD be generated / produced / recorded using the Event API to ensure that the event is created using the configured SDK instance.
  • It's NOT RECOMMENDED to prefix the payload (data) fields with the event.name to avoid redundancy and to keep the event definition clean.
  • The events SHOULD document their semantic conventions including event name, attributes, and the payload.

Event payload (data)

  • Common attribute naming conventions and registry requirements don't apply to event payload fields.
  • The definition for OpenTelemetry defined events supports describing individual fields (Body Fields)
    • The fields are unique to the named event (event.name) and different events may use the same field name to represent different data, due to the unique nature of the event.
  • The fields MAY reference / inherit details from the attribute registry attributes and provide additional details specific to the event, including providing an alias (shorter) name for the attribute.

External event compatibility

When recording events from an existing system as OpenTelemetry Events, it is possible that the existing system does not have the equivalent of a name or requires multiple fields to identify the structure of the events. In such cases, OpenTelemetry recommends using a combination of one or more fields as the name such that the name identifies the event structurally. It is also recommended that the event names have low-cardinality, so care must be taken to use fields that identify the class of Events but not the instance of the Event.