Start from zero: what observability actually is
Observability is the ability to ask "what is my running system doing and why" from the outside. This is the from-zero map and the eight words the rest of the track assumes you already know.
Your service is live. Users are hitting it. Then someone on Slack says: “checkout is broken.” You open a terminal and stare. You cannot step through the code in a debugger — it is running on three servers at once, handling hundreds of requests a second, and the failure happened 90 seconds ago. All you have is what the system chose to record about itself. If it recorded the right things in the right shape, you can answer “what happened and why” in minutes. If it did not, you are guessing in the dark. Observability is the discipline of making systems legible from the outside — and this lesson is the vocabulary you need before the real work starts.
The one problem observability solves
When code runs on your laptop you can attach a debugger, add print statements, and watch every variable change. In production you cannot. The program is on machines you do not control, handling many requests concurrently, and the moment you care about has already passed. You are permanently on the outside. Observability is the engineering discipline that makes “outside” good enough: the system continuously records signals about itself — numbers, text, causal chains — and you query those signals to understand behaviour you never directly observed. Get it right and a five-minute incident becomes a ten-minute post-mortem. Get it wrong and every outage becomes archaeology.
The goal is not to log everything; it is to emit the signals that let you answer questions you have not thought of yet.
The eight words the rest of the track assumes
The senior lessons that follow drop these terms without stopping to define them. Here they are, one sentence each — what it is and why it exists.
| Word | What it is | Why it exists |
|---|---|---|
| Telemetry | Data your code emits about its own behaviour — the umbrella term for metrics, logs, and traces. | So you have raw material to query when something goes wrong. |
| Metric | A number sampled over time — request rate, error count, memory used. | So you can see trends, set thresholds, and know when something crosses a line. |
| Log | A timestamped text record of one event — “user 42 checked out, order 99 created.” | So you can read the story of a specific moment in detail. |
| Trace | The full journey of one request across every service it touched, stitched together. | So you can see where time was spent and which service caused a slowdown. |
| Span | One timed unit of work inside a trace — a single database query, a single HTTP call. | So a trace can be a tree of spans, each with its own timing and attributes. |
| Dashboard | A screen of charts that display metrics over time in one place. | So your team can glance at system health without running queries manually. |
| Alert | A rule that fires a notification when a metric crosses a threshold. | So humans are paged automatically when the system needs attention. |
| Cardinality | The number of unique values a label on a metric can take — e.g. one per user ID is very high cardinality. | So you understand why some metrics are cheap and others explode your storage bill. |
How they fit together
Read in order, the words tell one story: your code continuously emits telemetry — a stream of metrics, logs, and traces. Metrics are aggregated numbers; a dashboard plots them over time so your team sees health at a glance, and alerts fire when a metric crosses a line so nobody has to watch charts manually. Logs are the fine-grained narrative: when a metric alarm fires, you look at the logs for that moment to read exactly what happened. Traces stitch the logs from many services into the story of one request — each hop is a span — so you can see which service added latency or threw an error. Cardinality is the hidden cost: the more unique label combinations a metric has, the more storage and query time it demands. That single paragraph is the entire track in miniature — every later unit zooms into one of those pieces.
▸Why this works
Why not just SSH in and check things by hand? Because by the time you SSH in, the problem may be gone — and you have no record of what the system was doing when it failed. Pre-emitted telemetry is the only evidence you can query after the fact. More: a system under load handles hundreds of requests per second across many servers. No human can watch that in real time. Observability turns “watch it live” into “query the record” — which scales infinitely and works on incidents that happened last Tuesday.
You see an alert that error rate crossed 5 %. Which signal do you reach for next to understand what happened?
Order the investigation steps when an alert fires on your service:
- 1 Alert fires — a metric crossed the threshold you configured
- 2 Open the dashboard to see which metric changed and when
- 3 Read logs for that time window to find the specific failing events
- 4 Open a trace for a failing request to see which service or span caused it
- 01In one breath: what is observability, and how do its three signal types divide the work?
- 02What is cardinality and why does it matter for metrics?
Observability is one idea with a lot of machinery hung off it: make your system legible from the outside by having it continuously emit data about itself, so you can answer questions about its behaviour after the fact. The three signal types divide the work by granularity. Metrics are numbers sampled over time — cheap, aggregate, good for dashboards and alerts. Logs are per-event text records — detailed, expensive at scale, the right tool for reading the story of a specific moment. Traces follow one request across every service it touched, with each hop as a span — the right tool for understanding latency and causality across service boundaries. Cardinality is the hidden cost that determines how expensive a metric is to store. You do not need to hold all eight words at once — each gets its own unit ahead. Now when you see an alert fire, you know which signal to reach for next: metrics to confirm the shape, logs to read what happened, traces to find where across services it broke.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.