Course contentsShow
← Node.js
Lesson 1689 of 1,98015. Logging, Observability, and MetricsFree lesson

Push vs Pull Metric Models

Choose between pushing telemetry to a collector or exposing an endpoint for external scraping.

In this lesson, you will learn how to architect your observability layer by choosing between two fundamental strategies: pushing metrics to a collector or exposing them for external scraping.

The Pull Model (Scraping)

In the pull model, your Node.js application acts as a server, typically exposing a /metrics endpoint. A centralized monitoring system (like Prometheus) periodically hits this endpoint to "scrape" the current state of your process.

  • Pros: The application doesn't need to know the address of the monitoring system; it only needs to provide data. It allows for easier service discovery and backpressure handling—if the collector is overwhelmed, it simply slows down its scrape interval.
  • Implementation: You provide a registry of your Counter or Histogram metrics that are rendered as plain text when the endpoint is requested.
// A simple pull-based metric exposure
app.get('/metrics', async (req, res) => {
  res.set('Content-Type', registry.contentType);
  res.end(await registry.metrics());
});

The Push Model

In the push model, your Node.js application takes the initiative. It periodically sends (pushes) telemetry data to a remote gateway or collector (like StatsD or an OpenTelemetry Collector).

  • Pros: This is ideal for short-lived processes, such as serverless functions or batch jobs, which may exit before a scraper can reach them. It also simplifies network topology in complex environments where the collector is behind a firewall and cannot reach individual application instances.
  • Cons: You must handle the overhead of outgoing network requests within your event loop and implement robust retry logic to avoid losing metrics if the collector is temporarily unavailable.

Choosing Your Strategy

Choosing between these models depends on your infrastructure. If you are running long-lived Node.js services inside a container orchestrator (like Kubernetes), the pull model is the industry standard; it treats your services as data sources and lets the infrastructure manage the collection. If you are dealing with transient, ephemeral processes, the push model ensures that your precious performance data survives even after your process terminates.

Key Takeaway: Choose the pull model for long-running services to simplify discovery and backpressure, and use the push model for ephemeral tasks to ensure telemetry is captured before the process exits.