The State of OpenTelemetry

The question we’re discussing daily with potential users of TelemetryHub is, ‘can I instrument my system with OpenTelemetry?’ And the answer is almost always ‘yes.’ 

Well, mostly. Any system with internet access can report data via the OpenTelemetry standard. And anyone can use an OpenTelemetry Collector to filter, compress, and limit data being sent over the internet to an OpenTelemetry Endpoint.

All is well and good, but what most people want to know is ‘how well will open telemetry instrument my language and framework?’

C++

C++ has most of the pieces that need to be instrumented with OpenTelemetry

The current status of the major functional components for OpenTelemetry C++ is as follows:

The latest release has support to build most projects with the C++ Otel SDK. Note the builds with Bazel are experimental at this stage. See the installation documentation for more detail.

Java

The OpenTelemetry Java project is the most mature of the Otel-supported languages. While Logs are still listed as “experimental,” it’s worth digging into what “experimental” means. From the docs:

Signals start as experimental, which covers alpha, beta, and release candidate versions of the signal. While signals are experimental, breaking changes and performance issues may occur. Components should not be expected to be feature-complete. In some cases, the experiment may be discarded and removed entirely. Long-term dependencies should not be taken against experimental signals.

Later in this article, I discuss the status of logging within OpenTelemetry, and the short version is that it’s likely you’re already using a logging tool that can be exported to the Open Telemetry format.

.Net

Like C++, .Net support is 

The current status of the major functional components for OpenTelemetry .NET is as follows:

For logging, while the OpenTelemetryLoggerProvider (i.e., integration with ILogger) is stable, the OTLP Log Exporter is still non-stable.

To be frank, this is probably still usable for most applications since it’s possible to use a tool like ILogger for sending logs. Further, it’s unlikely that logs are the ‘missing piece’ of your observability solution.

Erlang/Elixir

The status of Erlang support makes it worth developing with:

See the definition of ‘Experimental’ above in the Java section; both logs and metrics are currently functioning in the project.

Packages of the API, SDK, and OTLP exporter have been published to hex.pm as opentelemetry_api, opentelemetry, and opentelemetry_exporter.

Go

Go isn’t currently well-supported enough to recommend using OpenTelemetry to monitor your stack. The current status of the major functional components for OpenTelemetry Go is as follows:

Traces are a major component, making it worth a try if you’re currently not observing any part of your go stack. For releases of the Go Otel project, including the latest release, see Releases.

Javascript

OpenTelemetry JavaScript is currently rather advanced

As of the latest release, logs were not in a state where they should be used in production. There are several other logging solutions available, and this is an area of active development

It’s worth noting that, in order to perform tracing, OpenTelemetry stores span in the Context. This is necessary to allow tracing of multiple components handling the same basic request. Learn more in the Context API documentation.

Python

Python, that classic of functional programming, is another language with OpenTelemetry support. Only logs are listed as Experimental, which is true across all OpenTelmetry languages. This is listed on the OpenTelemetry documentation page

• 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 are complete, the focus will shift to developing an OpenTelemetry logging API.

One question that may come up is, ‘why is logging still in the experimental phase, how hard can it be?’ The counter-intuitive reason is that logging, and the transmission of logging, is largely a solved problem in the tech industry.

Every framework has some way to emit logs, and nearly every organization has tools to transmit and store logs. Data ingest of existing logs tools is a more reasonable focus for the OpenTelemetry project.

Ruby

OpenTelemetry Ruby is ‘not ready for prime time’ as of yet. The current status of the major functional components for OpenTelemetry Ruby is as follows:

For releases, including the latest release, see Releases.

Without Metrics, there’s not a strong case for Otel on Ruby yet. Thankfully there are great APM tools to monitor Ruby applications.

OpenTelemetry GA

From https://opentelemetry.io/docs/reference/specification/versioning-and-stability/

Still, the question remains ‘when will OpenTelemetry reach GA?’ The term “OpenTelemetry GA” refers to the point at which OpenTracing and OpenCensus will be fully deprecated. The minimum requirements for declaring GA are as follows

• A stable version of both tracing and metrics MUST be released in at least four languages.
• CI/CD, performance, and integration tests MUST be implemented for these languages.

And we’re close! GA is expected within the next year. The team here is so confident that we’ve released TelemetryHub, a clean, efficient, and reliable endpoint for your OpenTelemetry data.

TelemetryHub enables users to ingest telemetry data from platforms instrumented with the OpenTelemetry CNCF project. As an early adopter of OpenTelemetry, TelemetryHub benefits from a project with the community support of over 100,000 contributors and is committed to evangelizing and supporting the project through education and contribution. This allows the TelemetryHub team to stay committed to providing the best solution for users and allows our customers the opportunity to implement an ever-maturing, vendor-agnostic solution that lets them have total control and flexibility with their observability data.