Concept and mechanism
A trace groups spans describing related operations. Context propagation preserves relationships across services; trace IDs and span IDs help correlate logs when those fields are actually recorded. If an application receives a request and always creates a new root without extracting context, the operation can appear fragmented. Similar timestamps do not prove causality, especially with concurrency and different clocks. In asynchronous processing, relationships may require span links depending on the execution model and instrumentation. Do not force every queue operation into a simplistic parent-child tree when several producers or batch processing are involved. State which components were instrumented and which remain outside visibility.
Guided application
Head sampling decides early, before final duration or a later error is necessarily known. Tail sampling can use information received later, but needs state, capacity, and suitable routing. It cannot recover spans already dropped upstream. In a fictional incident, a missing trace does not prove the request never existed: compare sampling, export losses, and application records. Check the boundary where context disappears before indiscriminately increasing collection. A trace without a recorded error is also not confirmation of business outcome. Accept the service using expected operations and data. During handover, document coverage, sampling policy, and search limitations so L3 engineers know what they can infer.
An operation crosses three services, but lost context in the second creates separate traces.
Common pitfalls
Timestamp as causality; absence as nonexistence; tail sampling as recovery of discarded data.
Related topics: Signals and service outcomes · Metrics and queries · Instrumentation and protection
Interpret traces using context and collection limits.
Reference: Context propagation and correlation · Observability 2026-09; selected OpenTelemetry, Prometheus and Dynatrace Classic concepts