Collecting Metrics: Push vs. Pull

How Does the Data Get There?

There are two main philosophical approaches to getting metrics from your applications into your monitoring system. The choice has significant operational implications.

1. The Push Model

Your application or a local agent running on the server actively sends (pushes) metric data to a central monitoring backend on a schedule.

• Examples: StatsD, Graphite, InfluxDB's Telegraf agent, AWS CloudWatch agent.
• Pros: Works well for short-lived jobs or batch processes that might finish before a monitoring system could scrape them. The application controls when data is sent.
• Cons: The application must be configured with the address of the monitoring server — creating a tight coupling. A sudden spike in applications all pushing simultaneously can overwhelm the central server. It's harder to detect if an application has silently died (it just stops sending, which looks the same as "no activity").

2. The Pull Model (Prometheus Style)

Your application exposes a simple HTTP endpoint (conventionally /metrics) that lists its current metric values in a plain-text format. The central monitoring system periodically connects to the application and reads (pulls, or "scrapes") the data.

• Examples: Prometheus, Victoria Metrics, Grafana Mimir.
• Pros: The application has zero knowledge of the monitoring system — no configuration coupling. The monitoring system controls the scrape rate, so it cannot be overwhelmed by a data flood. A failed scrape immediately signals that the target is down. Easy to debug: you can curl http://my-app:8080/metrics and see exactly what Prometheus sees.
• Cons: Requires the monitoring system to have network access to every application instance. Not ideal for very short-lived batch jobs (use a Pushgateway as an intermediary for those cases).

The cloud-native world has largely adopted the Pull Model due to its robustness and simplicity in dynamic environments like Kubernetes, where application instances come and go constantly. A Prometheus /metrics endpoint exposes this as plain text: a HELP comment describing each metric, a TYPE comment declaring whether it's a counter or gauge, and then the current value for each label combination.