The Anti-Observability Manifesto
Logs, measurements, traces, and alerts help explain production systems. The monitoring stack should not become another system just as hard to operate.
A second product
Monitoring helps teams find failures, understand production behavior, and verify repairs. Complex distributed systems could not be operated responsibly without it.
Our question is about proportion: why does understanding the software sometimes require a second software platform nearly as elaborate as the first?
When a request crosses services, queues, networks, runtimes, and vendors, its story is split among many sources. Telemetry has to reconstruct what a single process would have kept as control flow and a call stack. The tools solve a real problem. The architecture helped create it.
What the stack costs
Logs must be collected, moved, indexed, retained, and queried. Measurements need names, labels, storage, and useful views. Traces reconnect requests across network boundaries. Alert rules decide when somebody should act.
Collection agents, data pipelines, indexes, dashboards, and alert routers are production systems too. They consume resources, fail, and need maintenance. Observing the product can become a product of its own.
Usage pricing ties cost to hosts, events, data volume, retention, or labels. Instrumentation, dashboards, thresholds, and false alarms all take time. During an incident, engineers may move among logs, traces, dashboards, and deployment histories. More data does not automatically produce more understanding. Excellent tools can also hide the chance to remove a service, a queue, or a network hop.
None of these components is inherently wasteful. The mistake is treating the largest possible stack as the default before the system demonstrates a need for it.
Ask the questions that matter
Are users succeeding? Is the application healthy? What failed? Why? Can we verify the repair?
We collect enough information to answer those questions and add more when a concrete operating need appears. A signal without an owner or an expected response is usually noise. A dashboard nobody uses is not visibility. An alert nobody can act on is an interruption.
Simple systems are easier to observe directly. Fewer network boundaries mean fewer partial failures and fewer identifiers needed to reconnect the story.
A product spread across machines, regions, or independent teams may need central logs, tracing, richer measurements, and a dedicated incident platform. Scale changes the answer. Insufficient information is expensive during an outage. So is an ocean of uncurated data.
Simplicity does not make a system self-explanatory. It narrows the search space. When the answers become difficult, inspect the architecture as well as the monitoring stack.
Simplify the system. Monitor what matters.