OpenTelemetry (OTel) is a CNCF-graduated, vendor-neutral observability framework that standardizes the generation, collection, and export of telemetry signals — traces, metrics, logs, and profiles — across any language, infrastructure, or runtime. It emerged in 2019 from the merger of OpenCensus and OpenTracing, and its single most powerful property is vendor lock-in elimination: instrument once with OTel APIs and route telemetry to any compatible backend. The key mental model to carry through the tables is the pipeline: SDK (instrument) → OTLP (transport) → Collector (process/route) → Backend (store/visualize) — every concept in this cheat sheet fits somewhere in that chain.
What This Cheat Sheet Covers
This topic spans 18 focused tables and 128 indexed concepts, 117 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 Signals
OpenTelemetry defines four canonical telemetry signals that together give a complete picture of system health. Understanding when each signal answers a different question — what happened (traces), how much / how often (metrics), why it happened (logs), where time was spent (profiles) — is foundational before learning any other OTel concept.
| Signal | Example | Description | |
|---|---|---|---|
trace_id: 7bba9f33312b3dbbspans: [GET /api, db.query, cache.get] | • A directed acyclic graph of spans representing end-to-end request flow across services • each span has a start/end time, status, attributes, and events | ||
http.server.request.duration{service="api"} histogram | • Numeric time-series measurements aggregated over time windows • efficiently quantify throughput, latency percentiles, error rates, and resource saturation at low storage cost | ||
{"severity":"ERROR","trace_id":"7bba...","body":"DB timeout"} | • Timestamped, structured or unstructured text records with optional trace/span correlation • OTel enriches existing logs rather than replacing them | ||
otelcol-ebpf-profiler --config profiler.yaml | • Continuous CPU/memory stack-trace samples enabling code-level performance analysis • entered public Alpha in March 2026 as OTel's fourth signal | ||
Baggage: userId=alice,region=us-east | • Key-value metadata propagated in-band with every request • not stored as telemetry itself but carried via HTTP headers to enrich downstream spans |