Observability Basics
A system you cannot see inside is a system you cannot operate. Metrics, traces, and logs answer three different questions, and averages will lie to you about all of them.
Prerequisites: A service in production, or the intention of having one.
After this: Say how you would know the system is broken, in percentiles, before the interviewer asks.
Suggested first pass: Read sections 1–5, answer each section in your own words, then use the remaining failure modes and exercises as the advanced pass.
| Answers | Cost | Fails at | |
|---|---|---|---|
| Metrics | Is something wrong? | cheap | Why. Detail is aggregated away |
| Traces | Where did the time go? | moderate, sampled | Per-request detail |
| Logs | What happened to this request? | expensive at volume | Finding the right lines |
Metrics are numbers over time: request rate, error rate, latency, queue depth. Easy to graph and alert on. Logs are individual events with detail. Traces follow one request across every service it touches, with timing per hop.
The workflow runs in that order. Metrics alert you, traces localise the problem, logs explain it. A design that mentions all three in that order sounds like someone who has been on call.