Quiz: OpenTelemetry

← Back to quiz index

3 questions

L0 (1 questions)

1. What problem does OpenTelemetry solve, and what are the three telemetry signals it unifies?

Show answer

OTel solves observability fragmentation — instead of separate agents, config languages, and SDKs for each telemetry type, OTel provides a single vendor-neutral standard. The three signals are traces (request journey across services, composed of spans), metrics (counters, gauges, histograms), and logs (structured events with severity and trace context). Instrument once, route to any backend.

L1 (1 questions)

1. What are the three components of an OTel Collector pipeline, and in what order do they execute?

Show answer

Receivers (ingest data from sources like OTLP, Prometheus scrape, or filelog), Processors (transform data in flight — batch, filter, tail sample, memory limit), and Exporters (send data to backends like Tempo, Prometheus, Jaeger, Loki). They execute in order: receivers -> processors -> exporters. Each signal type (traces, metrics, logs) has its own pipeline definition.

L2 (1 questions)

1. What is the difference between head sampling and tail sampling in OpenTelemetry, and when would you use each?

Show answer

Head sampling decides at trace creation whether to sample (e.g., sample 10% of all traces). It is simple and low overhead but may drop interesting traces. Tail sampling decides after the trace completes, based on its content — keeping all errors, all slow requests, plus a percentage baseline. Tail sampling requires the collector to buffer complete traces (costs memory) but preserves the most valuable signals. Use head sampling for low-overhead environments; tail sampling for production observability.