OpenTelemetry
The vendor-neutral standard for telemetry, from the data model to the Collector. Learn the API and SDK, context propagation and the pipeline that ships your spans — and remember it with spaced repetition.
- flashcards
- 99
- flashcards
- per day
- ~10 min
- per day
- level
- Beginner → Intermediate
- level
- modules
- 5
- modules
What is OpenTelemetry?
OpenTelemetry is the CNCF standard for producing telemetry: one API, one family of SDKs and one wire protocol (OTLP) for traces, metrics and logs, so instrumentation stops being a per-vendor decision. It deliberately stops before storage — you still choose Prometheus, Jaeger, Grafana or a commercial backend — and that separation is what lets you change backend without touching instrumented code.
The split that matters most is API versus SDK: libraries depend on the API, which is stable and does nothing on its own, while the application installs an SDK and decides on samplers, processors and exporters. Around it sit the pieces that make telemetry comparable across services — Resources that describe the producer, semantic conventions that fix attribute names, and W3C trace context that carries a trace across every hop.
The Collector is the other half of a real deployment: receivers, processors, exporters and connectors wired into pipelines that batch, filter, enrich and route telemetry, running as an agent beside the workload or as a gateway fleet. This track then finishes where production actually gets hard — reading the Collector’s own metrics, reaching for zPages and the debug exporter, and recognising the shapes of lost data: a full queue, a stripped traceparent, a cardinality explosion.
Studying for the certification? The modules here follow the four OpenTelemetry Certified Associate domains and their weighting — nearly half of that exam is the API and SDK alone.
5 modules, seed to bloom
Each module is a set of flashcards — 99 in total. Answer, review, and watch your knowledge grow from seed to full bloom.
Fundamentals of Observability
Telemetry data, semantic conventions, instrumentation and analysis
15 cardsAPI & SDK: Data Model and Signals
Providers, spans, instruments, log records and context
23 cardsAPI & SDK: Pipelines, Configuration, Propagation, Agents
Processors, exporters, OTEL_ env vars, W3C headers and zero-code agents
24 cardsThe OpenTelemetry Collector
Configuration, pipelines, connectors, transforming data, deployment and scaling
21 cardsMaintaining and Debugging Observability Pipelines
Collector health, internal metrics, debugging tools and data loss
16 cardsSample questions
A taste of the real flashcards. Pick an answer, then reveal the explanation.
What does a Resource represent in OpenTelemetry, and how does it differ from span attributes?
- AThe entity producing telemetry — fixed for the process, unlike per-operation span attributes
- BThe backend that stores telemetry — chosen per exporter, unlike per-operation span attributes
- CThe host machine's hardware profile — detected at boot, unlike per-request span attributes
- DThe set of sampled spans kept in memory — pruned on export, unlike per-request span attributes
Which instrument should record request latency?
- AHistogram — it keeps a distribution so percentiles and bucket counts can be derived
- BGauge — it keeps the last observed latency so the current value is always known
- CCounter — it sums latencies so the backend can divide by request count for an average
- DUpDownCounter — it tracks latency going up and down as the load changes over time
Where should the batch processor sit relative to memory_limiter and any sampling or filtering processors?
- AAfter memory_limiter and after sampling or filtering — so it batches only data that will actually be exported
- BFirst in the pipeline — so that every later processor works on whole batches instead of single items
- CImmediately after the receiver but before memory_limiter — so the limiter measures complete batches
- DPosition does not matter — processors run concurrently and share one queue between them
A service’s spans never join the spans of the service it calls; each side starts its own trace. What is the usual cause?
- ATrace context is not reaching the callee — the header is missing, stripped or in another format
- BThe two services use different exporters — the backend cannot join spans sent by unlike exporters
- CThe two services sample at different ratios — the backend refuses to join traces of unequal ratios
- DThe two services use different SpanKinds — the backend joins only matching client and server kinds
Learn it once, keep it for good
Answer a question
Each card is one practical concept with multiple options. Pick what you think is right.
Get the full answer
See the correct option plus a clear explanation, and a link to deeper docs when one is available.
Review at the right time
A spaced-repetition engine (SM-2 or FSRS) resurfaces each card just before you would forget it.
Why OpenTelemetry is worth your time
Instrument once, switch backends
OpenTelemetry is vendor-neutral, so the instrumentation you write survives a change of observability vendor.
The ecosystem’s common denominator
Most observability backends now ingest OTLP directly, and the major language ecosystems ship OTel instrumentation.
Pipelines you can reason about
Knowing the Collector’s receivers, processors and exporters turns telemetry plumbing from guesswork into configuration.
Find lost telemetry with evidence
Internal metrics, zPages and the debug exporter show you where data disappeared instead of leaving you to guess.
Common questions
How is this different from the Observability track? +
The Observability track is a general course across metrics, logs, traces, Loki and Grafana. This one is OpenTelemetry end to end — the API and SDK, semantic conventions, context propagation and the Collector — at the depth the OTCA blueprint expects.
Do I need tracing experience first? +
No. The track starts from resources, signals and what OTLP is, then builds up to SDK pipelines and Collector configuration, so both beginners and engineers already emitting spans get something out of it.
Is it free? +
Yes, completely free. No registration or credit card is required, and all your progress is stored locally in your browser.
Will this prepare me for the OTCA exam? +
It follows the four published OTCA domains and their weighting, so the API and SDK material is the largest part, as it is on the paper. It is a recall companion rather than a full course — pair it with the official curriculum and hands-on time with an SDK and the Collector.
Ready to master OpenTelemetry?
Plant your first seed today. Ten minutes a day on the data model, the SDK and the Collector is all it takes to stop telemetry being magic.