The Three Pillars: Logs, Metrics, and Traces
Observability is the ability to understand what's happening inside a running system just from what it exposes externally, without having to guess or attach a debugger to production. It's usually broken down into three complementary signal types.
Monitoring vs. observability
Monitoring answers questions you already thought to ask ahead of time ("is CPU usage above 80%?"). Observability is what lets you answer questions you didn't anticipate when something goes wrong at 3am ("why are only requests from mobile clients in the EU slow, and only since 20 minutes ago?"), by exploring the raw signals your system emits.
The three pillars
| Pillar | Answers | Example |
|---|---|---|
| Logs | What happened, in detail, at a specific point | "User 42's payment failed: card declined" |
| Metrics | How much/how many, over time | "Requests per second", "p99 latency" |
| Traces | How a single request flowed through multiple services | "Request hit API → auth service (12ms) → database (340ms) → response" |
None of the three replaces the others, metrics tell you something is wrong and roughly when, logs tell you the specific detail of what happened, traces tell you where in a multi-service request the time actually went.
A concrete example
Imagine checkout latency suddenly spikes:
- A metric (p99 latency dashboard) shows the spike started at 14:32 and is ongoing.
- A trace for a slow request shows 90% of the time is spent in a call to the inventory service.
- Logs from the inventory service around that time show repeated database connection timeout errors.
Each pillar narrowed the investigation, from "something is slow" to "which service" to "the exact underlying error", in minutes instead of hours of guessing.
NOTE
This course focuses on the concepts and vendor-agnostic tools (structured logging, Prometheus-style metrics, OpenTelemetry), the same ideas apply whether you're using a cloud provider's built-in tools, a self-hosted stack, or a dedicated observability vendor.