Trace Correlation IDs
Trace correlation IDs give each request a unique ID that every log, metric, and span carries, so a single failed request is found across every store by one ID without manual join.
Definition
Trace correlation IDs are a unique identifier assigned to each request at the edge and propagated to every log line, metric label, and span attribute, so that a single failed request can be located in every telemetry store by querying for one ID, collapsing the multi-store, multi-service diagnosis into a single filter.
Context and scope
Applied in distributed tracing, structured logging, and any system where a request touches multiple services and stores and diagnosis requires correlating across them.
Common misconceptions
- Correlation IDs are just trace IDs — a trace ID is one correlation ID; the value of a separate correlation ID is when tracing is not available or the log store cannot join to it
- Every request needs a new ID — idempotent retries should carry the original ID so the retry and the original are correlated
Anti-patterns
- Generating a new correlation ID at every hop, so the trace fragments cannot be joined
- Logging the correlation ID only on the request log and not on every downstream operation, so the ID is present at the start and missing where the failure happened
Related concepts
Authoritative source
What it is
Trace correlation IDs are a unique identifier assigned to each request at the edge and propagated to every log line, metric label, and span attribute, so that a single failed request can be located in every telemetry store by querying for one ID, collapsing the multi-store, multi-service diagnosis into a single filter. Applied in distributed tracing, structured logging, and any system where a request touches multiple services and stores and diagnosis requires correlating across them. The goal is not to collect all data but to be able to answer the question you did not think to ask in advance — which requires high-cardinality labels and exemplars that link traces to the metric that triggered them.
How it works
Three signals compose: metrics aggregate over time, traces preserve causality across boundaries, and logs carry the unstructured detail. Sampling is adaptive — head sampling for known-interesting paths, tail sampling to retain slow or error traces at a fixed budget. Cardinality is controlled at the source, not the query, because a high-cardinality label explodes storage and makes dashboards unusable.
When to invest and pitfalls
Invest when mean time to detect matters — in production, at scale, with paying users. The pitfall is instrumenting everything and alerting on nothing: dashboards full of lines that no one reads, alerts that fire on noise and are then muted, leaving the real outage undetected. Symptom-based alerts on user-visible degradation outperform cause-based alerts on internal thresholds.