README.md

OpenTelemetry Specification

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
• SDK Specification
  • Tracing
  • Metrics
  • Resource
  • Configuration
• Data Specification
  • Semantic Conventions
  • Protocol
    • Metrics
    • Logs
  • Compatibility
    • OpenCensus
    • OpenTracing
    • Prometheus and OpenMetrics

Notation Conventions and Compliance

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "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", "SHALL", or "SHALL NOT" requirements defined in the specification. Conversely, an implementation of the specification is compliant if it satisfies all the "MUST", "MUST NOT", "REQUIRED", "SHALL", and "SHALL NOT" 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". Refrain from using "OT" in order to avoid confusion with the now deprecated "OpenTracing" project.
• 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