Logs and traces answer different questions. Reaching for the wrong one — or collecting both without linking them — is why so many investigations stall.
What Logs Are Good At
Logs are a discrete record of what happened at a point in time. They're ideal for confirming a specific failure mode, reading error messages, and auditing behavior.
Their weakness is causality: a log line tells you something failed, not how the request reached that point.
What Traces Are Good At
A trace follows a single request across services and shows where the time went. When latency spikes, a trace points at the exact span responsible.
trace_id=astk_trace_92jx 812ms
api-gateway POST /api/v1/orders 812ms
billing-service charge 640ms ← slow
postgres-primary insert 96ms
Why Correlation Wins
The real value appears when a log line carries the trace ID it belongs to. You start from an error log and jump straight to the full request path — no guessing, no timestamp matching.
Takeaways
Collect both, but link them. A log without a trace ID is an island; a trace without logs lacks detail. Together they tell the whole story.