What is Observability?

Observability is about answering "why is this happening?" for problems nobody predicted. Instead of guessing from the outside, an engineer queries the data the system produces about itself, which helps with behavior that is difficult to reproduce locally. The OpenTelemetry primer calls that data telemetry and names three main kinds of signal: traces, metrics and logs.

A trace follows a single request as it moves through services. Metrics are numeric values aggregated over time, such as error rate or request rate. Logs are timestamped messages, which are useful but often lack context unless they are tied to a trace and span. Making code produce these signals is called instrumentation, and the primer says a system is properly instrumented when its existing data is enough to diagnose a problem without adding more.

The primer also separates reliability from uptime. A service can be running all the time and still fail to do what users expect, so teams express reliability with service level indicators, which measure behavior from the user's point of view, and service level objectives, which attach those measurements to business value.

The main caveat the page gives is that observability depends on instrumentation. If the right signals are never emitted, the questions that matter cannot be asked later. Logs on their own are not enough to track code execution, because they usually lack context such as where they were called from.