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”
In 2018, Charity Majors (co-founder of Honeycomb and former Facebook infrastructure engineer) drew a distinction that changed how the industry thinks about system visibility: "Monitoring is for known-unknowns. Observability is for unknown-unknowns."
Monitoring answers predefined questions: "Is CPU above 90%? Is the error rate above 5%? Is the database reachable?" You set up checks for failure modes you can anticipate.
Observability answers questions you haven't thought of yet: "Why are users in Brazil experiencing 10x only on Tuesdays between 2-4 PM when they access the recommendations endpoint?" You didn't write a monitor for that. You couldn't have predicted it. But with good observability, you can investigate it on the fly, slicing and dicing your telemetry data until the answer emerges.
The shift from monitoring to observability isn't just a vocabulary change. It's a fundamental upgrade in how you understand and operate complex systems, and it becomes essential the moment your architecture grows beyond a handful of services.
Observability rests on three complementary data types, each answering different questions:
Logs. What happened? Discrete events with context. "At 10:30:12, user alice@example.com attempted to check out order #8834 and received a 'payment_declined' response from Stripe with error code 'card_expired'."
Logs are rich in detail but hard to aggregate. They're your forensic evidence, perfect for investigating a specific incident after the fact.
Metrics. How much? How often? How fast? Numerical measurements over time. "Request rate: 3,200/sec. Error rate: 0.3%. P99 : 180ms. CPU: 62%."
Metrics are cheap to store, easy to aggregate, and great for dashboards and alerts. They tell you the overall health at a glance but lack the detail to explain why something is happening.
Traces. What path did this request take? A request's journey through your distributed system. "This request entered at the , called the auth service (12ms), then the cart service (45ms), which called the inventory service (234ms, slow!), and finally the payment service (89ms). Total: 412ms."
Traces connect the dots across services, showing you exactly where time is spent and which service is the bottleneck.
| Pillar | Strength | Weakness | Best For |
|---|---|---|---|
| Logs | Rich detail, context | Expensive at scale, hard to aggregate | Debugging specific incidents |
| Metrics | Cheap, aggregatable, alertable | No detail about individual requests | Dashboards, alerts, capacity planning |
| Traces | Shows request flow across services | Complex to implement, sampling needed | Latency debugging, dependency mapping |