Observability is the practice of instrumenting systems to measure their internal state through external outputs, enabling teams to understand and debug complex distributed systems. Unlike traditional monitoring which tracks predefined metrics, observability provides the ability to ask arbitrary questions about system behavior using logs, metrics, traces, and continuous profiles as core telemetry signals. The key difference lies in unknown-unknowns: monitoring answers questions you already know to ask, while observability helps you explore questions you didn't anticipate, particularly critical in microservices architectures where emergent behaviors and cascading failures are common. OpenTelemetry graduated as a CNCF project in May 2026, cementing its status as the de facto open standard for instrumentation — instrument once, ship to any backend, without vendor lock-in.
What This Cheat Sheet Covers
This topic spans 17 focused tables and 132 indexed concepts, 114 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
A jump-to index of every table row in this cheat sheet.
An interactive map of every table and concept in this topic.
Table 1: Core Observability Pillars
The four signals of observability each answer a different question: logs say what happened, metrics say how much, traces say where it went, and profiles say which code caused it. Understanding what each pillar does well — and where it falls short — prevents over-engineering the telemetry stack.
| Pillar | Example | Description | |
|---|---|---|---|
{"timestamp": "2026-05-28T10:30:00Z", "level": "ERROR", "service": "api", "message": "DB timeout", "trace_id": "abc123"} | • Discrete timestamped records of events with contextual details • essential for root cause analysis and debugging specific failure scenarios; most effective when structured (JSON) and correlated with traces via trace_id. | ||
http_requests_total{method="GET", status="200"} 15420 | • Numeric measurements aggregated over time tracking system health, performance trends, and resource utilization • optimized for efficient storage, alerting, and long-term trending. | ||
Trace ID: abc123 Span: API → DB (duration: 245ms) | • Causal chains of spans representing request flow across distributed services • reveals latency bottlenecks, dependency relationships, and failure propagation paths. | ||
CPU flame graph showing function-level resource consumption heap: function processCart() allocated 2.3 GB | • Always-on code-level performance analysis capturing CPU usage, memory allocation, and mutex contention in production • now standardized as the OTel Profiles signal (public alpha 2026); correlates directly to traces and metrics. | ||
Page load: 2.3s, Core Web Vitals: LCP 1.8s, INP 120ms | • Captures actual user experience metrics from real browsers including page load times, interactions, and JavaScript errors • reveals performance as users actually perceive it — not just server-side latency. |