Observability
Observability is the ability to understand what's happening inside a system by examining what it outputs — metrics, logs, and traces — well enough to answer questions you didn't know you'd need to ask when you built it.
Observability is usually explained through its three data types. Metrics are numbers over time (CPU usage, request count, error rate) — cheap to store, good for dashboards and alerting on known problems. Logs are timestamped, discrete events — good for reconstructing exactly what happened during a specific incident. Traces follow a single request as it moves through multiple services — essential once an app is broken into microservices, because a slow request might touch six different services and only a trace shows you which one was actually slow.
The difference from traditional monitoring is what question you can answer. Monitoring is built around dashboards for problems you anticipated — “alert me if CPU goes above 80%.” Observability is built for problems you didn’t anticipate — when something breaks in a way nobody wrote a dashboard for, can you still ask a new question of the system’s data and get an answer, without shipping new code first?
OpenTelemetry has become the standard way to instrument applications so this data isn’t locked into one vendor’s format — you emit metrics, logs, and traces in a shared format, and route them wherever you want, including switching backends later without re-instrumenting the whole codebase.
Related reading