OpenTelemetry vs. Prometheus

OpenTelemetry and Prometheus can accomplish their goals in different ways. To better understand how the choice will affect the overall business, it is important to review the technical details. Below are the eight key areas where the offerings differ.

1. Type of service and scope

As stated, OpenTelemetry and Prometheus are fundamentally different types of services. OpenTelemetry is an observability framework, not an observability tool. It facilitates the collection of observability data, but it doesn't directly provide capabilities like data inspection or alerting. Users would need to use OpenTelemetry in conjunction with an observability tool to do these things.

Prometheus is mainly an observability tool. It also provides native integrations for collecting some types of telemetry data -- specifically, metrics -- from applications and infrastructure. In that sense, it facilitates telemetry data collection like OpenTelemetry. But its focus is on interpreting telemetry data, not collecting it. It's possible to use OpenTelemetry as a data collection framework in conjunction with Prometheus, rather than using Prometheus's native data collectors.

2. Supported telemetry data types

OpenTelemetry can help admins collect all of the key types of observability data -- metrics, logs and traces, which are collectively known as the pillars of observability.

Prometheus only supports metrics. To collect and analyze logs and traces, users typically need to combine Prometheus with additional tools -- such as Graylog for logs and Jaeger for tracing.

A caveat is that there are a handful of Prometheus extensions or integrations that make it possible to ingest other types of data. For example, the fluentd_exporter can export log data. But once inside Prometheus, the data is presented as metrics. Even in this case, Prometheus is still not a log collection or analysis tool.

3. Integrations and tool compatibility

OpenTelemetry can export telemetry data into virtually any of today's mainstream observability tools. This is advantageous for users who work with multiple observability tools, or who want the freedom to migrate from one tool to another without having to reconfigure data collection pipelines. With OpenTelemetry-compliant tools, users can migrate with minimal reconfiguration requirements. This also frees up businesses to make strategic buying decisions without technical complexities.

Prometheus can also integrate with a wide variety of data sources and export data to some other observability tools. But it's not as flexible as OpenTelemetry. Prometheus's data collection technologies and configurations are specific to Prometheus. Users who want to migrate from Prometheus to an alternative observability tool need to reconfigure their data pipelines from scratch -- unless they were using OpenTelemetry to provide data to Prometheus.

4. Data movement models

Another consideration is whether an organization is looking for a push- or pull-based data movement model.

Push-based model. Data sources can export data to observability tools automatically.

Pull-based model. Data collection tools must discover new data sources to begin importing data, which can delay the data collection.

Prometheus is a pull-based observability tool, and it imports metrics data from the applications or infrastructure it monitors. OpenTelemetry is more flexible. It can support both pull- and push-based approaches to data collection.

While a pull-based data model works fine in many circumstances, having the option to push data can be advantageous. Push-based data movement can help ensure that data arrives within observability tools quickly. It's also beneficial in environments in which additional data sources might appear dynamically, such as a containerized application spinning up a new container instance automatically.

5. Infrastructure requirements

OpenTelemetry and Prometheus can run on almost any infrastructure. They're also compatible with the major OSes such as Linux, Windows and macOS.

That said, the infrastructure setup for Prometheus tends to be simpler and more straightforward because Prometheus includes a built-in database. This eliminates the need to provision separate storage infrastructure alongside Prometheus itself, except for large-scale Prometheus deployments. Then it might be necessary to offload storage using external tools like Thanos.  

Setting up host infrastructure for OpenTelemetry can be more complicated. Users must ensure that their servers have the CPU and memory infrastructure necessary to host OpenTelemetry data collection pipelines. They must also provision sufficient storage resources for hosting any logs, metrics and/or traces they want to retain.

6. Ease of use

Because OpenTelemetry and Prometheus are different types of observability offerings, it's hard to draw an apples-to-apples comparison about their ease of use or user-friendliness. However, in general, Prometheus is a simpler tool to operate for most use cases. It's fairly simple to deploy Prometheus, connect it to one or more data sources using the various exporters and integrations that Prometheus supports and then start collecting and analyzing data.

Getting started with OpenTelemetry can be more challenging. Users must decide exactly which types of telemetry data they want to collect, then configure the OpenTelemetry Collector accordingly. Users might need to set up multiple data collection pipelines to collect multiple types of data and/or work with multiple observability tools. OpenTelemetry is well-documented, but expect to face a steeper learning curve than with Prometheus.

7. Scalability

Scaling Prometheus is challenging because it typically requires the use of additional features and tools. These include the Federation capability, which makes it possible to run multiple Prometheus instances. Without Federation, users can only deploy one Prometheus instance, with the result that the amount of data they can process will be restricted by the CPU, memory and storage resources of the host server. Scaling can also require integrating Prometheus with third-party tools like Thanos, which helps to scale data storage.

Scaling OpenTelmetry is simpler because there are no inherent limitations on the amount of data users can collect or process. To work with more data than a single server can support, users can simply distribute their OpenTelemetry observability pipelines across multiple servers, without requiring additional tools or extensions.

8. Management and support services

Since OpenTelemetry and Prometheus are both open source, non-commercial tools, they don't come with any built-in support options. Users must set up and manage them on their own in most cases.

It's possible to find software management and support options for both tools, although this is generally easier with Prometheus. Several vendors offer Prometheus as a managed service, meaning they set up and manage the software for users -- often on their own infrastructure -- so users can focus on metrics analysis.

Managed services for OpenTelemetry are hard to come by. Many OpenTelemetry-compliant observability tools are available as managed service options, but planning and implementing the observability pipelines that move data into those tools is the user’s responsibility. No major vendors offer end-to-end OpenTelemetry management or support services.

Which observability option should businesses choose?

OpenTelemetry and Prometheus have their respective strengths and drawbacks. Neither tool is fundamentally better than the other. But there are factors that can make one preferential for certain cloud environments, admin teams or use cases.

In general, Prometheus is likely to be best for those who want immediate business value, as well as under the following circumstances:

• Metrics are the only type of telemetry data users need to analyze, or users will use other observability tools to supplement Prometheus.
• Users want a relatively simple, straightforward tool that doesn't require complex configuration.
• Pull-based data movement is sufficient for organizational workloads.
• Data collection needs are small or moderate, with less than 1 million time-series events at once.
• The observability tool will function as a managed service, without having to deal with setup and management.

Meanwhile, consider OpenTelemetry if the business is poised for growth and the following apply:

• Users want a holistic observability tool that can cover logs, metrics and traces.
• Telemetry data will move into multiple observability tools, or observability tools change frequently.
• Unlimited scalability from the cloud observability tool is a requirement.
• Expertise and staff resources exist on user teams for learning and implementing OpenTelemetry-based data movement pipelines.
• Users want the option to choose between pull- and push-based data movement models. 

Use OpenTelemetry and Prometheus together

OpenTelemetry and Prometheus are distinct services, and admins can use one without the other. However, they can also combine them by using OpenTelemetry to collect metrics and export them into Prometheus.

Configuring Prometheus to use OpenTelemetry is a bit more complicated than using it out-of-the-box data collection functionality. But, it offers the benefit of making it easy to integrate Prometheus into a broader set of cloud observability tools, all of which use OpenTelemetry to provide access to telemetry data. 

Chris Tozzi is a freelance writer, research adviser, and professor of IT and society. He has previously worked as a journalist and Linux systems administrator.