Events API Interface

Status: Experimental

The Event API consists of these main components:

Data model

Wikipedia’s definition of log file:

In computing, a log file is a file that records either events that occur in an operating system or other software runs.

From OpenTelemetry’s perspective LogRecords and Events are both represented using the same data model.

However, OpenTelemetry does recognize a subtle semantic difference between LogRecords and Events: Events are LogRecords which have a name which uniquely defines a particular class or type of event. All events with the same name have Payloads that conform to the same schema, which assists in analysis in observability platforms. Events are described in more detail in the semantic conventions.

Unlike the Logs Bridge API, application developers and instrumentation authors are encouraged to call this API directly.


EventLoggers can be accessed with a EventLoggerProvider.

Normally, the EventLoggerProvider is expected to be accessed from a central place. Thus, the API SHOULD provide a way to set/register and access a global default EventLoggerProvider.

EventLoggerProvider operations

The EventLoggerProvider MUST provide the following functions:

  • Get an EventLogger

Get an EventLogger

This API MUST accept the following parameters:

  • name: This name uniquely identifies the instrumentation scope, such as the instrumentation library (e.g. io.opentelemetry.contrib.mongodb), package, module or class name. If an application or library has built-in OpenTelemetry instrumentation, both Instrumented library and Instrumentation library may refer to the same library. In that scenario, the name denotes a module name or component name within that library or application.

  • version (optional): Specifies the version of the instrumentation scope if the scope has a version (e.g. a library version). Example value: 1.0.0.

  • schema_url (optional): Specifies the Schema URL that should be recorded in the emitted telemetry.

  • attributes (optional): Specifies the instrumentation scope attributes to associate with emitted telemetry. This API MUST be structured to accept a variable number of attributes, including none.

EventLoggers are identified by name, version, and schema_url fields. When more than one EventLogger of the same name, version, and schema_url is created, it is unspecified whether or under which conditions the same or different EventLogger instances are returned. It is a user error to create EventLoggers with different attributes but the same identity.

The effect of associating a Schema URL with a EventLogger MUST be that the telemetry emitted using the EventLogger will be associated with the Schema URL, provided that the emitted data format is capable of representing such association.


The EventLogger is the entrypoint of the Event API, and is responsible for emitting Events as LogRecords.

EventLogger Operations

The EventLogger MUST provide functions to:

Emit Event

The effect of calling this API is to emit an Event to the processing pipeline.


  • The Name of the Event, as described in semantic conventions.
  • The (AnyValue) (optional) Payload of the Event.
  • The Timestamp (optional) of the Event.
  • The Context (optional) associated with the Event.
  • The SeverityNumber (optional) of the Event.
  • The Attributes (optional) of the Event. Event Attributes provide additional details about the Event which are not part of the well-defined Payload.

Optional and required parameters

The operations defined include various parameters, some of which are marked optional. Parameters not marked optional are required.

For each optional parameter, the API MUST be structured to accept it, but MUST NOT obligate a user to provide it.

For each required parameter, the API MUST be structured to obligate a user to provide it.