Prometheus operates on a pull-based model. This means that instead of monitored systems actively sending (pushing) their metrics to Prometheus, Prometheus itself periodically pulls the metrics from these systems.
Exporters: Prometheus doesn't directly monitor every type of application or system. Instead, it relies on intermediary components called exporters. These exporters are lightweight applications that run alongside the systems you want to monitor. They collect metrics from the target system and expose them in a format that Prometheus can understand (typically over HTTP on a /metrics endpoint).
Scraping: Prometheus is configured with a list of targets (IP addresses and ports) where these exporters are running. At regular intervals (defined by the scrape_interval configuration), Prometheus initiates an HTTP GET request to the /metrics endpoint of each target.
Data Storage: The exporters respond with the current metrics data, which Prometheus then ingests and stores in its time-series database.
Why Pull is the Primary Method for Prometheus:
Centralized Control: The Prometheus server has control over when and how frequently metrics are collected. This makes it easier to manage and configure the monitoring system.
Reliability: If a monitored system experiences a temporary network issue or goes down, the metrics won't be lost. Prometheus will simply fail to scrape during that period and will resume when the system comes back online. With a push model, metrics might be lost if the receiving system is unavailable.
Simplicity for Monitored Systems: Monitored systems only need to expose their metrics in a specific format. They don't need to be aware of the Prometheus server or its configuration.
Easy Discovery: Prometheus can be configured to automatically discover targets using service discovery mechanisms (like Kubernetes service discovery). This makes it easier to scale and manage large monitoring environments.