When to Reach for Logs, Metrics, or Traces

Metrics answer 'is something wrong right now, and how wrong' — they're cheap to store at high resolution and are what should page someone, but they can't tell you why. Logs answer 'what exactly happened on this one request or process,' with full context, but they're expensive to search at scale and useless for spotting a trend across millions of events. Traces answer 'where did the time go across a distributed call chain' — which service, which downstream call, which retry — and are the only one of the three that reconstructs causality across service boundaries. A common failure mode is alerting directly off logs (grepping for ERROR and paging on count), which produces noisy, low-precision alerts because logs weren't designed to be aggregated that way; use metrics for alerting and reserve logs for the investigation that follows. Another is adding distributed tracing last, after logs and metrics, when it's actually the fastest path to finding the actual bottleneck in a multi-service request — a single trace showing 800ms spent in a downstream auth call answers in seconds what could take an hour of log correlation across services.