The Problem That Created the Pillars
A decade or two ago, software was simpler. Most applications were “monoliths”—single, large codebases where everything happened in one place. Debugging was like fixing a car; you could pop the hood and see all the parts. But then came the great migration
to microservices. Companies like Twitter, Google, and Netflix began breaking their monoliths into hundreds, or even thousands, of smaller, independent services. This was great for scalability and development speed, but a nightmare for troubleshooting. A single user request might now travel across dozens of services before completing. When something broke, engineers were left asking: where did it even happen? The old ways of monitoring, which focused on the health of individual servers, were no longer enough. They needed a new way to understand the internal state of these complex, distributed systems just by looking at their outputs. This was the problem observability was born to solve.
Pillar 1: Logs, The Detailed Storytellers
Logs are the oldest and most fundamental piece of the puzzle. Think of them as a detailed, chronological diary kept by an application. Each entry is a timestamped record of a discrete event: a user logged in, a database query failed, a file was written. They answer the question, “What happened at this exact moment?” In the monolith era, you could often find the whole story in one log file. But in a distributed world, logs became both essential and overwhelming. They provide the granular, ground-truth context needed to understand a specific failure, but trying to piece together a story from thousands of separate log streams is like trying to solve a crime by reading every book in a library. Still, for deep-dive root cause analysis, nothing beats the rich, contextual detail of a log.
Pillar 2: Metrics, The High-Level Dashboard
As systems scaled, engineers realized they couldn't read every log. They needed a bird's-eye view. This led to the rise of metrics. Metrics are numeric measurements aggregated over time—things like CPU usage, request rate, or error count. Instead of telling a detailed story about one event, they answer the question, “What is the overall health of the system?” Think of metrics as the gauges on your car’s dashboard: speed, fuel level, engine temperature. They don't tell you why the engine is overheating, but they're the first and fastest way to know that it's overheating. This makes them perfect for creating alerts and understanding trends. Their compact, numeric nature makes them efficient to collect and store, allowing engineers to quickly spot system-wide problems that would be invisible in a sea of logs.
Pillar 3: Traces, The Cross-Country Road Map
Metrics told you that something was wrong, and logs could tell you what went wrong inside a single service, but a crucial piece was missing. In a microservices environment, the biggest question was often, “Where did the process fail?” That’s where traces come in. A distributed trace follows a single request on its journey through all the different services it touches. It’s like putting a GPS tracker on a package and watching its path from the warehouse to your door. Each stop is recorded, along with how long it took. This allows engineers to visualize the entire flow, pinpoint bottlenecks, and see which specific service caused a failure. Traces were designed specifically to solve the biggest headache of distributed systems: understanding the path of a single transaction from end to end.
The 'Real Reason' Is... There Wasn't One
Here's the twist: these three pillars weren't designed together as a unified framework. In fact, for a long time, they were developed by different people to solve different problems. The term “three pillars” was popularized by vendors much later, after an engineer named Peter Bourgon wrote an influential blog post in 2017 that simply tried to clarify the vocabulary around these three data types. He presented them as overlapping tools with different trade-offs, not as a rigid checklist. The real reason they exist as a trio is evolutionary. They are three distinct, complementary lenses for viewing a complex system. Metrics give you the high-level alert (the what), traces show you the problematic path (the where), and logs provide the granular context to find the root cause (the why). You use them together because no single one tells the whole story.
