Lesson 1 of 15
30. Observability

The picture to keep in your head

3 min read+10 XP

Every question below is answered twice: first in the car, so you can picture it, then in the system, so you know exactly how it works. Each answer ends with a memory code to lock it in.

The picture to keep in your head

You're driving on the highway. The dashboard shows your speed, fuel and engine temperature at a glance. The car keeps a trip log: every hard brake, every warning, with the time. Your phone's maps can replay the route, showing exactly where you lost twenty minutes (a toll queue, not the traffic). The service book makes a promise: "service every 10,000 km". And the warning lights stay dark unless something actually needs you: no light for "the radio is slightly loud", but a red one for "oil pressure low, stop now".

When the car starts making a strange noise, you don't guess. You look at the gauges, check the log, replay the route, and narrow it down.

That's observability: being able to tell, from the outside, what's happening inside your system, and why.

Our running example: the bookstore's checkout during the Big Book Sale. Customers say "checkout is slow". Is it? For whom? Since when? Why? And should anyone have been woken up? Traffic and latency numbers are assumptions for practice.

In the carIn the system
Knowing what's wrong without opening the bonnetWhy observability
The trip logLogs
The gaugesMetrics
The route replayTraces
Speed, fuel, temperature: the few that matterGolden signals, RED and USE
"Service every 10,000 km"SLI, SLO, SLA
How many km of slack before the next serviceError budgets
Warning lights that only light for real problemsAlerting without noise
The dashboard layoutDashboards
Strange noise → gauges → log → replay → fixDebugging an incident

the trip log, gauges, route replay, service promise and warning lights mapped to logs, metrics, traces, SLOs and alerts.

Figure: you can't fix what you can't see; watch what the driver feels, and keep the logbook.