Observability / Basic: signals and measurement meaning / Lesson 4

Traces, spans, and propagated context

Read a trace as related timed operations, distinguish parentage from wall-clock nesting, and preserve context safely across process boundaries.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Explain trace and span identity.
Interpret duration without summing overlapping spans.
Review propagation and untrusted context boundaries.

A trace relates work rather than every event

A span represents a timed operation with a name, identity, timing, attributes, events, and relationships as supported by the tracing model. Related spans share a trace identifier, while each span has its own span identifier. For parcel tracking, a server operation can relate to a client storage call and an internal rendering step. A span is not automatically one network packet, one thread, or one log line. Instrument meaningful boundaries so a reader can understand the operation. Excessive tiny spans add cost and visual noise without necessarily explaining where useful work or waiting occurred.

Carry context at the actual boundary

Context propagation lets one operation relate to work in another process or execution boundary. HTTP propagation commonly uses the W3C Trace Context format; SDK and framework integration determines where context is extracted and injected. The illustrative header uses syntactically shaped synthetic identifiers only. Do not treat an incoming trace ID as authentication or authorization. Validate context through the platform’s supported propagator, and decide how trust boundaries affect baggage and sampling inputs. A request can carry context even when some spans are not recorded, so record absence must not be confused with propagation absence.

text Synthetic W3C trace context header

traceparent: 00-11111111111111111111111111111111-2222222222222222-01

The fields represent version, trace ID, parent span ID, and flags. The example is non-runnable and does not authenticate a caller or contact an endpoint.

Read overlap before adding durations

Parallel child spans can overlap, so summing their durations can exceed the parent duration without a defect. In the offline example a parent lasts one hundred milliseconds and two parallel children each last sixty; the sum is one hundred twenty. That does not mean the request took one hundred twenty milliseconds. Exclusive-time calculations require interval union and careful assumptions about what was instrumented. Cross-process clocks can also distort apparent placement. Use the trace to identify a promising boundary for investigation, then compare population evidence before generalizing from one operation.

python Offline overlapping-span model

parent_start, parent_end = 0, 100
children = [(10, 70), (30, 90)]
print("parent_ms", parent_end - parent_start)
print("summed_child_ms", sum(end - start for start, end in children))
print("children_overlap_ms", min(70, 90) - max(10, 30))

Expected output

parent_ms 100
summed_child_ms 120
children_overlap_ms 40

The two synthetic child intervals overlap for 40 ms. Their sum is not the request’s elapsed duration and is not a measured trace.

Separate topology from causal proof

A long client span may include connection acquisition, retries, network travel, and downstream execution depending on instrumentation. Its name alone cannot prove a database engine is slow. A missing child can result from missing instrumentation, propagation loss, sampling, export loss, or backend filtering. Check those possibilities before declaring that a dependency was never called. Trace status and recorded exceptions follow instrumentation semantics and do not replace the business outcome definition. Pair trace evidence with counts, distributions, and safe event context to understand how common the observed path is.

Choose safe attributes and meaningful names

Use bounded operation names such as a route template rather than a raw URL containing a parcel identifier. Avoid placing credentials or personal details in span attributes, events, or baggage. Record service and deployment context consistently so cross-service navigation remains possible. Review async and batch boundaries separately because a single parent may not express all relationships. This lesson models intervals and shows a header only: it does not instantiate an SDK, send telemetry, inspect a real trace, or verify framework-specific context propagation. Those claims require separate authorized integration evidence.

Common errors and fixes

Child durations sum above the request duration

Why it happens: Parallel intervals were added as sequential work.
How to fix it: Inspect overlap and elapsed boundaries.
Prevent it next time: Teach interval semantics with a small trace fixture.

A missing span proves the call never happened

Why it happens: Sampling, instrumentation, and export loss were ignored.
How to fix it: Trace the recording path and compare independent evidence.
Prevent it next time: Document coverage and sampling policy.

A trace identifier grants access

Why it happens: Correlation context was confused with identity trust.
How to fix it: Use proper authentication and validate propagated context.
Prevent it next time: Review trust boundaries and baggage allowlists.

Check your understanding

1. A parent lasts 200 ms and two children last 150 ms each. Is the trace impossible?

Show worked solution

No. The children may overlap, and the sum of child durations does not equal wall-clock request time. Inspect their intervals, relationships, and clock sources. If a child appears outside an expected boundary, investigate instrumentation and timing semantics before assuming corruption.

2. A downstream service starts a new trace for every incoming call. What should you inspect?