What is observability? Logs, metrics and traces explained
Observability is the ability to understand what is happening inside a system from the outside, by collecting and analysing its outputs — and in practice it rests on three pillars: logs, metrics and traces. It grew out of a plain problem: modern cloud systems have too many moving parts for anyone to predict every way they might fail, so teams need to be able to ask new questions of a running system rather than only watch a fixed set of pre-built dashboards. This article explains the three pillars in plain terms, draws an honest line between observability and monitoring, covers why it matters more as systems grow distributed, names the cloud tools involved, and notes where it turns up in certification study.
The problem it solves
A single application running on one server fails in a small, familiar set of ways — you can list most of them in advance and build a dashboard for each. A distributed, cloud-based system does not behave like that. A request might touch a dozen services, three managed data stores and an external API before it returns, and the way it breaks is rarely one anticipated failure — it is more often a novel combination of small delays and partial failures that nobody wrote a dashboard for.
Observability exists for that situation. Instead of only watching known signals, it collects enough raw detail about a system’s behaviour that an engineer can investigate a question nobody thought to ask in advance — “why did this specific customer’s request take four seconds at 2 p.m. on Tuesday?” — after the fact, without having to reproduce the problem first.
The three pillars, plainly
Observability is usually described through three complementary types of data, each answering a different kind of question:
- Logs — discrete, timestamped records of individual events (“user 4821 logged in”, “payment failed: card declined”). Logs are the most detailed pillar and the best source for “what exactly happened here”.
- Metrics — numeric measurements aggregated over time, such as request count, error rate or CPU usage. Metrics are cheap to store and graph, and are the natural fit for “how is the system behaving right now, and is that normal”.
- Traces — the recorded path of a single request as it moves across services, showing how long each step took. Traces are the pillar that answers “which of these dozen services actually caused the slowdown”.
Observability versus monitoring — an honest distinction
The two words get used interchangeably in marketing, but the distinction is real and worth keeping. Monitoring watches a predefined set of known failure modes: you decide in advance which metrics matter, build a dashboard and an alert for each, and monitoring tells you when one of those known things goes wrong. It is essential, and it is not enough on its own.
Observability is the broader capability that lets you investigate unknown failure modes — problems nobody wrote a dashboard for, because nobody predicted them. A genuinely observable system lets an engineer explore its logs, metrics and traces freely and ask new questions on the fly. In short: monitoring tells you that something is wrong; observability helps you work out why, especially the first time that particular thing has ever gone wrong.
Why it matters more in cloud-native systems
Observability became a distinct discipline largely because of the shift towards microservices and cloud-native architecture, covered in our cloud-native explainer. When an application is one process, a debugger and a log file go a long way. When it is dozens of independently deployed services calling each other over a network, a single slow request can be caused by any one hop in that chain — and no individual team owns the whole path.
Traces exist precisely to make that chain visible again, stitching together the individual steps a request took across services so an engineer can see, at a glance, where the time actually went. Without that end-to-end view, distributed systems become genuinely difficult to reason about — every incident turns into a manual hunt across a dozen separate log files.
Cloud and open-standard tooling
Every major cloud provider ships an observability stack. On AWS, CloudWatch handles logs, metrics and alarms, and X-Ray adds distributed tracing across services. Azure Monitor is the equivalent umbrella service, covering metrics, logs and application-level tracing. Google Cloud groups the same capabilities under Google Cloud Operations (formerly Stackdriver).
Increasingly, teams also lean on open standards rather than a single vendor’s format — OpenTelemetry is the most widely adopted, providing a common way to generate and export logs, metrics and traces that can be sent to any of the platforms above, or to third-party tools, without rewriting instrumentation for each one.
Observability in certification study
Observability concepts show up heavily wherever an exam’s focus is operational. On AWS, the CloudOps Engineer – Associate (SOA-C03) devotes an entire domain to monitoring, logging, analysis, remediation and performance optimisation, and expects familiarity with CloudWatch and X-Ray specifically. The Developer – Associate (DVA-C02) covers the same tools from an application-troubleshooting angle. Azure’s Administrator Associate (AZ-104) similarly expects working knowledge of Azure Monitor for day-to-day operations. Beyond any single exam, observability is also core DevOps and SRE practice — understanding the three pillars pays off well beyond exam day.
Original practice questions, timed mock exams and revision notes. No card, nothing to pay.
Questions, answered
Get the study material as it lands
Occasional email when we publish a new certification, guide or set of practice questions. No spam, unsubscribe in one click.