Observability and Operations · Observability Foundations
Logs, Metrics and Traces
What each telemetry signal is good for and how they connect.
Logs are timestamped records of discrete events — rich context, great for debugging specific requests. Metrics are numeric time series (request rate, error rate, latency histograms, queue depth) — cheap to store and ideal for dashboards and alerts. Traces follow one request across services as a tree of spans — they show where time is spent. The power comes from correlation: a metric spike links (via exemplars) to traces, and trace IDs link to the logs of those exact requests. OpenTelemetry standardizes collecting all three.
Investigation flow
1. Alert: checkout p99 latency > 800 ms (metric, SLO burn)
2. Dashboard: latency rose only for region eu-west, started 14:02 (metric breakdown)
3. Exemplar → trace 4bf92f...: 650 ms spent in 'payments.authorize' span
4. Trace ID → logs: "payment provider timeout, retry 2/3" with provider=acme-pay
5. Root cause: provider degradation; mitigation: shift traffic to fallback provider
Common pitfalls
- Only logs, no metrics — you can't alert efficiently.
- Metrics without context — you can't explain why.
- Three disconnected tools with no shared IDs.
Key points
- Metrics alert, traces locate, logs explain
- Correlate with trace/request IDs
- OpenTelemetry for vendor-neutral collection
Further reading: OpenTelemetry: Observability primer
Practice questions
Why are metrics better than logs for alerting?
Answer
Metrics are pre-aggregated, cheap to query continuously and reliable for thresholds over time; alerting on log searches is slower, costlier and more fragile.
What links a slow request on a dashboard to its logs?
Answer
Trace/request IDs: exemplars attach trace IDs to metric samples, and logs include the same trace ID, so you can jump from aggregate to the exact request.
Open in the app to mark lessons complete, take notes and track your progress.