Push vs. Pull Metrics Collection

Metrics have to get from where they’re generated to where they’re stored and queried, and there are two fundamentally different ways to move them. In the pull model, the metrics backend reaches out and scrapes each target on a schedule. In the push model, each target sends its own metrics outward to a collector or backend. Both are widely used in production, and the choice shapes a lot of operational detail downstream.

The pull model

Prometheus is the model example: it’s configured with a list of targets (or a service-discovery mechanism that finds them dynamically), and it makes an HTTP request to each target’s /metrics endpoint at a fixed interval, parsing whatever the target currently reports.

The push model

StatsD popularized this approach for application metrics: applications send individual metric updates over UDP to a local StatsD daemon, which aggregates and forwards them onward. Most commercial platforms — Datadog, Amazon CloudWatch, and others — also use a push model, typically via a local agent that collects metrics and ships them outward to the vendor’s ingestion endpoint on an interval.

Why it matters

• Pull simplifies knowing what’s alive. Because Prometheus actively scrapes, a target that stops responding is immediately and unambiguously “down” — this is the basis of the up metric. A push-based system has to infer staleness from the absence of incoming data, which is a weaker signal.
• Push handles network topology that pull can’t reach. If targets sit behind NAT, in short-lived serverless functions, or in a network the metrics backend can’t initiate connections into, pushing metrics outward avoids needing inbound connectivity or firewall exceptions to every target.
• Pull gives the backend control over collection rate and load. Because the server decides when to scrape, it can protect itself from being overwhelmed and can enforce limits (like Prometheus’s sample_limit) at the point of collection, which is a natural chokepoint for the cardinality controls described elsewhere in this hub.
• Push suits ephemeral and batch workloads better. A cron job or short-lived batch task may finish and exit before a pull-based scrape would ever happen; pushing its final metrics out (for example to Prometheus’s Pushgateway) is the only way those numbers get captured at all.

Trade-offs and practical details

• Service discovery vs. firewall complexity. Pull-based systems need to know what to scrape, which usually means integrating with a service discovery mechanism (Kubernetes, Consul, cloud provider APIs) that keeps the target list current as instances come and go. Push-based systems avoid that discovery problem but need every target to have outbound network access to the collector, which can be its own firewall and NAT headache in locked-down environments.
• The Pushgateway is a narrow exception, not a general push mechanism. Prometheus’s own project documentation is explicit that the Pushgateway exists specifically for ephemeral and batch jobs that would otherwise never be scraped, and that it is a metrics cache rather than an aggregator — using it as a general-purpose push path for long-running services defeats the advantages of pull and is explicitly discouraged.
• Push gives applications more control over cardinality at the source, since the client decides exactly what to send and when, whereas a pull-based scrape captures whatever the target currently exposes, for better or worse — though this cuts both ways, since a push-based client can just as easily flood the ingestion pipeline with bad labels.
• Push fits managed/SaaS backends naturally. When the metrics backend is a vendor’s cloud service that your infrastructure doesn’t have direct network access to scrape, having an agent push data outward is usually simpler than exposing internal endpoints to the internet.

Which systems use which model

Prometheus, and Prometheus-compatible systems like VictoriaMetrics, default to pull. StatsD, Amazon CloudWatch (via the CloudWatch agent), Datadog, and most other commercial APM platforms default to push, usually through a locally running agent. Some systems support both: Prometheus can accept pushed metrics via the Pushgateway for ephemeral jobs, and remote-write lets it forward its scraped data onward to a push-style long-term storage backend, so the two models increasingly coexist within a single pipeline rather than forcing an all-or-nothing choice.