OpenTelemetry’s Past, Present and Future Explained
Epsagon sponsored this post.
There were two major players in the world of distributed tracing libraries for the past two years only until a few months ago: OpenTracing and OpenCensus. And choosing between the two is often not easy. After all, both aim to solve the same fundamental problem of having a vendor-neutral API for distributed tracing (though in slightly different ways), resulting in two competing standards.
Earlier this year, both project teams decided to join forces and merge as OpenTelemetry: a brand new project under the Cloud Native Computing Foundation (CNCF) umbrella.
While OpenTelemetry is still under development, in this post, you’ll learn about the past, present and future of OpenTelemetry through the two projects from which it originated, including some code examples comparing all three.
The Past
OpenTracing
OpenTracing is the oldest of the two projects, after 1.0 was released in December of 2016. Like OpenTelemetry, it is also a CNCF project. As the name suggests, the main focus is on distributed tracing, which is all it’s meant to do. Libraries are available in nine languages, but where OpenTracing truly shines is in its simplicity.
The libraries themselves have a small API surface and define an interface that tracers must implement. Tracers such as Jaeger must implement their client libraries if they wish to support OpenTracing. Many tracers are officially supported by vendors, with an additional few that are community supported. Only three methods are needed to satisfy OpenTracing’s Tracer interface, making it incredibly easy to add new ones.
OpenCensus
OpenCensus originally started at Google and was first released in January of 2018. It was born out of Google’s internal Census libraries and as such, OpenCensus also supports both the capturing of tracing information and metrics. Nowadays, it has a vibrant ecosystem of partners, which include other cloud providers such as Microsoft and many vendors in the distributed tracing and metrics space. Like OpenTracing, OpenCensus also supports nine languages and the two share eight languages in common.
OpenCensus aims to be vendor-neutral, so vendors can implement exporters for their tracing and metrics backends. However, OpenCensus has always shipped some exporters with some of its libraries as well. In some languages, these have moved into their own separate repositories so they can be maintained separately from the core project. Still, in others, they remain a part of the libraries. In practice, for application developers wishing to use OpenCensus, there is little difference: Software must usually import and initialize whichever exporter it wishes to use. For software under your control (i.e., developed in-house), this is unlikely to be a problem because you’ll choose the one being used at your organization.
However, in a cloud native world, you may be running one or more open source microservices that you wish to propagate tracing information to and from. These might, for example, export g to Jaeger, while you use Zipkin. OpenTracing has the same problem, in which concrete tracers must be imported and initialized. But, unlike OpenTracing, OpenCensus came up with a solution.
OpenCensus Service
The OpenCensus Service is a collection of separate processes that receive data, either in its own OpenCensus format or in Zipkin, Jaeger or Prometheus format. As for output, the service supports numerous formats/vendors, including those already supported by OpenCensus. It is possible to deploy the OpenCensus Service as a collector that runs nearby your application and sends data to one or more monitoring backends.
Another option is to run it as an agent on the same host (or sidecar container), which exports to an OpenCensus collector or even directly to a monitoring service. There are several advantages to this approach:
- The configuration of exporters is not in the applications themselves. You could, for example, change the exporter backend or add an extra one simply by changing the configuration of the OpenCensus Service processes without having to redeploy your code.
- You can convert between formats, for example, from Zipkin to Jaeger, or Prometheus to Stackdriver, all without having to change any code. This is particularly useful for operators dealing with externally built software.
- There is no need to include exporters in your code and keep them up-to-date.
- OpenCensus maintainers and contributors don’t need to implement exporters in all library languages but only in Go (the language chosen to implement the OpenCensus Service).
Both projects satisfy tracing needs perfectly well, but OpenCensus has a slightly more ambitious goal and a “batteries-included” approach.
OpenTelemetry: Best of Both Worlds
OpenTelemetry truly takes the best ideas from both projects. At launch, it will support distributed tracing and metrics, just like OpenCensus does. Support for logging will follow after the initial release.
The OpenCensus Service — with arguably the best features — has been merged into this new project as the OpenTelemetry Collector. While it still supports running as both an agent and collector, it is now the exact same binary (and Docker image) for both use cases.
But what if you’re already using OpenTracing or OpenCensus? There’s nothing to fear — when OpenTelemetry is released, it will be backward compatible with both projects, so you’ll have plenty of time to adopt the new APIs as the project evolves and matures.
For the whole CNCF ecosystem, OpenTelemetry is also good news because it now supports metrics. This means that Prometheus — another CNCF project — will have support from the get-go as an exporter for metrics. And when it comes to Jaeger, not only is support available, but Jaeger currently develops, maintains and distributes its own agent and collector implementations. Jaeger is also planning to collaborate with OpenTelemetry to see if it would be possible to phase out the Jaeger’s agent and collector over time, as detailed in the post about Jaeger and OpenTelemetry.
Current Status and Roadmap
All OpenTelemetry sub-projects (specification, libraries and collector) are still under development in the alpha stage. Many of the libraries still have no versioned releases for the time being.
High-quality preview releases of language SDKs in 2019 can be expected, including support for the OpenTelemetry Collector. In the second quarter of 2020, the plan is to then sunset both OpenTracing and OpenCensus projects.
It’s important to note that none of the OpenTelemetry projects are ready for production use. The OpenTelemetry protocol is still changing and so are the APIs of SDKs. The OpenTelemetry Collector documentation currently states that the OpenCensus Service should instead be used until a stable release is available.
Code Comparison
In order to better understand the actual differences between each project upon implementation, let’s dive into a real-world example. Let’s create a span with an annotation, using the JavaScript SDKs of OpenTracing, OpenCensus andOpenTelemetry. All examples use Jaeger as a backend.
OpenTracing
|
1 2 3 4 5 6 7 8 |
const jaeger = require('jaeger-client'); const tracer = jaeger.initTracer({ /* Jaeger options */ }); const span = tracer.startSpan('my_span'); span.setTag({ 'key': 'value' }); // Code to instrument goes here... span.finish(); |
The first thing to notice with OpenTracing is that you may not even need to import any OpenTracing-specific library because the client libraries directly implement the public OpenTracing API. However, the OpenTracing library provides additions, such as a mock tracer and constants for well-known tag keys.
OpenCensus
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
const tracing = require('@opencensus/nodejs'); const { JaegerTraceExporter } = require('@opencensus/exporter-jaeger'); const tracer = tracing.start({ samplingRate: 1 }).tracer; tracer.registerSpanEventListener(new JaegerTraceExporter({ /* Jaeger options */ })); tracer.startRootSpan({ name: 'my_span' }, rootSpan => { rootSpan.addAttribute('key', 'value') // Code to instrument goes here... rootSpan.end(); }); |
The main difference here with OpenCensus is that its library is the main focus point and Jaeger is just an exporter that needs to be registered. API differences aside, both OpenCensus and OpenTracing are similar in terms of setup, span creation and span attributes/tags.
OpenTelemetry
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
const opentelemetry = require('@opentelemetry/core'); const { BasicTracer, SimpleSpanProcessor } = require('@opentelemetry/tracing'); const { JaegerExporter } = require('@opentelemetry/exporter-jaeger'); const tracer = new BasicTracer(); tracer.addSpanProcessor(new SimpleSpanProcessor(new JaegerExporter({ /* Jaeger options */ }))); opentelemetry.initGlobalTracer(tracer); const span = opentelemetry.getTracer().startSpan('my_span'); span.setAttribute('key', 'value'); // Code to instrument goes here... span.end(); |
OpenTelemetry is perhaps a bit more verbose in terms of setup, but that’s due to its modular design. Similarly to OpenCensus, its library is at the core. However, in addition to having a choice of exporters, there are also different span processors, such as batch span processors and a console processor that prints spans to the console for diagnostic purposes. This more modular design opens up possibilities for further customization.
Please note that this example uses an alpha version of OpenTelemetry, which is subject to change.
Summary
Both OpenTracing and OpenCensus have large, healthy communities backing them — it is thus impressive to see them joining forces. With this merger, everybody wins:
- Developers no longer need to choose between two competing standards and can focus on writing code with truly portable telemetry.
- Operators have a standardized way to configure, collect, interpret and export tracing data, thanks to the OpenTelemetry Collector.
- Vendors of application performance monitoring solutions only need to support and test against a single standard and don’t need to implement agents or collectors themselves.
If you’re starting a new project today, you should probably stick with OpenTracing or OpenCensus, especially if stability is essential. And thanks to the compatibility shims, when the stable releases of OpenTelemetry finally hit, you won’t need to worry about upgrading to the new API right away and will be able to take advantage of the new features and improvements in OpenTelemetry.
Epsagon, an AWS Advanced Technology Partner, delivers automated monitoring and tracing for cloud microservices — containers and serverless. Get started today with a free trial to see how Epsagon can help you save as much as 95% in troubleshooting time and reduce errors by 75%.
Feature image via Pixabay.
