Below are a list of some OpenTelemetry specific terms that are used across this specification.
Denotes the library that implements the OpenTelemetry API.
See Library Guidelines and Library resource semantic conventions
Denotes the library for which the telemetry signals (traces, metrics, logs) are gathered.
The calls to the OpenTelemetry API can be done either by the Instrumented Library itself, or by another Instrumenting Library.
Example: org.mongodb.client.
Denotes the library that provides the instrumentation for a given Instrumented Library. Instrumented Library and Instrumenting Library may be the same library if it has built-in OpenTelemetry instrumentation.
Example: io.opentelemetry.contrib.mongodb.
Synonyms: Instrumentation Library, Integration.
This refers to the name and (optional) version arguments specified when
creating a new Tracer or Meter (see Obtaining a Tracer/Obtaining a Meter). It identifies the Instrumenting Library.
This term applies to Metric names only. The namespace is used to disambiguate identical metric
names used in different instrumenting libraries. The Name provided
for creating a Meter serves as its namespace in addition to the primary semantics
described here.
The version argument is not relevant here and will not be included in
the resulting namespace string.
A recording of an event. Typically the record includes a timestamp indicating when the event happened as well as other data that describes what happened, where it happened, etc.
Also known as Log Entry.
Sometimes used to refer to a collection of Log Records. May be ambiguous, since
people also sometimes use Log to refer to a single Log Record, thus this
term should be used carefully and in the context where ambiguity is possible
additional qualifiers should be used (e.g. Log Record).
Log Records embedded inside a Span
object, in the Events list.
Log Records that are not embedded inside a Span and are recorded elsewhere.
Key/value pairs contained in a Log Record.
Logs that are recorded in a format which has a well-defined structure that allows
to differentiate between different elements of a Log Record (e.g. the Timestamp,
the Attributes, etc). The Syslog protocol (RFC 5425),
for example, defines a structured-data format.
Logs recorded in text files, often one line per log record (although multiline records are possible too). There is no common industry agreement whether logs written to text files in more structured formats (e.g. JSON files) are considered Flat File Logs or not. Where such distinction is important it is recommended to call it out specifically.