Exemplar
A trace identifier attached to a metric data point, linking an aggregate measurement directly to a concrete request that produced it.
The recurring frustration in observability is the gap between signals. A dashboard shows p99 latency rising, and the next question is always "show me one of those slow requests" — which normally means manually searching traces by time window and hoping to find one, and the interesting ones may have been sampled away.
An exemplar closes the gap by attaching a trace ID to the metric sample. Clicking the spike on the latency histogram opens an actual trace of a request in that bucket, with its full span breakdown.
The implementation detail that makes it powerful is the interaction with sampling: exemplar-carrying traces should be retained regardless of the sampling decision, since they are by construction the ones a human is likely to want. This is one of the cleanest ways to make sampled tracing feel complete.
The broader principle it illustrates is worth stating: the value of observability comes from the links between signals, not from the signals individually. A metric tells you something is wrong, a trace tells you where, and logs tell you why — and moving between them should be one click rather than a manual correlation exercise performed under pressure. Consistent identifiers across all three, propagated through every service, are what make that possible, and they must be in place before the incident.