OpenTelemetry Specification

Overview
Glossary
Principles and Guidelines
API Specification
- Context
  - Propagators
  - Environment Variable Carriers
- Baggage
- Tracing
- Metrics
- Logs
  - API
SDK Specification
- Tracing
- Metrics
- Logs
- Resource
- Configuration
Data Specification
- Semantic Conventions
- Protocol
  - Metrics
  - Logs
  - Profiles
- Compatibility

Notation Conventions and Compliance

The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in the specification are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

An implementation of the specification is not compliant if it fails to satisfy one or more of the "MUST", "MUST NOT", "REQUIRED", requirements defined in the specification. Conversely, an implementation of the specification is compliant if it satisfies all the "MUST", "MUST NOT", "REQUIRED", requirements defined in the specification.

Project Naming

The official project name is "OpenTelemetry" (with no space between "Open" and "Telemetry").
The official acronym used by the OpenTelemetry project is "OTel". "OT" MAY be used only as a part of a longer acronym, such as OTCA (OpenTelemetry Certified Associate).
The official names for sub-projects, like language specific implementations, follow the pattern of "OpenTelemetry {the name of the programming language, runtime or component}", for example, "OpenTelemetry Python", "OpenTelemetry .NET" or "OpenTelemetry Collector".

About the project

See the project repository for information about the following, and more:

Change / contribution process
Project timeline
Versioning the specification
License

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!