Checklist
Trace the request by identity, not by nearby timestamps
Two messages appearing at 10:03 do not necessarily belong to the same story.
When it fits
- Logs from multiple services need to be connected to one operation.
When to avoid it
- A shared identifier can be misused or reused incorrectly. A trace shows what was instrumented, not a guaranteed complete history.
Checklist
- Identify the initiating operation and its correlation identifier.
- Follow the identifier or explicit causal link through each boundary.
- Mark missing instrumentation and avoid copying sensitive payloads into a tracing field.
Why it matters
Use propagated request or trace identifiers to connect work across services. Preserve parent or causal links when asynchronous processing starts a separate trace. Timestamps help order observations, but proximity alone cannot establish that one message caused another.
An example
A queue consumer starts minutes after the sender finishes. The recorded causal link, not clock proximity, connects their attempts.
Check your result
Each claimed connection has an identifier or documented linking rule; gaps remain visible.
Keep this limit in mind
- A shared identifier can be misused or reused incorrectly. A trace shows what was instrumented, not a guaranteed complete history.
Connected ideas
Useful withFind the first boundary where the record becomes wrong
Evidence and sources
Supports
OpenTelemetry uses propagated trace context and span links to associate work across synchronous and asynchronous boundaries.
Recorded links describe instrumented relationships, not necessarily the complete system history.
Traces · Context Propagation; Span Links