Eric Tschetter on Decoupling Observability
Logs, metrics, and traces started life inside a single vendor stack that owned collection, storage, querying, and dashboards all at once. Microservices made that arrangement expensive and hard to leave. Eric argues for pulling the stack apart the way business intelligence pulled the warehouse away from the dashboard, and we work through what that costs you as well as what it buys.
Three things worth keeping
The proposed split is four layers: ingest and routing, storage, query and compute, and visualization. The parallel Eric draws is to business intelligence, where the warehouse and the dashboard stopped being one product. A coupled observability vendor sells all four together, and that bundling is where both the lock-in and the shape of the scaling bill come from, not from any one layer being bad.
Portability is a schema problem before it is a storage problem. OpenTelemetry earns its place in this architecture mainly as a shared schema: if telemetry is written in a form more than one backend can read, then changing the query layer is a configuration change rather than a re-instrumentation project across every service.
Query and compute is where the difficulty concentrates, because observability data wants real-time analytics behavior rather than batch. That drives the discussion into Druid's indexing choices and into returning one unified result across hot and cold storage, so an engineer chasing an incident does not have to know which tier their time range happens to live in.