Prometheus vs. InfluxDB: A Monitoring Comparison

Monitoring has been around since the dawn of computing. Recently, however, there’s been a revolution in this field. Cloud native monitoring has introduced new challenges to an old task, rendering former solutions unsuitable for the job.

When working with cloud native solutions such as Kubernetes, resources are volatile. Services come and go by design, and that’s fine—as long as the whole system operates in a regular way. Classical monitoring solutions aren’t always able to handle this transience gracefully.

This post will pit Prometheus vs. InfluxDB to compare two modern monitoring solutions, examining their similarities and differences, and identify their best use cases.

For those interested in a Prometheus managed service or unifying metric monitoring with log and trace analysis, we’ll also weave Logz.io Prometheus-as-a-service into the comparison every once in awhile.

Prometheus vs. InfluxDB: An Overview

Prometheus is a database optimized for time series data and an ideal way to store monitoring metrics. Prometheus graduated from the Cloud Native Computing Foundation (CNCF), which means it has great integration with other CNCF components.

It features built-in service discovery, making it easy to use in highly dynamic environments. Unlike traditional monitoring tools, Prometheus uses a pull model which allows it to scale better. To access data, Prometheus offers a flexible query language called PromQL.

InfluxDB is a time series database designed for fast, high-availability storage and retrieval of time series data. It can work as a stand-alone solution, or it can be used to process data from Graphite. In addition to monitoring, InfluxDB can be used for the Internet of Things, sensor data, and home automation solutions. Just like Prometheus, it features its own query language inspired by SQL.

Even though the database itself is an open-source project, it implements closed-source components to allow clustering. For a more detailed comparison of Prometheus and Graphite, check out this article.

A High-Level Comparison: Prometheus vs. InfluxDB

Features

Data Collection

InfluxDB is a push-based system. It requires an application to actively push data into InfluxDB.

Prometheus is a pull-based system. An application publishes the metrics at a given endpoint, and Prometheus fetches them periodically.

Storage

InfluxDB is much more suitable for event logging. Prometheus is focused on metrics recording. They both require some manual effort to manage and scale. Prometheus, for example, requires configuring and installing new Prometheus servers whenever you need to scale, plus routine upgrades.

To eliminate these maintenance requirements, Logz.io delivers Prometheus-as-a-service to provide scalable metrics storage, alerting, and visualization for 18 months, out-of-the-box.

You can get started by forwarding your existing Prometheus metrics to Logz.io by adding a remote write to your Prometheus configuration files.

Visualization and Dashboards

Both Prometheus and InfluxDB feature basic visualizations and dashboards. To truly shine, they should be deployed alongside dedicated visualization and dashboard solutions, such as OSS Grafana or Chronograf.

Logz.io users can begin monitoring popular cloud technologies out-of-the-box with prebuilt monitoring dashboards.

Plug-in Architecture and Extensibility

The main advantage of Prometheus is its huge community support, which is based on its CNCF graduated project status. Many applications, especially cloud native ones, already offer Prometheus support out of the box.

While InfluxDB also features many integrations, it is not as ‘well-connected’ as Prometheus.

Community

Prometheus and InfluxDB are both open-source, and both are well maintained by active developer communities. As of January 2020, Prometheus’ primary GitHub repo has been forked over 4,600 times, compared to InfluxDB’s 2,600 forks.

Use Cases

Prometheus was built with monitoring in mind—especially distributed, cloud native monitoring. It excels in this category, featuring lots of useful integrations with other existing products.

While InfluxDB can also handle monitoring, it’s not as popular as Prometheus for accomplishing this task. As a result, you may be required to write your own integrations. However, if you are interested in more than just monitoring, InfluxDB is also a great option for storing time series data, such as data coming from sensor networks or data used in real-time analytics (e.g., financial data or Twitter stats).

Visualization with Open Source Grafana

When it comes to monitoring and querying, Prometheus is a powerful tool. When it comes to UI, it has its drawbacks. Because of this, most people use the OSS Grafana edition with Prometheus most of the time. Since open source Grafana has a pluggable data source model, it can be used with both Prometheus and InfluxDB. Let’s look at how to configure both.

And for those who prefer a unified view of metric, log, and trace monitoring, Logz.io’s open source observability platform may be a good option to visualize, monitor, and correlate all of your telemetry data together.

Configuring OSS Grafana with Prometheus

For a detailed, step-by-step article on how to set up and configure OSS grafana and Prometheus, please refer to our tutorial, Prometheus Monitoring with Open Source Grafana. For a quick and easy example that illustrates the power of these two tools in combination, we’ll use a preconfigured component. Assuming you have access to a Kubernetes cluster, you’ll want to access the Prometheus operator Helm chart.

To use the Helm chart, you first need to install it. Depending on the operating system, you can use brew install helm (for macOS and Linux) or choco install kubernetes-helm (for Windows). After that, you can run a few Helm commands to install the Prometheus Operator:

helm repo add stable https://kubernetes-charts.storage.googleapis.com/
helm install stable/prometheus-operator --name po

After a while, your Prometheus Operator should be running. You can verify that by calling kubectl get pods and checking to see that they are all in the running state. Then, access OSS grafana by calling:

kubectl port-forward $(kubectl get pods -l "app=grafana,release=po" -o jsonpath="{.items[0].metadata.name}") 3000:3000

Now, you should be able to access OSS grafana at http://localhost:3000. The login to access the panel is admin, and the default password is prom-operator.

In the OSS grafana panel, you can either explore the preconfigured dashboards or create your own. The screenshot below provides an example of a preconfigured dashboard showing cluster health:

Configuring OSS Grafana with InfluxDB

Here is a short OSS grafana-InfluxDB tutorial. There isn’t a ready-made, all-in-one Helm chart for InfluxDB with OSS grafana, so, for this process, you will need to do more work. We’ll use Helm to simplify the installation—as we did with Prometheus—installing charts for OSS grafana and InfluxDB separately:

helm repo add stable https://kubernetes-charts.storage.googleapis.com/
helm install stable/influxdb --name influxdb
helm install stable/grafana --name grafana

To access grafana, use admin-user and the password admin-password. Forward the application’s port with:

kubectl port-forward $(kubectl get pods -l "app=grafana,release=grafana" -o jsonpath="{.items[0].metadata.name}") 3000:3000

Since we want our data pumped into InfluxDB, we will also modify Heapster to feed our InfluxDB instance. To do this, we need to open an editor with Heapster deployment using:

kubectl edit deployment heapster -n kube-system

Inside the editor, search for the spec.containers.command section and add as the last line of the command:

--sink=influxdb:http://influxdb-influxdb.default:8086

Then, go to the OSS grafana dashboard and add the InfluxDB data source, pointing to http://influxdb-influxdb.default:8086 and selecting k8s as a database. This rundown of dashboards will give you some dashboard configuration inspiration. 

The screenshot below illustrates an example of a CPU metrics dashboard:

Summary

Both of these products are excellent time series databases. They differ in their default mode (push for InfluxDB, pull for Prometheus). Some people argue that PromQL, Prometheus’ language, is simpler than the language used by InfluxDB, but, all in all, the decision to use one tool or the other will probably depend on your use case.

If monitoring is what you’re most interested in, Prometheus is your safest bet because of its many integrations and scalable model. If you’re more likely to be using a time series database for IoT, sensors, or analytics, then you’ll probably want to choose InfluxDB.

If you prefer Prometheus, but are also looking for a unified observability platform, check out Logz.io’s sandbox to see how we bring together Prometheus metrics alongside log and trace analytics. The data processing and storage is managed for you on Logz.io’s cloud service, so you don’t have to manage the data infrastructure yourself.