Advantages of Prometheus's Pull Model

Prometheus's core architecture, the pull model, is a method where the server periodically scrapes metrics from clients.

Many existing monitoring systems (e.g., Zabbix agent, Telegraf, StatsD) used a push model where clients push data to the server.

However, Prometheus boldly adopted the pull model, which acts as a strength in cloud-native MSA environments.

Intuitive and Certain Fault Detection #

With the push model, when data didn't arrive from a client, it was difficult to immediately determine if it was due to a network disconnection, a client server going down,

or simply because there were no metrics to send.

However, with the pull model, if the Prometheus server sends an HTTP request (usually to /metrics) to a specific target and receives no response or it fails, it can immediately confirm that a fault has occurred on that target.

Prometheus automatically generates a metric called up (1 for healthy, 0 for unhealthy) for this status, providing a very intuitive and certain target health check.

Monitoring Server Load Control #

Regarding flow control, with the push model, if the number of target servers increases to thousands or tens of thousands, a DDoS-like situation can occur where numerous agents simultaneously flood the monitoring server with data.

Ultimately, the monitoring server itself can become overloaded and crash due to the incoming traffic.

On the other hand, with the pull model, the monitoring server has the initiative for data collection. No matter how many targets there are, Prometheus can adjust the collection interval and limit the number of collections according to its processing capacity,

thereby preventing the monitoring system itself from collapsing due to overload.

Simplified Client Configuration #

In the push model, clients must know the monitoring server's IP address, port, and authentication information.

If the monitoring server configuration changes, a terrible situation arises where settings on all clients must be modified.

However, with the pull model, clients only need to expose their metrics on a specific port,

and they don't need to know who collected the data or where the monitoring server is located. This means each service is perfectly decoupled from the monitoring infrastructure.

High Availability #

When configuring high availability with multiple Prometheus servers, the pull model is overwhelmingly convenient.

Without any client configuration changes, it's simply a matter of having multiple Prometheus servers point to the same target and scrape data independently.

If it were a push model, additional configuration would be needed for clients to duplicate traffic and send data to two monitoring servers separately.

Easy Debugging #

When a developer writes metric collection logic and wants to check if the data is coming out correctly, the pull model is excellent.

Because you can simply open a browser or type curl http://localhost:8080/metrics in the terminal,

you can directly verify the data in plain text in the format Prometheus will scrape, eliminating the need to set up a complex fake collection server.

Limitations #

Of course, the pull model is not a panacea. It has critical drawbacks when target servers are hidden behind firewalls/NAT, making them inaccessible from outside (Prometheus),

or in the case of short-lived batch jobs that execute and terminate within seconds, which are difficult to pull directly.

To overcome these limitations of the pull model, Prometheus provides a workaround called pushgateway.