Lesson 10 of 15
30. Observability

Memory card and where the analogy breaks

3 min read+10 XP

The memory card (tear this page out)

#QuestionMemory code
30.1Why observability?Plug in the reader before you open the engine
30.2Three pillars (logs, metrics, traces)?The log says what, the gauges say how much, the replay says where
30.3Golden signals, RED, USE?Speed, fuel, temperature, warnings: watch the few that tell you most
30.4SLI, SLO, SLA?Measure the kilometres, promise the service interval, sign the warranty looser
30.5Error budgets?The slack before the next service is yours to spend, but watch how fast you're spending it
30.6Alerting without noise?A warning light should mean "stop now", never "speed bump"
30.7Dashboards?Speedometer in front, trip computer one press away
30.8Debugging an incident?Pull over, read the gauges, find what changed, replay the trip, then fix and write it down

The whole chapter in one line: Emit structured logs, metrics and traces linked by a trace ID, watch percentiles of what users feel, set SLOs with error budgets, page only on fast budget burn, and in an incident mitigate first, then break down by dimension and follow one bad request.

Where the analogy breaks

  • A car has one driver and one engine. A request may cross twenty services, which is why traces need a shared ID passed along every call.
  • Car gauges are free. Telemetry costs money, and logs especially can cost more than the servers they describe, so sample and choose.
  • A car's warning lights are designed once at the factory. Alerts are yours to design, and bad ones get ignored until the day they matter.

Quick check

Five questions on this chapter. Pick an answer, then check it.

quiz