We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Observability Monitoring
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Observability Monitoring
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
Imagine flying a commercial airplane with no instruments. No altimeter, no airspeed indicator, no fuel gauge. You'd look out the window and guess. "Seems like we're high enough. Engine sounds fine. Probably have enough fuel." That's terrifying, and it's exactly how most applications run before metrics collection is set up.
Without metrics, you make decisions based on gut feeling and user complaints. "The site feels slow" is not actionable data. "P99 for the checkout endpoint increased from 200ms to 1.4s at 3:17 PM, correlating with a database connection pool saturation event", now you know what happened, when, and where to look.
Metrics collection is the process of instrumenting your applications and infrastructure to emit numerical measurements at regular intervals. CPU usage every 10 seconds. Request count per minute. Error rate per endpoint. Queue depth per consumer group. These numbers, collected over time, become the foundation of every monitoring dashboard, every alert, and every capacity planning decision you'll ever make.
There are two fundamental ways to get metrics from your systems:
Pull model (scraping). A central collector periodically asks each service "give me your current metrics." is the most famous example. Your application exposes a /metrics endpoint, and Prometheus scrapes it every 15 seconds.
Push model. Each service actively sends its metrics to a central collector. StatsD, Datadog Agent, and CloudWatch follow this model. Your application calls something like metrics.increment("orders.completed") and the library ships it off.
| Aspect | Pull (Prometheus-style) | Push (StatsD-style) |
|---|---|---|
| Who initiates? | Collector fetches from targets | Targets send to collector |
| Discovery | Collector needs to know all targets | Targets need to know collector address |
| Short-lived jobs | Misses jobs that start and stop between scrapes | Works well, metrics sent immediately |
| Network direction | Collector reaches into your services | Services reach out to collector |
| Firewall friendliness | Collector needs access to all targets | Only outbound from services needed |
Neither model is strictly better. Prometheus's pull model works beautifully for long-running services in Kubernetes where is built in. Push models work better for serverless functions, batch jobs, and environments where services can't expose HTTP endpoints.
Many production setups use both. Prometheus for infrastructure and long-running services, push-based collection for ephemeral workloads.