Exemplars in the Broader Observability Picture

The Three Pillars, Connected

Observability is often described as having three pillars: Metrics, Logs, and Traces. In practice, these pillars are only useful if you can navigate between them. Exemplars are the first standardized mechanism for connecting two of these pillars — metrics and traces — with a direct, clickable link.

The same pattern is emerging for logs. Some observability platforms now support embedding Trace IDs in structured log lines, so you can jump from a log entry to its trace. Combined with Exemplars, this creates a fully navigable observability graph:

Metric spike → (Exemplar) → Specific Trace → (Trace ID in logs) → Log lines

When Exemplars Are Most Valuable

Exemplars provide the highest value in these scenarios:

• Latency percentile investigation: P99 spikes are by definition rare events. Exemplars capture the specific requests that fell in the high-latency buckets, which are exactly the ones you want to trace.
• Error rate investigation: Attach Exemplars to error counters. When the error rate spikes, click the Exemplar to see the exact failing request's trace.
• Capacity planning: Exemplars on resource utilization metrics can link to the specific requests that caused CPU or memory spikes, helping you understand which workloads are expensive.

When Exemplars Are Less Useful

• High-cardinality metrics: If your histogram has hundreds of label combinations, the Exemplar ring buffer is split across all of them, reducing the chance that any given bucket has a recent Exemplar.
• Very low traffic: If a bucket receives one request per hour, the Exemplar is always the most recent request — which is fine, but the sampling benefit is less meaningful.
• Without tail-based sampling: If your tracing backend drops most traces via head-based sampling, Exemplar links will frequently point to traces that don't exist. Exemplars and tail-based sampling are designed to work together.