OpenTelemetry — Observability Primer

OpenTelemetry’s first-party conceptual definition of observability, ingested to give the observability page a canonical definitional source (distinct from the opentelemetry tool page).

Citable claims

• Definition: observability “lets you understand a system from the outside by letting you ask questions about that system without knowing its inner workings” — and troubleshoot novel problems (the “unknown unknowns”), answering “why is this happening?” without prior knowledge of the internals.
• Telemetry is “data emitted from a system and its behavior,” in three primary signals: traces (how a request propagates across a distributed system), metrics (aggregated numbers over time — error rate, CPU), and logs (timestamped messages, usually not request-scoped).
• Instrumentation: code must emit signals; the bar is met when “developers don’t need to add more instrumentation to troubleshoot an issue, because they have all of the information they need.”
• The framing implicitly contrasts observability vs. monitoring: monitoring watches predefined metrics/dashboards (known failure modes), while observability supports open-ended questions for unanticipated ones.

Tier

T1 — first-party (OpenTelemetry/CNCF). Definitional, not a dated snapshot.

Related

observability · opentelemetry · distributed-tracing · platform-ops