It's still focused on pull, while there is the Pushgateway (see
https://prometheus.io/docs/instrumenting/pushing/ and
https://prometheus.io/docs/practices/pushing/) for dealing with one-off situations where you cannot scrape something. Pull works great in most situations where people have their own private clouds or datacenters, but it's less suitable for very restrictive environments where you can't run Prometheus on the same network or behind the same firewall as the targets you want to monitor.
In the usual cases, pull has many benefits however:
- You can get high availability by simply running two identically configured, independent Prometheus servers. No clustering required.
- You can run a copy of production monitoring (or similar) on your laptop without changing production. This is great for experimentation and testing changes.
- You get free up-ness monitoring via scrapes and can use this for alerting.
- When there's an HTTP pull endpoint on service instances, you can also go there manually as a human and check out the current metrics state of any target, independent of the Prometheus server.
- Knowledge of service identities is inverted: instead of each service instance having to know its own identity (usually instance="hostname:port" and some job/service name), the monitoring system knows (usually via some form of service discovery) what instances should be there and how they are labeled, and proactively checks on them. Services have no knowledge of where the monitoring system lives anymore, enabling the above use cases.
- Debatable, but push-based monitoring systems can make it easier for someone to accidentally DDoS your monitoring. (still possible with pull, but you have one central place where you know what you pull from)