{"id":4178,"date":"2026-05-29T11:06:00","date_gmt":"2026-05-29T11:06:00","guid":{"rendered":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/05\/29\/why-logs-metrics-and-traces-still-dont-give-you-real-observability\/"},"modified":"2026-05-29T11:06:00","modified_gmt":"2026-05-29T11:06:00","slug":"why-logs-metrics-and-traces-still-dont-give-you-real-observability","status":"publish","type":"post","link":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2026\/05\/29\/why-logs-metrics-and-traces-still-dont-give-you-real-observability\/","title":{"rendered":"Why Logs, Metrics and Traces Still Don\u2019t Give You Real Observability\u00a0"},"content":{"rendered":"
\"Jamf,<\/div>\n

\"Jamf,<\/p>\n

Several years ago, the\u00a0observability community reached what felt like a consensus:\u00a0The\u00a0three pillars\u00a0\u2014\u00a0logs, metrics and traces. Instrument everything, ship it all to a central platform and you will finally understand what your system is doing.<\/span>\u00a0<\/span><\/p>\n

It\u2019s a tidy framework.\u00a0Yet it\u00a0turns out to be incomplete in ways that only become obvious once you\u2019re actually trying to debug a production incident with it.<\/span>\u00a0<\/span><\/p>\n

This article isn\u2019t an argument against logs, metrics and traces; you\u00a0need all three.\u00a0However,\u00a0there\u2019s a growing set of failure modes in modern distributed systems that the three-pillar model struggles to explain \u2014 and understanding why is the first step toward building observability that actually works.<\/span>\u00a0<\/span><\/p>\n

The Promise of the Three Pillars<\/span>\u00a0<\/span><\/h3>\n

Before we critique the model, let\u2019s be precise about what it promises.<\/span>\u00a0<\/span><\/p>\n

Logs<\/span><\/i>\u00a0give you a timestamped record of discrete events:\u00a0A\u00a0function was called, a request came in, an error was thrown. They\u2019re rich in detail and easy to add to code. The challenge is volume \u2014 a high-traffic service can generate millions of log lines per minute, and correlating across services requires discipline and tooling.<\/span>\u00a0<\/span><\/p>\n

Metrics<\/span><\/i>\u00a0give you aggregated numerical data over time:\u00a0Request\u00a0rate, error rate, latency percentiles, CPU usage. They\u2019re cheap to store, easy to alert on and ideal for dashboards. The tradeoff is that aggregation loses information \u2014 a p99 latency of\u00a0two\u00a0seconds tells you something is slow, but not where or why.<\/span>\u00a0<\/span><\/p>\n

Traces<\/span><\/i>\u00a0give you a causal record of how a single request moved through your system \u2014 which services it touched, how long each hop took, where errors occurred. Distributed tracing, using standards like<\/a><\/span>\u00a0<\/span>OpenTelemetry<\/span>, has matured considerably and can dramatically accelerate root cause analysis.<\/span>\u00a0<\/span><\/p>\n

Together, these three tools cover a lot of ground. For the canonical failure modes \u2014 a slow database query, a misconfigured cache, a crashing pod \u2014 they work well. The question is what happens when the failure mode is less canonical.<\/span>\u00a0<\/span><\/p>\n

What the Three Pillars Miss<\/span>\u00a0<\/span><\/h3>\n

The\u00a0Known Unknowns Problem\u00a0<\/strong><\/h3>\n

Observability built on logs, metrics and traces is fundamentally a system of\u00a0<\/span>known unknowns<\/span><\/i>. You instrument the things you think might go wrong. You define the metrics that seem important. You add trace spans around the code paths you care about.<\/span>\u00a0<\/span><\/p>\n

However,\u00a0production systems fail in ways you didn\u2019t anticipate. When a new failure mode appears that doesn\u2019t match your existing instrumentation, you\u2019re blind. You\u2019re correlating signals that weren\u2019t designed to explain this kind of problem, often in a rush, in the middle of an incident.<\/span>\u00a0<\/span><\/p>\n

The classic example:\u00a0A\u00a0subtle interaction between two microservices that each look perfectly healthy by their own metrics but are producing subtly wrong outputs when used together.\u00a0No individual metric captures this. The logs from each service look normal. The traces show normal latencies. The failure is in the\u00a0<\/span>relationship<\/span><\/i>\u00a0between services, not in any one service\u2019s behavior.<\/span>\u00a0<\/span><\/p>\n

High-Cardinality Blind Spots\u00a0<\/strong><\/h3>\n

Traditional metrics systems have trouble with high-cardinality data. If you want to track latency by user ID or error rate by specific combination of API endpoint + region + tenant, most time-series databases either refuse or make it prohibitively expensive.<\/span>\u00a0<\/span><\/p>\n

This is a real operational gap. Many production incidents are caused by a specific cohort of users, a specific region or a specific combination of request parameters that you can\u2019t efficiently query for with low-cardinality metrics.\u00a0You know something is wrong. You can see the aggregate signal degrading. But you can\u2019t slice to the exact population affected.<\/span>\u00a0<\/span><\/p>\n

Tools\u00a0such as<\/span>\u00a0<\/span><\/a>Honeycomb<\/span>\u00a0and<\/span>\u00a0<\/span><\/a>Lightstep<\/span>\u00a0were built specifically around solving this with high-cardinality event data \u2014 each request as a structured event with arbitrary fields. This is a fundamentally different mental model than metrics-first observability, and it enables queries you simply cannot run with traditional tools.<\/span>\u00a0<\/span><\/p>\n

The Context Collapse Problem<\/span>\u00a0<\/span><\/h3>\n

Traces give you a picture of how a request flows through your system.\u00a0However,\u00a0that picture is only as good as the context propagated through it. In practice, context collapse is endemic:<\/span>\u00a0<\/span><\/p>\n