Understanding Opentracing, Opencensus, and Openmetrics

When looking to improve performance monitoring and metric data collection of your cloud-based software system applications, the open source projects known as OpenTracing, OpenCensus, and OpenMetrics can assist you in making the process easier. Each used to unify instrumentation and observability through standardized APIs and formats, in the following article we will look at what these projects or tools are, how they differ, and how to use them.

Three Pillars of Observability in Software

A process of software maintenance that came along with the influx of cloud-based systems, observability is a move to solve the issue of it becoming harder and harder to monitor software as it is spread across multiple servers and microservices. Essentially a subset of monitoring that can be broken down into the action of observing and gathering three types of data in order to ensure the instrumentation, performance, and health of a system – observability includes:

1. Metrics – quantifiable pieces of data.
2. Traces – records of requests and interactions made of spans.
3. Logs/Events – specific occurrences within a span.

With these three pillars, DevOps and IT professionals can see how a system is behaving currently as well as work to foresee any potential issues in the future. To further assist with observability and instrumentation, the cloud community came up with open source projects in hopes to standardize the process of collecting these pillars. Each project dedicated to making observability easier, it is essential to note that each project has a different focus and group of supporters.

Brief Differences

The two best-known projects, OpenTracing and OpenCensus, have made names for themselves as they both aim to create a more effective environment for monitoring distributed tracing. They seek to answer the questions regarding where the distributed event happens, where it failed, how spikes behave in your system, what service is working, what services are no longer used, and so on. When each project is used correctly, you can observe, monitor, and de-bug your system with ease.

Utilizing many of the same tracing APIs, both vendor-neutral, and both allowing you to monitor several back-ends like Zipkin and Datadog, the differences between the two projects arise when we look at who created them and how they are run.

OpenCensus is a Google Open Source community project where OpenTracing, as well as OpenMetrics, are Cloud Native Computing Foundation projects. OpenCensus, as defined by Datadog, “is a collection of language-specific libraries for instrumenting an application, collecting stats (metrics), and exporting data to a supported backend.” OpenTracing is “a standardized API for tracing and provides a specification that developers can use to instrument their own services or libraries for distributed tracing. OpenTracing also provides a way for developers to collect metrics, though it’s not an out-of-the-box implementation.”

With that, it is clear to see the differences. The OpenTracing API makes it simple to change a preferred storage backend but relies on you to implement your own tracers that are compatible with the specifications of the project. While OpenCensus is built to include multiple backend exports automatically, it only supports the collection of various data types based on the backend and language.

Newer on the scene, OpenMetrics aims to standardize the format for metric data. It is ideally used in conjunction with OpenTracing and in the future is expected to replace Prometheus exposition format with CNCF.

To better understand each project, let’s look at each individually.