A latency histogram tells you p99 jumped. An exemplar tells you which trace produced that outlier point, without a separate search.

Staring at a spike on a latency histogram and then manually searching traces for one that roughly matches the timestamp is slow and imprecise, especially on a service handling thousands of requests per second. Exemplars attach an actual trace ID to individual histogram buckets, so the spike points directly at the request that caused it.

1. Enable exemplar recording on the histogram

By default the SDK records histogram buckets without exemplars, since storing a trace reference per bucket costs slightly more overhead. Turn it on explicitly for the metrics worth this level of detail.

const durationHistogram = meter.createHistogram('checkout.request_duration', {
  recordExemplars: true,
  exemplarReservoirSize: 10,
});

2. Query the histogram with exemplars attached

Exemplars ride along with the metric data itself, retrievable in the same query rather than a separate call.

from metrics
| where metric.name == "checkout.request_duration"
| where bucket_le >= 1s
| project timestamp, value, exemplar.trace_id

3. Jump straight from chart to trace

In the Helix UI, any histogram panel built with exemplar-enabled data shows small markers on outlier points. Clicking one opens the exact trace behind that data point directly, no copying a trace ID between tabs, no guessing which request in a time window matches the spike.

4. Reserve it for the metrics that page

Exemplar recording adds a small amount of memory overhead per histogram, and turning it on for every metric in a large service is unnecessary. Enable it specifically for the handful of latency and error-rate metrics that already have alerts attached, those are the ones someone will actually click through during an incident.

An exemplar is not a replacement for tracing, it is a bookmark. It only works because full tracing was already in place to bookmark into.

Teams that adopt exemplars usually notice the same pattern within the first week: the outlier points on a histogram are rarely random. A cluster of exemplars pointing at the same slow downstream call, or the same customer account with an unusually large cart, turns a vague latency spike into a specific, fixable cause far faster than paging through raw traces in the hope of stumbling onto the right one.

  • Turn on exemplar recording explicitly, it is off by default for overhead reasons.
  • Query exemplar.trace_id alongside the metric to pull the backing trace directly.
  • Use the chart-to-trace click-through in the UI instead of manual timestamp matching.
  • Limit exemplar recording to metrics with alerts attached, not every histogram in the service.