Observability Is Not Three Pillars: It Is Asking Questions

The Three Pillars Trap

The industry defined observability as "logs + metrics + traces" and teams optimized for collecting all three. But having petabytes of telemetry data does not make your system observable. Observability is a property of the system, not the monitoring stack.

A system is observable when you can understand its internal state by examining its outputs. The question is not "do we have enough data?" but "can we answer questions we have never asked before?"

From Known-Unknowns to Unknown-Unknowns

Dashboards Handle Known-Unknowns

Dashboards are great for questions you know to ask: Is CPU high? Is latency increasing? Is the error rate above threshold? These are monitoring, not observability.

Exploration Handles Unknown-Unknowns

The 3 AM incident that pages you will not match any dashboard. You need to ask: Why are requests from this specific customer, using this specific feature, on this specific region, suddenly 10x slower?

This requires high-cardinality, high-dimensionality data that you can slice and dice in real time.

Structured Events Over Raw Logs

Stop logging strings. Every interesting event should be a structured record with all relevant context:

• Request ID, user ID, tenant ID
• Duration, status code, error message
• Feature flags, deployment version
• Upstream dependencies called and their latencies

When every event carries its full context, you can group, filter, and aggregate in ways that raw log lines never permit.

The Practical Starting Point

You do not need a complete observability platform on day one. Start with one thing: instrument your request hot path with structured events. One well-instrumented service teaches you more about your system than a dozen dashboards watching CPU.