Prometheus is a monitoring system that collects metrics from targets by scraping metrics via HTTP endpoints on these targets. The pull and push models are two different approaches adopted by various monitoring solutions.
The push model necessitates that the targets themselves actively send their metrics data to the monitoring system. Each target is responsible for pushing its metrics data to the central monitoring system or server. This approach might result in potential delays in identifying unresponsive targets and uneven loads on the monitoring solution due to simultaneous pushes from multiple applications.
Contrarily, The pull model involves the system actively fetching data from the targets. It requires the monitoring system to reach out to the targets and pull the metrics data from them at regular intervals.
Let’s explore some advantages of the pull model for monitoring.
1. Awareness of the targets
The Prometheus pull model requires your Prometheus system to know all the targets. This is achieved through Prometheus Service Discovery.
Prometheus Service Discovery allows you to automatically discover and monitor services in your environment. More than 20 systems are supported, like Kubernetes, Consul, and major cloud providers.
Knowing the targets, based on a source of truth, allows Prometheus to identify expected targets. If a defined target is unresponsive, its status will be immediately apparent and recorded as offline.
2. Notification of Unavailability
Similarly, thepull model provides direct feedback when a target is unresponsive. Instead of relying on the absence of pushed metrics, which might take time, immediate notifications can be received when a target fails to provide its metrics.
3. Central configuration
In the pull model, metric frequency and other configurations are centralized. In a push model, every application has to be configured to an endpoint. Changing the push interval is therefore becoming a complex problem.
4. Load Distribution
Prometheus evenly distributes the load when pulling targets, avoiding simultaneous attempts to fetch all targets. It also means that scrapes and metrics will be evenly spread over a given time interval.
When pushing metrics, multiple applications could push at the same time, e.g. if they are started at the same moment, leading to uneven load of the monitoring solution.
5. High Availability
As the application is exposing metrics, it does not matter how many Prometheus servers are consuming the data. You do not have to deal with multiple endpoints configuration and load balancers/a fallback solution when the server you are pushing to is down.
6. Local Data Viewing
Because the applications expose metrics over HTTP, you can easily look at the
metrics at any moment. Even on a machine that has only a few tools installed,
you can query your metrics with curl. No extra configuration is needed.
Combining pull & push
While the pull model has been chosen for Prometheus, there are scenarios where you want to push your monitoring data to another location. In this situation, the Prometheus Agent (or a Prometheus server) can run on the edge and forward the metrics data to another Prometheus server or a Long Term Storage solution, such as Thanos or Grafana Mimir.
If you need advices about setting up a resilient monitoring solution based on Prometheus, contact us.
