The Disconnect
You are looking at a dashboard. Your P99 latency graph has spiked from 200ms to 2 seconds. Something is clearly wrong. You know what is happening (a metric tells you that). You need to know why. That answer lives in a distributed trace.
But which trace? In a system handling 10,000 requests per second, there are thousands of traces in any given second. Finding the one that caused the spike means:
- Noting the exact timestamp of the spike from the graph.
- Switching to your tracing tool (Jaeger, Tempo, Zipkin).
- Filtering for traces with duration > 2s in that time window.
- Manually reviewing results and hoping one of them is representative of the problem.
This is slow, error-prone, and requires context-switching between tools. In an incident, every minute of this costs you.
The Root Cause of the Problem
Metrics and traces are fundamentally different data structures. A metric like http_request_duration_seconds_bucket{le="2.0"} 847 is an aggregate — it collapses thousands of individual requests into a single number. A trace is a specific event — it records the full lifecycle of one request. These two worlds don't naturally reference each other.
The result is an observability gap: you can see that something is wrong in your metrics, and you can investigate why in your traces, but there is no direct path between them. You have to bridge the gap manually, under pressure, during an outage.
The Solution: Exemplars
Exemplars close this gap by embedding a specific Trace ID directly into the metric data point. Instead of just incrementing a counter or histogram bucket, the instrumentation also records: "the request that caused this increment had Trace ID abc-123."
When you look at the latency graph, you don't just see a line. You see dots — called exemplars — overlaid on the graph, each representing a real request. You click the dot at the peak of the spike, and your observability platform takes you directly to that trace. No searching. No guessing. One click from symptom to root cause.