OpenTelemetry Specification v1.0.0, Tracing Edition

This week, we had the rewarding experience of merging this PRthis PR, which bumps the OpenTelemetry specificationOpenTelemetry specification to v1.0.

This is a big moment for OpenTelemetry. With v1.0.0 of the specification complete, and v1.0.1 already out, we are ready to begin offering stability guarantees for the tracing portion of the OpenTelemetry clients.

Please check out the API and SDK release candidates, available in the following languages.

• Erlang

• Java

• Javascript

• .NET

• Python

Other languages will follow suit in the coming weeks and months. Please join us in vetting these release candidates, feedback is greatly appreciated.

V1.0 and Tracing Stability

Long-term support, backwards compatibility, and dependency isolation are three core tenets of the project. OpenTelemetry is a cross-cutting concern – by design, the project will integrate with many, many codebases. Each component of OpenTelemetry is marked as either stable or experimental. The following components will become stable as part of the release of v1.0 implementations.

The tracing API. This means that all instrumentation written against the tracing API will be compatible with future minor versions, and supported for a minimum of three years after the next major version of the OpenTelemetry API. This is the most important stability guarantee, as it allows application developers to trust that they can access new OpenTelemetry features (such as metrics and logging) without needing to rewrite their existing instrumentation. At the same time, library authors can trust that they can instrument their libraries without worrying about OpenTelemetry creating dependency conflicts when their library is installed in an application.

The tracing SDK. This means that environment variables, configuration options, and plugins will be compatible with future minor versions, and supported for a minimum of one year after the next major release of the OpenTelemetry SDK. This allows operators and application developers to trust that they can receive security patches and performance upgrades to the SDK without needing to rewrite their integrations or deployment scripts. We will have a follow up blog post explaining our stability and support guarantees in detail. For now, the details can be found in the specificationthe specification.

The Road Ahead

To be clear, work is still continuing! Tracing is just the first portion of OpenTelemetry to stabilize: metrics, logs, and semantic conventions will continue to evolve. However, work on those components will not affect the stability of tracing, and will be released as minor version bumps when they reach stability.

For tracing, we will continue to improve our documentation, installation experience, and availability of instrumentation. In fact, writing instrumentation is a great way to get involved with the project.

For metrics, there is still a significant amount of work to do. Like many standardization efforts, OpenTelemetry tends to move slowly, as we value input and consensus from the wide range of organizations which both create and depend upon the project. The OpenTelemetry metrics community has grown to include many contributors, and we are seeking advice from related projects such as PrometheusPrometheus, OpenMetricsOpenMetrics, and MicrometerMicrometer. By integrating metrics with tracing, we believe OpenTelemetry has something valuable to add to this field, and we are excited to see that others agree.

OpenTelemetry has also been making progress on the logging front. With the contribution of StanzaStanza, the OpenTelemetry CollectorOpenTelemetry Collector is set to become a best-in-class log processor. We are also in the process of integrating OpenTelemetry Tracing with existing logging systems. This will allow existing logs to be converted into trace events, enriching the trace data collected by OpenTelemetry. It will also work in the opposite direction and allow trace identifiers to be added to existing logs, so that logging systems currently in production can benefit from better indexing.

Follow up blog posts will discuss the tracing, metrics, logging, and collector roadmaps in detail. Once metrics are stable, we plan to declare the OpenTelemetry project to be Generally Available. In the meantime, we are confident that OpenTelemetry tracing is ready for production.

Thank You, Everyone

It has been a pleasure watching OpenTelemetry thrive and grow into the broad, stable organization that it is today. As of January 2021, OpenTelemetry has 861 contributors to the project; I would like to thank each and every one of you. It has been an amazing journey, and I look forward to the next chapter.

P.S. As part of hitting the v1.0 milestone, we’re switching from Gitter to Slack for chat. If you’d like to say hi, you can find us in the OpenTelemetry channelOpenTelemetry channel on the CNCF Slack instance. If you’re new, you can create a CNCF Slack account herehere.

Interested in joining our team? See our open positions herehere.