5 exercises on sampling strategies — head-based, tail-based, reservoir sampling, and TraceID-based decisions.
0 / 5 completed
1 / 5
What is head-based sampling?
Head-based sampling: the decision (keep or drop) is made when the root span starts, typically by a random percentage. It is simple and low-overhead but cannot base decisions on what happens later in the trace — a slow or errored trace may be dropped.
2 / 5
What advantage does tail-based sampling offer over head-based?
Tail-based sampling: the collector buffers spans for each trace until the root span finishes. Only then does it apply rules — always keep traces with errors, latency > 2s, or specific user IDs. This ensures important traces are never dropped at the cost of buffer memory.
3 / 5
What is reservoir sampling used for in observability?
Reservoir sampling: with a reservoir of size k, each new trace has a k/n probability of replacing an existing sample. It guarantees a statistically representative sample from a stream of unknown size, useful for keeping a fair sample under a storage budget.
4 / 5
What does a sample rate of 0.01 (1%) mean in practice?
Sample rate 1%: for 1 million requests/minute, only 10,000 traces are exported — a manageable volume. When visualising rates or counts, observability tools multiply sampled values by the inverse (100×) to reconstruct accurate estimates.
5 / 5
How is a TraceID used in sampling decisions?
TraceID-based sampling: sampling on TraceID ensures that if a root span is sampled, all descendant spans in downstream services are also kept (since they share the TraceID). Without this, you get partial traces — some spans kept, others dropped — which are nearly useless for debugging.