Observability is how well you can answer "what is wrong and why?" from the outside, using the data a system emits. That data comes in three kinds, often called the three pillars:
| Signal | What it is | Good for |
|---|---|---|
| Metrics | Numbers sampled over time (request count, CPU %, latency) | Dashboards, alerts, trends. Cheap to store. |
| Logs | Timestamped text or JSON records of single events | The details of one error: stack trace, user id, input |
| Traces | The path of one request across services, split into timed spans | Finding which service in a chain is slow |
A typical debugging flow uses all three: an alert on a metric says the error rate jumped, a trace shows the slow or failing hop is the payment service, and that service's logs show the exact exception.
Monitoring vs observability. Monitoring watches for failures you predicted ("alert if disk > 90%"). Observability lets you investigate failures you did not predict, by slicing the data in new ways.
The four golden signals (from Google's SRE book) are what to measure first for any service: latency, traffic, errors, saturation.
The classic trap: putting high-detail data like user ids into metric labels. Each unique label value creates a new time series and can overload the metrics store. Put that detail in logs or traces instead.
In interviews: "What is the difference between metrics, logs and traces?" Give one line each and one example of when you would reach for it.