30. Observability
1
The picture to keep in your head2
30.1 Why do you need observability?3
30.2 What are the three pillars?4
30.3 What are golden signals, RED and USE?5
30.4 What are SLI, SLO and SLA?6
30.5 What are error budgets?7
30.6 How do you alert without noise?8
30.7 What makes a good dashboard?9
30.8 How do you debug an incident, step by step?10
Memory card and where the analogy breaks11
Practice: five levels12
Interview questions13
Solutions14
Sources15
Code lab30. Observability
30.1 Why do you need observability?
3 min read+10 XP
The signals
In the car: A mechanic who can plug in a diagnostic reader finds the fault in minutes. Without it, they take the engine apart piece by piece.
In the system: Modern systems have many services, many instances, queues, caches and third parties (Chapters 22 to 29). When something goes wrong, the question is never just "is it up?" but:
- Is it actually broken for users, or is a graph just wiggling?
- For whom? All users, one region, one app version, one payment method?
- Since when, and what changed then (a deploy, a config, a traffic spike)?
- Where in the chain of services is the time or the error coming from?
Monitoring watches known things: "alert if error rate > 1%". Observability is broader: having enough rich data (logs, metrics, traces with useful context) to answer new questions you didn't think of in advance, like "why are checkouts slow only for UPI payments from the v42 Android app?"
What it buys you:
- Shorter outages: time to detect and time to fix both drop.
- Fewer false alarms and calmer on-call engineers (30.6).
- Confidence to ship: you can see whether a release made things worse and roll back quickly.
- Capacity and cost insight: what's busy, what's idle.
Memory code: "Plug in the reader before you open the engine."