Observability Basics
System Design: lesson 15 of 15
Metrics say something broke; traces say where.
Lesson 15 of 15 · 5 min
Observability Basics
Step 1 of 13
Metrics are cheap numbers over time: request rate, error rate, latency percentiles.
The Idea
Metrics are cheap numbers over time — request rate, error rate, latency percentiles — ideal for alerting and useless for detail. Logs record individual events with context, and get expensive at volume. A trace follows one request across every service it touched, which is the only view that finds the slow hop.
Real-World Example
A bus control room runs all three. The wall board shows headway and punctuality; each vehicle's fault log explains one breakdown; and when a complaint lands, somebody follows that single journey through every depot handover to see where the twelve minutes went.
The Tradeoff
All three cost money and attention, and a dashboard nobody reads is worse than none. Watch percentiles rather than averages, keep metric labels low-cardinality — a label per user ID will bankrupt you — and sample traces instead of recording every single request.
Your turn
Put the steps in the right order.
- Open the trace of a slow request to see which hop cost the time
- An alert fires when the error-rate metric crosses its threshold
- Read that one service's logs around the failing requests
- Check the dashboard to see which service the errors come from
Mini quiz
1 / 3