A span records one unit of work within a distributed trace. It identifies an operation, service, timing, status, parent relationship, and instrumentation details. section 12.1.1 section 12.1.2
Spans let you reconstruct a request as it crosses services, compare time spent in each operation, locate missing steps, and distinguish local failures from communication problems. section 12.1.1 section 12.4
Read spans by asking focused diagnostic questions:
- Which service and operation created the span, and how long did it run? section 12.1.1
- Does the span appear under the expected parent, or does the trace tree contain a missing step? section 12.1.1
- Do repeated child spans reveal a retry storm, especially when internal traffic rises without more user traffic? section 12.3.2
- Does a client span end in timeout while the server span continues successfully? section 12.3.3
Finding a timeout mismatch
A trace shows a frontend call ending at 2,000 ms with an error while the OrderService span continues to 3,000 ms. The caller timed out, but the downstream service kept processing. Compare client and server timeout settings before treating the symptom as a server failure. section 12.3.3
Following a missing order
A checkout trace can show validation, the OrderService call, database work, Kafka publication, and confirmation email as separate spans. If the Kafka publication or downstream processing is absent or fails, the trace narrows the investigation.
