The OpenTelemetry specification has been promoted to v1.0.0. This milestone includes improved stability and backwards compatibility guarantees as well as API and SDK release candidates available for a number of languages. With this release both the tracing API and the tracing SDK are considered stable.
OpenTelemetry provides a set of APIs, libraries, agents, and collector services for capturing distributed traces and metrics. At the highest level, clients are organized into signals, with each signal representing a form of observability. Tracing, metrics, and baggage are three separate signals.
A trace represents a set of events, generated from a single operation (such as clicking a button on a website), aggregated across the various components within the application. Within OpenTelemetry, a baggage represents a name/value pair. It is intended for indexing events in one service with details provided by a prior service in the same transaction. For example, a provider could include context about the API user that is responsible for the request.
This release introduces a new level of stability for the tracing portion of OpenTelemetry clients, such as OpenTelemetry .NET. The 1.0 version was recently published which implements the 1.0 version of the OpenTelemetry specification. This release includes .NET APIs for tracing, baggage, context, and propagators, an SDK with controls for sampling, processing, and export. There are also exporters to Jaeger, Zipkin, and the OpenTelemetry Protocol (OTLP). A getting started guide and samples are also included.
Future releases for OpenTelemetry .NET are expected to include stable versions of instrumentation libraries for ASP.NET, ASP.NET core, HTTP client, SQL client, and gRPC client. There are also plans to incorporate the metrics API into the .NET runtime itself. This will be similar to how the tracing API was built, allowing the .NET Activity API to be used as the OpenTelemetry tracing API.
At the time of release there are also API and SDK release candidates for Erlang, Java, and Python. Other languages will be added in the new few months.
With this added stability for the tracing portion of OpenTelemetry, both the tracing API and SDK are moving from experimental to stable with this release. There is now a commitment for compatibility with future minor versions as well as a guaranteed length of support after the next major release. APIs are supported for a minimum of three years and plugin interfaces and constructors have a minimum of one year of support.
According to Ted Young, director of developer education at Lightstep, "tracing is just the first portion of OpenTelemetry to stabilize: metrics, logs, and semantic conventions will continue to evolve." However, work on these components will not affect the stability introduced in tracing. The plan is that these releases will be done as minor version bumps.
To inform the direction on metrics, they are seeking advice from related projects such as Prometheus, OpenMetrics, and Micrometer. With the contribution of Stanza to the OpenTelemetry Collector, Young feels that OpenTelemetry Collector is "set to become a best-in-class log processor". Stanza is a log transport and processing agent similar to FluentD and Logstash. It can run as a standalone agent on all major operating systems or be embedded directly into any Golang applications. With this merger, the Stanza repo will be deprecated and development will continue in the OpenTelemetry Log Collection repository.
Once the work on metrics is moved to stable, the plan is to declare the OpenTelemetry project as generally available. As part of this release, the project chat is moving to Slack at the new OpenTelemetry channel within the CNCF Slack instance. More details and downloads can be found on the OpenTelemetry GitHub page.
