OpenTelemetry Tracing Specification now 1.0!

Our goal is to provide a generally available, production quality release for the tracing data source across most OpenTelemetry components in the first half of 2021. Several components have already reached this milestone! We expect metrics to reach the same status in the second half of 2021 and are targeting logs in 2022.

Project Overview

OpenTelemetry is developed on a signal by signal basis. Tracing, metrics, baggage, and logging are examples of signals. Signals are built on top of context propagation, a shared mechanism for correlating data across distributed systems.

Each signal consists of four core components: APIs, SDKs, the OTLP protocol, and the Collector. Signals also have contrib components, an ecosystem of plugins and instrumentation. All instrumentation shares the same semantic conventions, to ensure that they produce the same data when observing common operations, such as HTTP requests.

To learn more about signals and components, see the specification Overview.

Component Lifecycle

Components follow a development lifecycle: Draft, Experimental, Stable, Deprecated, Removed.

  • Draft components are under design, and have not been added to the specification.
  • Experimental components are released and available for beta testing.
  • Stable components are backwards compatible and covered under long term support.
  • Deprecated components are stable, but may eventually be removed.

For complete definitions of lifecycles and long term support, see Versioning and stability.

Current Status

The following is a high level status report for currently available signals. Note that while the OpenTelemetry clients conform to a shared specification, they are developed independently.

Checking the current status for each client in the README of its github repo is recommended. Client support for specific features can be found in the specification compliance tables.

Note that, for each of the following sections, the Collector status is the same as the Protocol status.


  • API: stable, feature-freeze
  • SDK: stable
  • Protocol: stable
  • Notes:
    • The tracing specification is now completely stable, and covered by long term support.
    • The tracing specification is still extensible, but only in a backwards compatible manner.
    • OpenTelemetry clients are versioned to v1.0 once their tracing implementation is complete.


  • API: stable
  • SDK: feature-freeze
  • Protocol: stable
  • Notes:
    • OpenTelemetry Metrics is currently under active development.
    • The data model is stable and released as part of the OTLP protocol.
    • Experimental support for metric pipelines are available in the Collector.
    • Collector support for Prometheus is under development, in collaboration with the Prometheus community.
    • The metric API and SDK specification is currently being prototyped in Java, .NET, and Python.


  • API: stable, feature-freeze
  • SDK: stable
  • Protocol: N/A
  • Notes:
    • OpenTelemetry Baggage is now completely stable.
    • Baggage is not an observability tool, it is a system for attaching arbitrary keys and values to a transaction, so that downstream services may access them. As such, there is no OTLP or Collector component to baggage.


  • API: draft
  • SDK: draft
  • Protocol: beta
  • Notes:
    • OpenTelemetry Logging is currently under active development.
    • The data model is experimental and released as part of the OTLP protocol.
    • Log processing for many data formats has been added to the Collector, thanks to the donation of Stanza to the the OpenTelemetry project.
    • Log appenders are currently under develop in many languages. Log appenders allow OpenTelemetry tracing data, such as trace and span IDs, to be appended to existing logging systems.
    • An OpenTelemetry logging SDK is currently under development. This allows OpenTelemetry clients to ingest logging data from existing logging systems, outputting logs as part of OTLP along with tracing and metrics.
    • An OpenTelemetry logging API is not currently under development. We are focusing first on integration with existing logging systems. When metrics is complete, focus will shift to development of an OpenTelemetry logging API.


An effort to expand the availability and quality of OpenTelemetry instrumentation is scheduled for this summer.

  • Stabilize and define long term support for instrumentation
  • Provide instrumentation for a wider variety of important libraries
  • Provide testing and CI/CD tools for writing and verifying instrumentation quality.