Why Senior Engineers Disagree About the Three Pillars of Observability

For years, the 'three pillars of observability'—logs, metrics, and traces—have been the gospel for understanding complex software. But a growing chorus of senior engineers is arguing that this foundational concept is outdated and misleading.

The Old Testament: Logs, Metrics, and Traces

To understand the debate, you first have to know the orthodoxy. The three pillars are distinct types of telemetry data that, together, are meant to provide a complete picture of a system's health. Logs are timestamped records of discrete events, like a single user error or an application startup. They're granular but can be overwhelming. Metrics are aggregated numerical data, like CPU usage over time or the number of errors per minute. They are great for spotting trends and setting alerts but lose individual context. Traces track a single request as it moves through all the different microservices in a distributed system, showing the whole journey and identifying bottlenecks. For a long time, the prevailing wisdom was that if you collected all three, you had achieved observability.

Cracks in the Foundation

The core of the disagreement is that logs, metrics, and traces are just data types—they are the inputs, not the goal itself. Critics, including prominent voices like Honeycomb CTO Charity Majors, argue that simply having these three data streams doesn't mean you can actually understand your system. The real goal of observability is the ability to ask novel questions about your system's state without needing to predict that question in advance. The pillar model often falls short here. Metrics, for instance, are pre-aggregated, meaning you lose the ability to ask about specifics that weren't defined ahead of time. If you track errors by region but not by user ID, you can’t debug a specific user’s problem. This limitation is especially painful in modern, complex systems where the number of variables (what engineers call 'high cardinality') is enormous.

The New Philosophy: Questions Over Pillars

The counter-argument proposes a fundamental shift in thinking. Instead of focusing on three separate data types, this new philosophy centers on collecting rich, structured events. An 'event' is a single unit of work containing all the context—user ID, shopping cart size, software version, region, and hundreds of other details. This arbitrarily wide, structured log becomes the single source of truth. From this one rich data source, you can then derive metrics, construct traces, and perform detailed logging without losing the connections between them. The focus moves from collecting specific types of data to ensuring the data you collect is explorable. It prioritizes the ability to slice, dice, and correlate information in infinite ways, which is crucial for debugging the unpredictable 'unknown unknowns' that plague distributed systems.

From Pillars to Platforms

This debate isn't just academic; it’s driving the evolution of engineering tools and practices. The industry is moving away from siloed tools for logs, metrics, and traces and toward unified platforms. The rise of open standards like OpenTelemetry is accelerating this by creating a common language for generating and collecting telemetry data, breaking down the walls between the old pillars. The future of observability seems to be less about which pillars you have and more about having a unified, AI-powered platform that can ingest high-context data and allow engineers to ask questions in a natural way. The shift is from reactive firefighting across three different toolsets to proactive problem-solving within a single, intelligent system.