Observability & Reliability
You can't operate what you can't see — logs, metrics, traces, and SLOs.
By the end of this lesson, instrument the three pillars and use SLOs and error budgets to manage reliability.
Observability is the ability to understand a system's internal state from its outputs — to answer new questions about production without shipping new code. In a distributed system where you can't attach a debugger, it's the difference between diagnosing an incident in minutes and guessing for hours.
First, see the whole system. Then we’ll open it up.
The three pillars
- Logs record discrete events, metrics record aggregates over time, and traces follow a single request across services; together they let you alert, diagnose, and improve.
flowchart LR logs[Logs: discrete events, what happened] --> obs[Observability] metrics[Metrics: aggregates, how much/how fast] --> obs traces[Traces: one request across services] --> obs obs --> act[Alert, diagnose, improve]
Logs tell you what happened; metrics tell you how much and how fast (and drive alerts); distributed traces follow one request across service boundaries so you can see where latency and errors originate. OpenTelemetry standardizes how all three are produced. Correlate them with request/trace IDs so you can pivot from a metric spike to the exact traces and logs behind it.
What does a distributed trace show that logs and metrics don't?
The path and timing of a single request as it crosses multiple services, revealing exactly where latency or errors originate.