Observability

Observability is the property of being able to ask questions about your system's behavior — including questions you didn't anticipate when you built it — and get answers from data the system already emits. Monitoring is checking known unknowns. Observability is being equipped to investigate unknown unknowns.

The goal is not "more telemetry." It's useful telemetry: the right signals, at the right cardinality, with the right context, retained for the right window, surfaced where humans look.

The three pillars (and the limits of that framing)

Metrics, logs, and traces are the standard taxonomy. Each is good at something:

• Metrics — cheap to store, fast to query, good for trends and SLOs and alerting. Bad at "why is this specific request slow?"
• Logs — high-fidelity per-event detail, expensive at scale, the place you go when metrics tell you something is wrong and you need to know what.
• Traces — the causal graph of a single request across services. Indispensable for distributed systems; the answer to "where did the time go?"

The pillars are not mutually exclusive — a modern stack correlates them. A trace ID in every log line lets you jump from a metric anomaly to the slow trace to the exact log lines. Wide structured events (the Honeycomb model) collapse logs and traces into a single high-cardinality store and are arguably the most useful primitive of the three; if you're starting fresh, give that model a serious look.

OpenTelemetry is the default

Pick OpenTelemetry (OTel) for instrumentation. It's the vendor-neutral standard, supported everywhere, and saves you from per-vendor SDKs that go obsolete.