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 9-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”
In 2011, Etsy was obsessed with measuring everything. They wanted developers to instrument their code liberally, track page views, feature usage, error counts, processing times, without worrying about the performance impact of sending metrics.
The problem: existing metrics systems used , which meant each metric emission opened a connection, waited for acknowledgment, and could block the application if the metrics server was slow. Developers hesitated to add instrumentation because they didn't want to risk slowing down production code.
Etsy built StatsD, a tiny daemon that receives metrics over UDP. UDP is fire-and-forget: the application sends a packet and doesn't wait for a response. If the StatsD daemon is down, the packet is silently dropped, the application is completely unaffected. No connections, no blocking, no risk.
This "zero-cost instrumentation" philosophy made StatsD wildly popular. It's now supported by virtually every metrics backend and used by thousands of organizations. The protocol is so simple that you can implement a StatsD client in 10 lines of code.
StatsD metrics are plain-text UDP packets with a dead-simple format:
<metric_name>:<value>|<type>
| Type | Symbol | Example | Meaning |
|---|---|---|---|
| Counter | c | orders.completed:1|c | Increment a counter by 1 |
| Timer | ms | api.latency:234|ms | Record a timing value in milliseconds |
| Gauge | g | queue.depth:42|g | Set a gauge to 42 |
| Set | s | users.unique:user123|s | Track unique values |
Sample rate. StatsD supports client-side sampling to reduce network traffic:
api.latency:234|ms|@0.1
This says "I'm only sending 1 in 10 measurements". StatsD adjusts its aggregation accordingly, multiplying the count by 10.
How StatsD fits in the pipeline:
The aggregation step is important, instead of sending 10,000 individual measurements per second to the backend, StatsD computes the count, sum, min, max, and percentiles locally and sends one summary every 10 seconds.