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. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
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 |