Correlating logs, metrics, and traces

WHAT THIS TESTS Whether you know that the three signals only become a debugging workflow when they share a correlating identifier, and that the essential piece is the trace ID propagated via context.

A GOOD ANSWER COVERS The key is a unique trace ID, often paired with span IDs, created at the edge when a request enters the system and propagated to every downstream service and asynchronous task through context propagation, typically W3C Trace Context headers. To correlate, you ensure three things: structured logs include the trace_id and span_id fields; metrics attach exemplars, which are sample data points that carry a trace ID for a representative observation; and traces naturally carry the ID as their identity. The debugging flow then becomes a pivot. You start from a metric, say an elevated 5xx rate or a latency spike, click the exemplar to open the offending trace, inspect the span tree to find which service and operation failed, and from that span jump directly to the log lines with the same trace ID for the root-cause detail and stack trace.

COMMON WRONG ANSWERS Saying you correlate purely by timestamp and service name; under concurrency many requests share a timestamp, so this is ambiguous. Forgetting that context must propagate across async boundaries and process hops, not just within one service. Omitting structured logging, which makes the trace ID unsearchable.

LIKELY FOLLOW-UPS What are exemplars and how do they bridge metrics and traces? How does context propagate across queues and threads? Why structured logs?

ONE CONCRETE EXAMPLE An alert fires on checkout error rate. The engineer opens the metric panel, clicks an exemplar dot, and lands on trace abc123. The trace shows the payment span errored. Clicking through, they query logs for trace_id=abc123 and find a downstream timeout with a stack trace, pinpointing the cause in minutes instead of grepping logs by time.