Status: Stable, Unless otherwise specified. General naming considerations This section applies to attribute names (also known as the “attribute keys”), as well as Metric and Event names. For brevity within this section when we use the term “name” without an adjective it is implied to mean all of these. Every name MUST be a valid Unicode sequence. Note: we merely require that the names are represented as Unicode sequences. This specification does not define how exactly the Unicode sequ...| OpenTelemetry
Status: Stable This section applies to Log, Metric, Resource, and Span, and describes requirement levels for attributes defined in semantic conventions. Attribute requirement levels apply to the instrumentation library. The following attribute requirement levels are specified: Required Conditionally Required Recommended Opt-In The requirement level for an attribute is specified by semantic conventions depending on attribute availability across instrumented entities, performance, security, and...| OpenTelemetry
Status: Stable All OpenTelemetry concepts and data recorded using OpenTelemetry API can be directly and precisely represented using corresponding messages and fields of OTLP format. However, for other formats this is not always the case. Sometimes a format will not have a native way to represent a particular OpenTelemetry concept or a field of a concept. This document defines the transformation between OpenTelemetry and formats other than OTLP, for OpenTelemetry fields and concepts that have ...| OpenTelemetry
Status: Stable A logical unit of software with which the emitted telemetry can be associated. It is typically the developer’s choice to decide what denotes a reasonable instrumentation scope. The most common approach is to use the name and version of the instrumentation library, with any additional identifying information as part of the scope’s attributes. Other software components can be used too to get name, version and additional attributes, e.g. a module, a package, a class or a plugin.| OpenTelemetry
Status: Development This document defines how to map (convert) arbitrary data (e.g. in-memory objects) to OTLP’s AnyValue. The mapping is needed when OpenTelemetry needs to convert a value produced outside OpenTelemetry into a value that can be exported using an OTLP exporter, or otherwise be converted to be used inside OpenTelemetry boundaries. Example use cases are the following: In the Logging SDKs, to convert values received from logging libraries into OpenTelemetry representation. In t...| OpenTelemetry
Status: Stable except where otherwise specified A Resource is an immutable representation of the entity producing telemetry as Attributes. For example, a process producing telemetry that is running in a container on Kubernetes has a Pod name, it is in a namespace and possibly is part of a Deployment which also has a name. All three of these attributes can be included in the Resource. Note that there are certain “standard attributes” that have prescribed meanings.| OpenTelemetry
Specification documents (files) may explicitly define a “Status”, typically shown immediately after the document title. When present, the “Status” applies to the individual document only and not to the entire specification or any other documents. The following table describes what the statuses mean. Maturity levels The support guarantees and allowed changes are governed by the maturity level of the document. Maturity levels are defined in OTEP 0232 and follow the OpenTelemetry project...| OpenTelemetry
Status: Mixed Users of OpenTelemetry need a way for instrumentation interactions with the OpenTelemetry API to actually produce telemetry. The OpenTelemetry SDK (henceforth referred to as the SDK) is an implementation of the OpenTelemetry API that provides users with this functionally. All language implementations of OpenTelemetry MUST provide an SDK. MeterProvider Status: Stable A MeterProvider MUST provide a way to allow a Resource to be specified. If a Resource is specified, it SHOULD be a...| OpenTelemetry
Status: Stable, except where otherwise specified The Tracing API consists of these main components: TracerProvider is the entry point of the API. It provides access to Tracers. Tracer is responsible for creating Spans. Span is the API to trace an operation. Data types While languages and platforms have different ways of representing data, this section defines some generic requirements for this API. Time OpenTelemetry can operate on time values up to nanosecond (ns) precision. The representati...| OpenTelemetry
Status: Mixed Overview Status: Stable The OpenTelemetry data model for metrics consists of a protocol specification and semantic conventions for delivery of pre-aggregated metric timeseries data. The data model is designed for importing data from existing systems and exporting data into existing systems, as well as to support internal OpenTelemetry use-cases for generating Metrics from streams of Spans or Logs. Popular existing metrics data formats can be unambiguously translated into the Ope...| OpenTelemetry
Status: Stable, except where otherwise specified This is a data model and semantic conventions that allow to represent logs from various sources: application log files, machine generated events, system logs, etc. Existing log formats can be unambiguously mapped to this data model. Reverse mapping from this data model is also possible to the extent that the target log format has equivalent capabilities. The purpose of the data model is to have a common understanding of what a log record is, wh...| OpenTelemetry
