Choose OpenTelemetry sampling from when the decision must be made

Head sampling does not inspect the whole trace; tail sampling can select traces using error or latency criteria.

Source facts

OpenTelemetry head sampling decides as early as possible without examining the whole trace. Tail sampling considers all or most spans. It can use criteria such as errors or overall latency. Head and tail sampling can be combined, with head sampling first retaining a small percentage and tail sampling making later decisions.

Source: OpenTelemetry documentation — Sampling.

Applicability

Review trace-sampling timing, selection criteria and combined head/tail processing in the OpenTelemetry guide.

DSE recommendation

DSE recommends defining which investigations must retain complete traces before selecting a sampling policy. Separate cost reduction from the requirement to observe rare errors or slow operations. Document what an early drop means for later analysis, and keep all necessary spans together for tail-based decisions. Monitor sampling and export behavior so an unexpectedly low trace count is not automatically attributed to the application. Keep metrics for overall request volume separate from the retained trace sample where the operational question needs population-level counts.

Verification

In a test application, produce normal, slow, and late-error traces and inspect which are retained under the intended policy. Confirm distributed spans reach the required processing stage. Compare observed retention with the written selection criteria and document the information intentionally lost. Retain the expected trace selection table and the actual retained trace identifiers. Have the application owner identify the late-error case and confirm the chosen policy supplies the investigation context that justified it.

Official reference

OpenTelemetry documentation — Sampling. Reviewed October 20, 2026.