Observability 101: Logs, Metrics, and Traces Explained

“Observability” is often used as a buzzword, but it decomposes into three genuinely distinct, complementary data types — understanding what each one is actually for prevents over-relying on just one.

Logs: What Happened, in Detail

Discrete, timestamped events with rich context — “User 42 failed login at 14:32:01, reason: invalid password.” Genuinely detailed, but expensive to store at scale and slow to search across millions of entries without good indexing.

Metrics: Aggregated Numbers Over Time

http_requests_total{status="500"} = 1,204
http_request_duration_seconds{quantile="0.99"} = 1.2

Cheap to store and query even at massive scale (since they’re pre-aggregated), ideal for dashboards and alerting — but they can’t tell you the specific story of any one individual request.

Traces: The Path a Single Request Took

A trace follows one specific request across every service it touched, with timing for each hop — invaluable for diagnosing “why was THIS specific request slow” in a distributed, microservices-based system, something logs and metrics alone genuinely can’t reconstruct on their own.

The three are genuinely complementary: metrics tell you something is wrong (error rate spiked), traces show you where in the request path (which specific service), and logs give you the detailed why (the exact error message and context) once you’ve narrowed down where to look.