Observability
Understanding a system’s internal state from its outputs — logs, metrics, and traces — especially for problems you did not predict.
Observability is how well you can understand what a system is doing from the outside, using its outputs — the three pillars are logs (discrete events), metrics (aggregated numbers over time), and traces (the path of a request across services). The goal is answering questions you did not know to ask in advance.
Worked example: a latency spike sends you to a dashboard (metric), you find the slow endpoint, open a distributed trace to see which downstream call is slow, then read that service’s logs for the error — three pillars, one investigation. Gotcha: observability differs from monitoring — monitoring watches known failure modes (is CPU high?), observability lets you debug UNKNOWN ones — and high-cardinality data (per-user, per-request tags) is what makes it powerful but also expensive to store and query.