Events API Interface
Status: Experimental
The Event API consists of these main components:
- EventLoggerProvider is the entry point of the API. It provides access to
EventLogger
s. - EventLogger is the component responsible for emitting events.
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.
EventLoggerProvider
EventLogger
s 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, thename
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.
EventLogger
s 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 EventLogger
s 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.
EventLogger
The EventLogger
is the entrypoint of the Event API, and is responsible for
emitting Events
as LogRecord
s.
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.
Parameters:
- The
Name
of the Event, as described in event.name 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. EventAttributes
provide additional details about the Event which are not part of the well-definedPayload
.
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.