The power of true observability emerges when metrics, logs, and traces are connected to each other. This episode covers correlating metrics to traces via exemplars, logs to traces via TraceID, traces back to logs, and the unified debugging flow of alert → metric → trace → log.

The three pillars of observability are just a pile of separate data if they aren't connected to each other. The main advantage of the LGTM Stack lies precisely in correlation — the ability to move seamlessly from metrics to traces to logs within a single investigation flow.
This episode covers correlation between pillars: from metrics to traces via exemplars, from logs to traces via TraceID, from traces back to logs, and the unified debugging flow that's the primary habit in production.
An exemplar is the mechanism that links metrics to real traces. An exemplar stores a TraceID and a duration as an example inside a histogram metric:
histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))From a histogram panel in Grafana, you can click a point and select the TraceID listed as an exemplar. That click opens the relevant trace directly — the first bridge between metrics and traces.
metric panel -> click point -> exemplar TraceID -> trace waterfallThe metric panel -> click point -> exemplar TraceID pattern is the most valuable interaction in observability dashboards.
Every structured log carries a TraceID (see episode 12). In Grafana, a TraceID appearing in a log panel automatically becomes a clickable link to the related trace.
{
"level": "error",
"service": "payment",
"trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
"msg": "payment gateway timeout"
}The trace_id field is what Grafana recognizes to create automatic log → trace correlation without manual configuration.
The Trace logs panel in Grafana displays logs that match the active span. With settings on the Tempo data source — such as derived fields — Grafana automatically links log lines to traces and vice versa.
To open logs from a trace, Grafana uses derived fields: regex patterns that extract a TraceID or other values from span attributes, then trigger a LogQL query to Loki.
derivedFields:
- name: TraceID
matcher: traceid=(\\w+)
datasourceUid: loki-uid
url: $${__value.raw}The derivedFields configuration above makes Grafana take the TraceID value from span attributes and directly open a log query to Loki.
With derived fields, from a trace waterfall you can one-click display all the logs for that TraceID — without manually copying the TraceID.
This is the golden triangle introduced in episode 2, now in real working form:
alert -> metrik -> trace -> log -> root causeThe alert -> metrik -> trace -> log pattern is followed during incidents: receive the alert, look at metrics to confirm, open the trace to find the problematic span, then follow the logs for error details.
Info
Correlation isn't a feature that activates by itself — it needs preparation: applications must carry TraceID in logs, exemplars must be enabled, and derived fields must be configured. Set all of that up from episode 4 onward before you need it during an incident.
In episode 18 you understood correlating metrics to traces via exemplars, logs to traces via clickable TraceIDs, traces back to logs via derived fields, and the unified debugging flow of alert → metric → trace → log that becomes the production working pattern.
The key takeaways:
In the next episode 19 we'll discuss alerting strategy and AlertManager — the principles of actionable alerts, Grafana Alerting, routing and grouping, recording rules, and alert maintenance best practices. The correlated metrics, logs, and traces will start protecting your system proactively.