OpenTelemetry: 3 questions to ask before choosing an observability solution

As OpenTelemetry rises in popularity, more organizations are implementing, or planning to implement, the open source project to monitor their applications — and, meanwhile, more vendors are offering OpenTelemetry support. 

In fact, a quick Google search for “OpenTelemetry support” shows results ranging from legacy APM vendors to newer, cloud native solutions like Grafana Cloud. When deciding where to host your OTel data, it’s important to remember that not all solutions for OpenTelemetry were created equal. 

With this in mind, let’s look at three questions every organization should ask before choosing a vendor for OpenTelemetry. 

OpenTelemetry questions to ask 

1. What is the vendor’s true stake in OpenTelemetry (and open standards, in general)? 

One way to measure this commitment is to see how many contributions the vendor has made to the OpenTelemetry project in GitHub. It’s also important, however, to look at other roles they play in the project. For example, ask how involved the vendor is in steering decisions for the project. Are they involved in any of the roadmap items, do they participate in a special interest group, or do they have any team members on the OpenTelemetry Governance Committee? 

It’s also worth considering the company’s commitment to open source projects, in general. 

One place to look, as a starting point, is on the OpenTelemetry Vendors page, which not only indicates a vendor’s support for the OTel project, but provides a glimpse into potential “lock in” risks that some vendors pose. To reap all the benefits of OTel, you should be able to move out of a commercial offering and into an open source alternative with ease. This means not being required to use a custom distribution or SDK, and that components are interoperable with other tools. 

At Grafana Labs, we’ve taken a multifaceted approach to contributing to the OTel community. Yes, we contribute to the OpenTelemetry project, we lead talks about OTel at industry events, share our guides to OpenTelemetry best practices, and have team members on the CNCF and OpenTelemetry governing boards.

But on top of our direct contributions to the OTel project, we continue to prioritize and focus on OTel interoperability with Prometheus. We believe that, together, these two projects will break down the silo between infrastructure and application observability, providing a single view of all the components that support reliable software. And, of course, Grafana Labs is (and always has been) very active in the OSS community, more broadly — not only as it relates to our own OSS projects, but others in the ecosystem, such as Cortex and Graphite. 

2. How, exactly, does the observability solution support OpenTelemetry data? 

OpenTelemetry defines methods of instrumentation and semantic conventions for data, but does not define how to store and visualize that data. So, just because a product can ingest OpenTelemetry data does not mean it offers built-in features to manage and derive value from that data. 

This is important because an observability tool can be advertised as “having support for OpenTelemetry,” but then store OTel metrics or traces separately, in the backend, from data sent with a proprietary agent. This can have a couple implications on your observability strategy.  

First, it could mean not every feature that is available with a proprietary agent is available with OTel data. This sometimes isn’t obvious upfront, but is found in the fine print. Secondly, if an agent or database modifies the data as it’s stored, and then you export the data, it might require a lot of manipulation to be shared with another vendor or platform. 

At Grafana Labs, every metric, log, and trace is a first-class citizen, and every dashboard, alert, or workflow that you create can be done with OpenTelemetry-sourced data. We support native ingestion of OpenTelemetry protocol (OTLP) data and Grafana Agent has support for native metrics, logs and traces via OTLP. 

3. What features are available to manage and optimize costs? 

OpenTelemetry offers a new way to send observability data to a backend and can give much more control to the user, as they are instrumenting. Being able to decide what metrics and trace data they want, how that data is sent, and where it’s sent is a new level of control teams may not have had in the past. They’ll have to decide, for example, whether to accept all the metrics that come with auto instrumentation, and what sample rate they need. With this decision-making and control comes responsibility in making sure you collect the metrics, logs, and traces that are most important to you, and that you do so in an optimized and cost-efficient way. 

The OpenTelemetry instrumentation itself does not provide a lot of built-in levers to do this — so, the backend and visualization tool you store your data in should provide that transparency. 

Grafana Cloud has built-in tools to monitor your metrics intake, alert on high cardinality, and reduce total spend with Adaptive Metrics. These tools not only provide cost savings, but predictability in your observability spend and awareness of where you will be in the future for budgeting purposes. 

More resources for Grafana and OpenTelemetry 

Want to learn more about Grafana Labs and OTel? Be sure to check out our recent blog posts, as well as our Application Observability documentation. And if you’re ready to get started, the quickest and easiest way is via the OpenTelemetry Integration for Grafana Cloud.