09.02 · Lecture
Logs, Metrics, and Traces
Say what each of the three signals answers and where the three-pillars framing misleads.
Logs explain the specific event, metrics show aggregate behaviour over time, and traces follow one request through multiple services. Treating them as separate “pillars” is the trap: useful observability comes from correlated signals with shared context, plus other views such as profiling when the usual signals only say something is slow.
What this lesson answers
- logs metrics traces what is each for
- when should I use traces instead of logs
- why are three pillars of observability misleading
Notes
Logs, Metrics, and Traces — Logs, metrics, and traces exist to answer different failure-detection questions—“what happened?”, “how much/how often?”, and “where did this request spend time?”—and without separating them teams either drown in events, miss aggregate regressions, or cannot follow failures across services.
Key Concepts: - Logs answer “what happened?” with discrete events such as `ERROR user_id=42 payment_id=abc timeout_ms=3000` emitted by one process at one time. - Metrics answer “how much/how often?” using numeric time series, e.g.
References
Common questions
- What is the difference between logs, metrics, and traces?
- Logs are discrete records from a process and are strongest for explaining exactly what happened. Metrics are numeric series over time and are strongest for alerting on aggregate behaviour. Traces connect spans from a single request across services, showing where time was spent and which dependency was involved.
- Why not just alert on error logs?
- Raw error logs are noisy and often lack the service-level meaning needed for paging. Harmless retries, expected failures, or verbose libraries can create alerts without user impact. Metrics are usually better for detection because they summarise rates, latency, and error behaviour across many requests before logs are used for detail.
- What is wrong with the three pillars model?
- The problem is treating logs, metrics, and traces as separate boxes or vendor products. In practice they need shared fields so an alert can lead to a trace and then to the relevant log lines. The model also leaves out useful signals such as profiling and real-user monitoring.