Logs vs Metrics vs Traces: The Three Pillars

Logs, metrics, and traces are the three data types most observability tooling is built around, and each one answers a different question: logs tell you what happened, metrics tell you how much or how often, and traces tell you where time went across a request. Reaching for the wrong one is a common reason debugging a production issue takes longer than it should.

What logs capture

A log is a timestamped, discrete record of an event — a request came in, an exception was thrown, a job finished. Logs are unstructured or semi-structured text (or, increasingly, structured JSON), and they’re the most detailed of the three, because they can carry arbitrary context: a stack trace, a request body, a user ID.

That detail is also the cost. Logs are the most expensive of the three pillars to store and search at volume, which is why most teams sample, filter, or aggregate them before long-term retention rather than keeping every line forever. Once a system spans more than a couple of processes, you also need a way to correlate log lines from different services for the same request — the problem log aggregation tooling exists to solve.

Logs are best for “what exactly happened here” — reconstructing the sequence of events around a specific failure, once you already know roughly where to look.

What metrics capture

A metric is a numeric measurement recorded at a point in time — request count, error rate, memory usage, queue depth. Unlike logs, metrics are pre-aggregated: instead of storing every individual event, a metrics system stores a rolling count, sum, or histogram, which makes them dramatically cheaper to store and query over long time ranges.

That aggregation is also the tradeoff. A metric can tell you your error rate jumped from 0.1% to 4% at 14:32, but it can’t tell you which specific requests failed or why — you lose the individual event the moment it’s folded into a counter. Metrics are what feed dashboards and alerts, and they’re the basis for defining SLOs and SLIs: you can’t set a target for “99.9% of requests succeed” without a metric measuring the success rate in the first place.

Metrics are best for “is something wrong, and since when” — the first signal that triggers an investigation, before you know which specific request or service is at fault.

What traces capture

A trace follows a single request as it moves through a distributed system, recording how long it spent in each service along the way as a tree of timed spans. Where a metric might tell you overall latency went up, a trace shows you that a particular request spent 400ms in the API gateway, 20ms in the auth service, and 1.8 seconds waiting on a downstream database call — pinpointing exactly where the time went for that one request.

Traces require the most instrumentation of the three: every service in the request path needs to propagate a shared trace ID and record its own span, which is nontrivial to retrofit onto a system that wasn’t built with tracing in mind. Tools like eBPF have made some of this instrumentation possible without changing application code, by observing system calls and network traffic directly rather than requiring explicit trace propagation.

Traces are best for “where in this specific request did the time go” — root-causing a latency problem once metrics have told you latency is a problem at all.

Comparing the three

	Logs	Metrics	Traces
Granularity	Individual events	Aggregated numbers	Per-request spans
Typical question	What happened?	How much, how often?	Where did time go?
Storage cost	High	Low	Medium–high
Instrumentation effort	Low (just log statements)	Low–medium	High (span propagation)
Best for	Root-cause detail	Alerting, trend detection	Cross-service latency
Retention	Usually short (days–weeks)	Usually long (months+)	Usually short (days)

How they work together

In practice, an incident investigation moves through all three in order. A metric alert fires — error rate is up. That tells you something is wrong but not what. You pull a trace for one of the failing requests, which shows the time is going into a call to a downstream service that’s timing out. Then you pull the logs for that specific service around that timestamp, which show the actual exception: a connection pool exhausted.

Each pillar narrows the search. Metrics tell you where to look at a system level, traces tell you where to look within a request, and logs tell you exactly what happened once you’re there. Trying to skip a step — grepping raw logs across every service before you know which one is implicated, for instance — is usually slower than following the chain.

This is also why modern observability platforms increasingly correlate the three automatically: a trace ID attached to every log line, a metric that links out to example traces from the same time window. The three pillars were originally separate tools with separate storage backends, largely because of the cost and instrumentation tradeoffs above, but the goal of tying them together is to make that manual correlation step unnecessary. See what observability actually means for how these pieces fit into the broader discipline, and our guide to designing behind a load balancer for one common source of the cross-service latency traces are built to surface.

The takeaway

Logs, metrics, and traces aren’t interchangeable — they trade off granularity, cost, and instrumentation effort in different directions, and each is suited to a different stage of debugging. Metrics detect that something is wrong and roughly when; traces localize where within a request the problem lives; logs supply the exact detail once you know where to look. A system with only one of the three will always have blind spots the other two exist to cover.