OpenTelemetry: What Can It Do?

What is OpenTelemetry?

OpenTelemetry is commonly used across the software industry. But ask any engineer about OpenTelemetry, and the extent of their knowledge roughly equates to “uh, I use it so I don’t have to be vendor locked.”

In our latest ELI5 blog post, we uplevel your knowledge of OpenTelemetry’s utility as a universal collector for observability data.

OpenTelemetry is a standard approach to collecting observability data. As part of the Cloud Native Computing Foundation (CNCF), OpenTelemetry provides APIs and SDKs in more than a dozen languages to help you instrument, generate, collect, and export telemetry data (opentelemetry metrics, traces, and logs).

But what exactly does all this mean and why is it important? Taking a page out of the “explain it like I’m 5” playbook, let me break it down into simpler terms.

Check out our in-depth article:

To illustrate OpenTelemetry’s importance (and to stretch the ELI5 analogy even further) let’s talk about a game popular with children of all ages: Minecraft. In order to properly play Minecraft, you need some hardware building blocks: a laptop, monitor, mouse, keyboard, and headset. And for all of this peripheral hardware to work as it should, each device needs to communicate their respective input and outputs. Unfortunately, each device has a different connector design: the monitor takes an HDMI; the headset uses an audio jack; and the mouse and keyboard are USB-B.

All these differentiated inputs means lugging around cords, adapters, and dongles just to play the damn game. What a pain. Not only that, some vendors (like Apple) made proprietary interfaces (like Lightning) such that you can’t switch platforms without changing hardware all over again. The result is similar to fitting round pegs into Minecraft’s block-shaped holes.

Today, there’s a much better solution: USB-C. As a universal connector with a standardized input, you can connect hardware peripherals — monitor, headset, mouse, and keyboard — such that they can all talk to each other while playing Minecraft. And if one day you decide to use a different computer, such as a PC, they are also USB-C compatible.

What USB-C is to laptops, OpenTelemetry is to your telemetry data. And just as USB-C is vendor-agnostic (remember, the U in USB stands for universal), OpenTelemetry is a universal telemetry data format compatible with any vendor. In this way, the hardware peripherals I just mentioned – mouse, keyboard, and monitor – can be seen as metaphors for different tech stacks like Google Cloud Compute Engine (GCE), Kubernetes, or any number of microservices.

What’s more, if I instrument all my technical services with an OpenTelemetry agent, I can have my telemetry data from GCE sent to any location or vendor that supports it. This is similar to how any USB-C-compatible device can be used on any computer that has USB-C port, not just one specific computer.

Without a universal collector format like OpenTelemetry, I’d have to heavily rely on vendor tools to standardize those differentiated telemetry data types. Remember the nightmare it was linking mouses, keyboards, and monitors — and how USB-C fixed all that? In that same way, cloud native observability solutions like Chronosphere are built to be compatible with open source standards like OpenTelemetry and Prometheus.

Engineering teams need telemetry data to know, triage, and understand the issues that occur across our systems and services. And as organizations adopt cloud native infrastructures, it’s not uncommon for systems and services to be used only for fractions of seconds at a time. Which means you need to set yourself up to not only get the right data, but to get it at the right intervals and right time. Just like USB-C made it easier to adapt to different hardware types, OpenTelemetry has made it easier to instrument telemetry data sources and use services  — services like Chronosphere.

Chronosphere is a SaaS cloud monitoring tool that helps teams rapidly navigate the three phases of observability. We’re focused on giving devops teams, SREs, and central observability teams all the tools they need to know about problems sooner, the context to triage them faster, and insights to get to the root cause more efficiently. One of the major things that make us different is that we were built from the ground-up to support the scale and speed of cloud native systems. We also embrace open source standards, so developers can use the language and formats they’re already familiar with, and it prevents lock-in.

What is the difference between open tracing and opentelemetry? OpenTelemetry and OpenTracing are both open-source projects that provide standard APIs for instrumenting applications and collecting telemetry data. The main difference between the two is their focus. OpenTelemetry focuses on providing a vendor-neutral, single set of APIs for capturing metrics and traces, while OpenTracing focuses on tracing and providing a vendor-neutral API for distributed tracing.

OpenTelemetry also provides more built-in support for metrics and includes features such as automatic metrics collection and correlation, while OpenTracing primarily focuses on providing a consistent API for tracing, but does not have built-in support for metrics. Both projects are complementary and can be used together to provide a comprehensive observability solution.

To learn more about OpenTelemetry, and how it can support your projects, get in touch with the team at Chronosphere for a demo.