Telemetry Became a Data Problem, and the Observability Vendors Know It

The observability bill has been the loudest complaint in enterprise infrastructure for three years running, and the complaint has changed nothing. Contracts get renewed, spend keeps climbing, and the annual ritual of threatening to move to an open-source stack ends with a negotiated discount and another year on the same platform. Anger is not leverage. Anyone reading the vendor repricing announcements as a response to customer frustration is reading the wrong signal.

What is actually happening is an architectural change, and it is the architecture, not the anger, that breaks the pricing model. Observability was sold as a product: an agent you install, a proprietary format it emits, a backend only that vendor can query, and a user interface that is the only way to see your own data. Every layer of that stack is being pulled apart. Instrumentation is becoming open at the source through OpenTelemetry. Collection and routing are becoming a separate controllable layer through telemetry pipelines. Storage is becoming columnar files on object storage that anyone can read. What remains proprietary is the query experience and the incident workflow on top.

That is the whole thesis. The vendor's position is moving from "we hold your data" to "we have the better query experience", and those are not the same business. The first supports pricing on ingestion volume, because the customer has no alternative destination. The second supports pricing on value delivered to the people who actually use the tool, which is a smaller number multiplied by a smaller unit. The vendors know this, which is why their product roadmaps are not about better dashboards.

Why the Cost Curve Forced This

The structural problem is that telemetry volume grows with service count and cardinality, and neither of those tracks revenue.

A monolith emits one stream of logs and a modest set of metrics. Decompose it into two hundred services and the trace volume rises with the call graph rather than with the transaction count, because a single user request now generates spans at every hop. Add Kubernetes and the host count becomes elastic and ephemeral, so per-host pricing detaches from anything the finance team can forecast. Add per-customer, per-endpoint, or per-transaction tags to a metric and the time series count multiplies combinatorially. The business did not grow. The telemetry did, superlinearly, and the bill followed it.

That arithmetic is the reason cost complaints never resolve. Every other line in the infrastructure budget has a defensible ratio to something the business cares about: cloud compute scales roughly with traffic, storage with retained data, headcount with delivery capacity. Observability spend scales with architectural complexity, which is to say it scales with decisions engineering made for reasons that had nothing to do with the observability budget. There is no ratio to defend, which means there is no level at which the bill looks correct, which means the complaint is permanent by construction. The detailed mechanics of how the invoice is assembled are laid out in the analysis of the observability cost explosion; the point here is that no discount fixes a curve, it only moves the intercept.

Vendors understood this earlier than customers did, and for a while it worked in their favor. When the data is captured in a proprietary agent, stored in a proprietary backend, and queried through a proprietary interface, superlinear volume growth is not a problem to solve. It is the revenue model. The customer's architectural choices compound the vendor's account growth without the vendor shipping anything new.

The counterforce arrived as three separate pieces of infrastructure that individually looked incremental and collectively dismantled the position.