The three pillars of observability explained plainly — what metrics, logs, and traces each tell you, and which one to reach for first depending on the question you're actually asking.
New engineers often reach for logs first, every time, because it's the most familiar tool — but logs are the slowest way to answer many operational questions. Knowing which of the three tools actually answers your specific question saves real time during an incident, not just in theory.
What each of the three observability pillars is actually good for, a simple rule for choosing which one to check first, and why they work best used together rather than any one alone.
A metric is a number tracked over time: CPU percentage, request count per minute, average response time, queue depth. Metrics are cheap to collect at high frequency and excellent for two things: alerting (a threshold crossed) and spotting trends (did this start gradually or suddenly, and exactly when). What metrics can't tell you is why — a CPU spike tells you something is consuming CPU, not which specific request or code path caused it.
A log is a discrete, timestamped record of a specific event, usually with rich context (an error message, a stack trace, a request's parameters). Logs are the right tool once you already know roughly when something went wrong (from a metric or an alert) and need to know what — but searching raw logs with no starting time window at all, across a busy production system, is slow and often the wrong first move.
A trace follows one specific request across every service, function, or system it touched, recording how long each step took. Traces are the right tool specifically for distributed, multi-step problems: "the page is slow, but is it the database, an external API call, or the application's own processing?" A trace answers that directly; metrics and logs alone usually require more inference to get there.
Used in this order, the three tools narrow the investigation at each stage rather than requiring you to read everything.
Metrics are usually the entry point into an investigation; once you have a time window, the discipline of reading logs efficiently (rather than scrolling endlessly) is covered in Reading Logs Backwards: A Debugging Habit. For a structured way to turn "I found the cause" into "I found the root cause," see Root Cause Analysis: A Simple Framework.
Part of: Support Engineers, System Administrators, DevOps Beginners, Cloud Beginners