Cloud Computing's observability lesson introduced logs, metrics, and traces as a checklist to implement. This lesson is the piece that actually matters for using them well — each one is blind to a specific kind of question, and knowing which is which is what stops a team from reaching for the wrong tool during an incident.
3 min read
Logs, metrics, and traces each capture a genuinely different shape of information, and none of them substitutes for the other two — a system with excellent logs and no metrics is just as blind in a different direction as a system with excellent metrics and no traces.
A log line proves one specific event happened, with full detail — but answering "is the error rate elevated right now" from raw logs means aggregating potentially millions of lines yourself, which is slow and expensive at real scale. Logs are the right tool once you already know which request or event to look at; they're the wrong tool for noticing that something's wrong in the first place.
A dashboard showing "error rate: 3%" is exactly what you need to notice a problem exists and to alert on it automatically — but it can't tell you which 3% of requests failed, for which customers, or why. Metrics are pre-aggregated by design, and that aggregation is precisely what makes them cheap to store and fast to query at scale — and precisely what throws away the per-request detail a real investigation eventually needs.
A trace shows that a call to the payments service took 400ms out of a 900ms total request — genuinely useful for finding where time went across service boundaries. It doesn't show why that specific service call was slow (a slow database query inside it, GC pauses, lock contention) — that detail lives in that service's own logs and metrics, not in the trace itself, which only records the boundary timing.
A real incident almost always moves through all three in this order: a metric alert says something is wrong (lesson 5 covers designing these alerts well), a trace narrows down where in a multi-service request path the problem lives, and logs from that specific service explain what actually happened. Skipping straight to logs without a metric or trace to narrow the search means grep-ing through everything, hoping to get lucky.
Cloud Computing's observability lesson is a solid "get this set up on AWS" walkthrough — CloudWatch, X-Ray, a checklist. This domain instead spends a full lesson on each pillar's actual mechanics and design trade-offs: metric types and what they can and can't measure (lesson 2), the frameworks that tell you what to actually put on a dashboard (lesson 3), how distributed tracing and its open standard actually work under the hood (lessons 6–7), and the parts of running observability well that a checklist can't capture — alert design, SLOs, and choosing a stack (lessons 5, 8–12).
Check your understanding
A quick comprehension check — not tracked, not graded, just for you.
1. Why can't logs alone efficiently answer 'is the system healthy right now'?
2. What can a trace reveal that a metric alone cannot?
3. What is the typical order an incident investigation moves through the three pillars?
Observability & Monitoring