OpenTelemetry Specification 1.36.0

Contents

• Overview
• Glossary
• Versioning and stability for OpenTelemetry clients
• Library Guidelines
  • Package/Library Layout
  • General error handling guidelines
• API Specification
  • Context
    • Propagators
  • Baggage
  • Tracing
  • Metrics
  • Logs
    • Bridge API
    • Event API
• SDK Specification
  • Tracing
  • Metrics
  • Logs
  • Resource
  • Configuration
• Data Specification
  • Semantic Conventions
  • Protocol
    • Metrics
    • Logs
  • Compatibility
    • OpenCensus
    • OpenTracing
    • Prometheus and OpenMetrics
    • Trace Context in non-OTLP Log Formats

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