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.

A detailed overview of signals and components can be found here.

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.

The complete definitions for lifecycles and long term support can be found here.

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.


API: stable
SDK: stable
Protocol: stable
Collector: experimental

  • 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: feature-freeze
SDK: experimental
Protocol: stable
Collector: experimental

  • 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 developemnet, in collaboration with the Prometheus community.
  • The metric API and SDK specification is currently being prototyped in Java, .NET, and Python.


API: stable
SDK: stable
Protocol: N/A
Collector: N/A

  • OpenTelemetry Baggage is now completely stable.
  • Baggage is not an observability tool, it is a system for attaching arbitratry 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: experimental
Collector: experimental

  • 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 injest 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 CICD tools for writing and verifying instrumentation quality.

Latest Releases


1.0.0-rc8 release of non-core components

Refer to individual changelog files to detailed release notes.


Release v1.0.1/Metrics v0.24.0

## 1.0.1 - 2021-10-01

### Fixed

- json stdout exporter no longer crashes due to concurrency bug. (#2265)

## Metrics 0.24.0 - 2021-10-01

### Changed

- NoopMeterProvider is now private and NewNoopMeterProvider must be used to obtain a noopMeterProvider. (#2237)
- The Metric SDK `Export()` function takes a new two-level reader interface for iterating over results one instrumentation library at a time. (#2197)
  - The former `"".CheckpointSet` is renamed `Reader`.
  - The new interface is named `"".InstrumentationLibraryReader`.


SDK v1.0.0

First stable release of the OpenTelemetry SDK for JavaScript includes the following packages:

- @opentelemetry/context-async-hooks
- @opentelemetry/context-zone-peer-dep
- @opentelemetry/context-zone
- @opentelemetry/core
- @opentelemetry/exporter-jaeger
- @opentelemetry/exporter-zipkin
- @opentelemetry/propagator-b3
- @opentelemetry/propagator-jaeger
- @opentelemetry/resources
- @opentelemetry/sdk-trace-base
- @opentelemetry/sdk-trace-node
- @opentelemetry/sdk-trace-web
- @opentelemetry/semantic-conventions
- @opentelemetry/shim-opentracing

A huge thank you to all who contributed toward this effort:

- @aabmass
- @adamegyed
- @alisabzevari
- @amanbrar1999
- @AndrewGrachov
- @antoniomrfranco
- @anuraaga
- @aphelionz
- @aravinsiva
- @Asafb26
- @astorm
- @austinlparker
- @banothurameshnaik
- @BlumAmir
- @bradfrosty
- @brunoluiz
- @carolinee21
- @chalin
- @confiq
- @connorlindsey
- @CptSchnitz
- @danielmbarlow
- @DarkPurple141
- @davidwitten
- @debagger
- @dengliming
- @dobesv
- @drexler
- @dyladan
- @echoontheway
- @EdZou
- @flands
- @Flarna
- @hermanbanken
- @Hongbo
- @ivansenic
- @JamesJHPark
- @JapuDCret
- @jessitron
- @johanneswuerbach
- @johnbley
- @jonahrosenblum
- @jonchurch
- @jordanworner
- @jtmalinowski
- @jufab
- @justinwalz
- @kanikashah90
- @KKelvinLo
- @kkruk
- @kudlatyamroth
- @legendecas
- @leonardodalcin
- @lizthegrey
- @lonewolf3739
- @longility
- @luebken
- @lykkin
- @marcbachmann
- @MarkSeufert
- @markwolff
- @mayurkale22
- @mhennoch
- @michaelgoin
- @mihirsoni
- @morigs
- @mottibec
- @MSNev
- @mustafain117
- @mwear
- @mzahor
- @naseemkullah
- @NathanielRN
- @neilfordyce
- @nflaig
- @niekert
- @nijotz
- @niko
- @nirsky
- @nozik
- @nvenegas
- @obecny
- @OlivierAlbertini
- @OmkarKirpan
- @pauldraper
- @paulfairless
- @PaurushGarg
- @philipszalla
- @pokutuna
- @pragmaticivan
- @pramodsreek
- @quickgiant
- @Rauno56
- @reggiemcdonald
- @renovate
- @rezakrimi
- @rubenvp8510
- @ryhinchey
- @sbrichardson
- @seemk
- @sergeylanzman
- @sergioregueira
- @sfishel
- @shivkanya9146
- @shovnik
- @sid
- @skjindal93
- @sleighzy
- @snyder114
- @srjames90
- @svrnm
- @t2t2
- @tannaga
- @thgao
- @thisthat
- @TigerHe7
- @TsvetanMilanov
- @vknelluri
- @vmarchaud
- @vreynolds
- @weyert
- @YanivD
- @zoomchan


Version 1.7.0

## Version 1.7.0 (2021-10-08):

### General

- IMPORTANT: The `io.opentelemetry:opentelemetry-proto` module should now be considered *deprecated*. It will be removed from publications in a future release. If you need Java bindings for the OTLP protobufs, they are now being published via the new [opentelemetry-proto-java]( repository. They are at new maven coordinates: `io.opentelemetry.proto:opentelemetry-proto` and  versioning is aligned with the released version of the protobuf definitions themselves.

### SDK

#### Exporters

- BREAKING CHANGE: The Jaeger gRPC exporter does not directly use the `protobuf-java` library for
  marshaling trace data. Along with this, the `opentelemetry-exporter-jaeger` artifact does not
  contain generated protobuf classes for the Jaeger API. If you were using these in your
  application, you must update your build configuration to also include the new `jaeger-proto`
  artifact. This artifact will not be included in a future 2.0 release of the SDK so it is
  recommended to instead generated the protobuf classes in your own build.
- BREAKING CHANGE: The `opentelemetry-exporter-otlp-http-*` exporter default endpoint ports have
  changed from `4317` to `4318`, in line with [recent changes]( to the spec.
- The OTLP gRPC exporters will now function without the `grpc-java` dependency, if `okhttp` is
  present on the classpath.
- The (alpha) metrics that are generated by the gRPC exporters have changed slightly. They now have
  a slightly different instrumentation library name, `"io.opentelemetry.exporters.otlp-grpc"` and
  the names of the metrics have also changed. Now emitted are metrics with
  names `otlp.exporter.seen` and `otlp.exported.exported`. Note that it is likely this will change
  in the future as the metrics semantic conventions are more defined.

### Auto-configuration (alpha)

- BREAKING CHANGE: The behavior of `otel.exporter.otlp.endpoint` has changed when the protocol
  is `http/protobuf`. The new behavior is in line with [recent changes]( to the specification, which states that the signal path  (e.g. `v1/traces` or `v1/metrics`) is appended to the configured endpoint. Values for signal specific endpoint configuration (e.g. `otel.exporter.otlp.traces.endpoint` and `otel.exporter.otlp.metrics.endpoint`) override the generic endpoint configuration and are used as-is without modification.
- The `compression` option for exporters now explicitly supports the `none` value, in addition to the existing `gzip` value.

### Metrics (alpha)

- BREAKING CHANGE: The `IntervalMetricReader` has been removed, and replaced with
  a `PeriodicMetricReader` that provides an implementation of the new `MetricReader` interface.
- This release includes initial support for multiple exporters to be configured for a single SDK
  instance. See the `SdkMeterProviderBuilder.registerMetricReader` method for more details.
- This release includes initial support for the SDK recording of Metric Exemplars for sampled Spans.
  See `SdkMeterProviderBuilder.setExemplarFilter` and the `ExemplarFilter` interface for
  more details.

### Logging (alpha)

- This release includes SDK extension interfaces for `LogProcessor`s and `LogExporter`s, and has
  implementations for batch log processing and export via OTLP. These classes are intended for usage
  in implementations of log appenders that emit OTLP log entries.


opentelemetry v1.6.2 & v0.25b2

- Fix parental trace relationship for opentracing `follows_from` reference


0.0.3 Release

45b7750 (HEAD -> main, upstream/main) Remove STDOUT output in Newrelic exporter (#404)
04f84d7 Add ReadableSpan/ReadWriteSpan interfaces (#403)
e5e8b74 Revert "change OTLP/HTTP port (#389) (#398)" (#401)
98fcced remove Fahmy as an approver (#399)
587b086 Make span.recordException accept Throwable (#390)
8e64874 change OTLP/HTTP port (#389) (#398)
f9948ef update dependencies (#397)
87cab2d Add InstrumentationLibrary in OTLP exporter (#395)
4a08e01 Update Tracer.php (#396)
44b09b3 Reintroduce InstrumentationLibrary (#392)
74b77ec chore: Force otel-collector to use linux/amd64 image in local dev (#394)
15d67d7 Add alternative stacktrace function (#391)
a325989 Feature - Implemented exporter factory and added unit tests (#351)
942b7f7 Update php.yml (#387)
546f4c3 Fix merging of attributes provided within SamplingResult in Tracer (#384)
1a1e0bd Update php-cs-fixer (#385)
c07dee2 OTLP/HTTP First Pass (#352)
236e228 Fixed idgenerator issues in SpanOptions and Tracer (#381)
48b98fb SpanContext Issue Temporary Fix (#380)
0003c75 New resource constants (#375)
c3c14b9 Span context trace context update (#374)
75c37cd Change random Hex generator to public function (#373)
f3db21c ensure insecure variable is converted to bool (#369)
7a484c9 fix dockerfile spacing (#372)
578d05c fix metadataFromHeaders parsing bug (#367)
d908922 Remove Tracer::endActiveSpan() (#365)
7c5d861 Remove not required, not implemented tracer methods (#364)
8f2c077 Update laravel guide for v.0.0.2 (#361)
fb83f2e Fix jaeger zipkin-port environment variable (#359)
e2d8725 Propagate ::startSpan() attributes to created span (#353)
b42895a Add attributes parameter to ::recordException() (#355)
c2a52e6 Fix span processors being called twice on ::endActiveSpan() (#354)
142e665 (prondubuisi/main, alex/main) Remove morrisonlevi as code owner (#349)
e20956f CorrelationContext to Baggage (#346)


opentelemetry-instrumentation-all 0.21.3

### v0.21.3 / 2021-10-07

* (No significant changes)


OpenTelemetry API v0.3.2

* `create_span` has been renamed `start_inactive_span` (#53)
* Fix `add_event` Elixir function (#56)
* Add accessors to deconstruct Span (#54)
* Attributes and events that aren't a list are now silently dropped (#51)
* Fix bug where there is no current span ctx and update_name is called (#52)
* Readme, typespec and doc fixes #45 #46 #50 #59 



## v0.37.0 Beta

## 🛑 Breaking changes 🛑

- Move `configcheck.ValidateConfigFromFactories` as internal function in service package (#3876)
- Rename `configparser.Parser` as `config.Map` (#4075)
- Rename `component.DefaultBuildInfo()` to `component.NewDefaultBuildInfo()` (#4129)
- Rename `consumererror.Permanent` to `consumererror.NewPermanent` (#4118)
- Rename `config.NewID` to `config.NewComponentID` and `config.NewIDFromString` to `config.NewComponentIDFromString` (#4137)
- Rename `config.NewIDWithName` to `config.NewComponentIDWithName` (#4151)
- Move `extension/storage` to `extension/experimental/storage` (#4082)
- Rename `obsreporttest.SetupRecordedMetricsTest()` to `obsreporttest.SetupTelemetry()` and `obsreporttest.TestTelemetrySettings` to `obsreporttest.TestTelemetry` (#4157)

## 💡 Enhancements 💡

- Add Gen dependabot into CI (#4083)
- Update OTLP to v0.10.0 (#4045).
- Add Flags field to NumberDataPoint, HistogramDataPoint, SummaryDataPoint (#4081).
- Add feature gate library (#4108)
- Add version to the internal telemetry metrics (#4140)

## 🧰 Bug fixes 🧰

- Fix panic when not using `service.NewCommand` (#4139)