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 8-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”
When Google's SRE team was codifying their monitoring practices for the SRE book, they asked a fundamental question: if you could only monitor four things about a service, what would they be?
Their answer, the Four Golden Signals, has become the industry standard framework for service monitoring. Not because Google is special, but because the framework works. It applies to an API service, a database, a queue, a cache, or virtually any distributed system component. Four signals. Not forty. Not four hundred. Four.
The genius is in what it excludes. CPU usage, disk I/O, thread counts, connection pools, these are all useful, but they're implementation details. The golden signals measure what the user actually cares about: is the service responding (), is it handling my requests (traffic), is it working (errors), and is it about to fall over (saturation)?
1. . How long does it take to serve a request?
Track latency separately for successful and failed requests. A failed request that returns in 1ms (because it short-circuited on an error) shouldn't bring your average latency down. The distribution matters, track P50, P95, P99, not just the average.
2. Traffic. How much demand is being placed on the service?
For a web service: HTTP requests per second. For a database: queries per second. For a : messages per second. For a streaming service: bytes per second. Measure the thing that represents "work being asked of the service."
3. Errors. What fraction of requests fail?
This includes explicit failures ( 5xx), implicit failures (HTTP 200 but wrong content), and policy violations (responses that succeed but violate your latency SLO, like a response that takes 10 seconds). Not all errors are HTTP errors, some are logic errors buried in a 200 response.
4. Saturation. How "full" is the service?
Saturation measures how close a resource is to its limit. CPU at 90%. Connection pool at 95%. Disk at 85%. Memory at 92%. The resource that saturates first becomes the bottleneck. Saturation is the early warning, it tells you the service is about to degrade before it actually does.