This is the second post on Prometheus and I will try to list out the Advantages of Prometheus over other monitoring tools. In the previous article, we discussed about different methodologies using in modern world and a quick introduction to Prometheus. I suggest you to read that article first, Modern Monitoring Concepts – An Intro To Prometheus World
In this article, we will discuss more about Prometheus’ advantages compared to other tools. We will discuss more topics on Prometheus in upcoming posts. You can follow my LinkedIn page for updates.
Advantages of Prometheus over other monitoring tools
1, Prometheus is TSDB
Yeah, Prometheus is TSDB, Time Series DataBase. A TSDB is a database optimised for time stamped or time series data. Time series data are simply measurements or events that are tracked, monitored, down sampled and aggregated over time. Example: Server metrics, application performance monitoring etc…
Simply TSDB contains a collections of data obtained through repeated measurements over time. You can plot the the points on a graph, one thing is, one of your axes should always time. If you’re interested about TSDB, this link contains some real examples.
As prometheus is a TSDB, here, we will get all advantages of TSDB in Prometheus monitoring tool. Advantages like, more data points, more data sources, more monitoring, more controls, data integrity and security, efficient disk usage etc..
2, Prometheus is Pull based tool
This is one of the noticeable difference between Prometheus monitoring and other time series database. Prometheus actively scrape targets in order to retrieve metrics from them.
Prometheus expects to retrieve metrics via HTTP calls done to certain endpoints that are defined in Prometheus configuration. Node exporter and App exporters will listen on particular ports and Prometheus server initiate a HTTP call to this particular exporter and fetch system / app metrics from end points.
3, Centralised control
As we mentioned in point number 2, it’s a pull based system, Prometheus initiates queries to its targets. The whole configuration is done on Prometheus server side and not on the client side.
Which means you can decide who to scrape, and how often you should scrape them. With a push based system, you may have the risk of sending too much data towards your server and essentially crash the server. A pull based system enables a rate control with the flexibility of having multiple scrap configurations, thus multiple rates for different targets.
This you can control from a centralised area – that your Prometheus server. So it’s completely under your control.
4, In built Alerting facility
As I mentioned in the first post, Alert Manager is one of the main components in Prometheus ecosystem. Once we have enough data, we must have to analyse it, visualise it and send alerts to respective members or team. So alerting is one of the important components in monitoring system.
Prometheus pushes alerts to the Alert manager via custom rules defined in configuration files. From there it will send notifications to different endpoints such as Slack, Google hangout, BigPanda etc.
5, Easy for monitoring teams
Yeah, once it’s implemented, it will be very useful for monitoring team. Consider the following example;
You have thousand plus servers and you’re monitoring server using Nagios. So you want to add one more new check to get alerts once the disk usage is greater than 70%. In traditional way, you need to do changes in many places , as the hosts are under many groups. Here, in Prometheus way, it’s easy to created Alert rules / conditions in Alert Manager.
They can easy configure different endpoints for alerting.
6, Data visualisation
similarly to Grafana, you can visualize your time series directly in Prometheus Web UI. You can easily filter and have a concrete overview of what’s happening on your different targets.
This GUI is not that mush good like Grafana, but we can test some queries before adding it to Grafana or other visualisation tools.
7, Service discovery (sd)
Prometheus can discover your targets dynamically and automatically scrap new targets on demand. Prometheus offers a variety of service discovery options for discovering scrape targets, including Kubernetes, Consul, and many others.
If these kind of service discovery options are not supported / available on your infra, you can use the file based service discovery. In this method you can add the scrape configurations in a JSON file. So you can add more scrape configurations without restarting the Prometheus server. This we will discuss in detail later.
Prometheus is highly scalable. You can club different Prometheus servers to a single one using federation approach. You can scrape different Prometheus servers using “/federation” end point. Read more from this page.
This federation approach is useful, if you have thousands of servers at different DCs. You can just setup individual Prometheus servers per DC and then scrape the details from Prometheus servers using federation end points.
Prometheus provides a functional query language called PromQL (Prometheus Query Language) that lets the user select and aggregate time series data in real time. PromQL is fast simple query language.