Exemplars connect an aggregate to an example, not a complete population

A metric data point represents an aggregation over a population and time interval. An exemplar preserves context from a selected contributing measurement, such as its value, time, and associated trace/span identifiers under the SDK's rules. These attributes are not an invitation to add a trace ID label to the metric's ordinary series identity. Doing that can create a new series per trace and defeat aggregation's bounded cost. Read the actual exporter and backend support because an exemplar can be filtered, sampled, limited, or discarded along the path.

Selection policies differ. A trace-based eligibility filter can restrict which measurements are candidates, and a reservoir then chooses among eligible candidates. Do not assume that an exemplar is uniformly representative of all requests or that it is always the slowest request in its bucket. OpenMetrics and OpenTelemetry have their own representation and reservoir contracts. Treat any sampled example as evidence that this particular observed behavior occurred, with its documented provenance, rather than as an exact count of all events sharing its attributes.

Following a trace ID from a metric requires the trace to have been recorded, retained, delivered, indexed, and still available under the user's access policy. Following from that trace to logs requires log context propagation and independent collection/retention behavior. A missing destination can therefore mean many things besides an invalid ID. Preserve service, environment, time range, instrumentation scope, and identifier semantics so a UI does not query an unrelated backend or silently join identically named resources across different environments.

Time proximity alone does not establish a causal relationship. An error log near a latency spike might belong to another request or reflect a common upstream cause. A shared trace context is stronger correlation evidence for the instrumented relationship, but incomplete traces and manually attached attributes still have limits. Verify the operation and event sequence, then test the suspected mechanism with additional observations or a controlled reproduction. A dashboard link can accelerate investigation; it should not manufacture certainty by hiding how the joined records were selected.

Create a known test request that emits compatible metrics, spans, and a structured event, then follow the references through the actual data path. Exercise absent traces, old retention windows, restricted access, different environments, and late indexing. The UI should distinguish a link that resolved to no retained data from proof that no work occurred. Track resolution failures and provenance without exporting sensitive context indiscriminately. A metric can remain a valid complete count even when its attached examples are sparse, provided its own collection contract is satisfied.

The probability lab gives a hypothetical resolution model only. Reset, set both p=0.75 and n=20, predict fifteen resolvable references on average, then Play or Step. Reset and re-enter both parameters before a separate comparison. The exact binomial bars assume independent references with one common resolution probability; real expiry, backend outages, or access policies can correlate results. Playback highlights the distribution rather than resolving URLs or sampling traces. It cannot infer why an actual link failed or turn selected exemplar cases into a representative request population.