Own the Signal, Rent the Platform

Every observability consolidation programme I see starts the same way. A leadership team looks at five, six, eight overlapping tools, adds up the bill, and asks: “Which platform should we standardise on?” It feels like the responsible question. It is the wrong one.

The platform is the part you will replace. The signal, the instrumentation that produces your telemetry, is the part you keep. Get that wrong way round and you will run the same painful migration again in three years, having learned nothing except how to fill in a procurement template.

A platform is a rental. You pay for it monthly, by volume, and the meter never stops. Look at any major vendor's published pricing and the shape is the same: you are billed for what you ingest, store, and query. Google Cloud's own published observability pricing, for example, meters Managed Service for Prometheus from a fraction of a penny per million samples ingested, and Cloud Monitoring per mebibyte on a tiered scale, with separate charges for alerting. That is not a dig at Google. Every serious platform prices this way, and that is precisely the point: the cost scales with your telemetry, and your telemetry only grows.

Rentals also end on someone else's schedule. In 2026, ServiceNow's Cloud Observability, the product formerly known as Lightstep, reached end of life. Teams that had standardised on it did not choose to re-migrate. The decision was made for them, by an acquisition and a roadmap. That is the risk hidden inside “which platform should we standardise on”: you are making a multi-year commitment to something a vendor can sunset, reprice, or fold into a suite at will. One survey this year found most UK IT leaders would happily consolidate onto a single platform if it met their needs. The appetite is real. The exposure that comes with it is the part the survey does not price.

Here is the reframe. Split your observability into two layers and be honest about which one you actually own.

The bottom layer is the signal: how your systems are instrumented and how telemetry is collected. Build that on an open standard, OpenTelemetry for application instrumentation, eBPF for agentless collection at the kernel, and your signal is portable. You instrument once and send that telemetry to any backend that speaks the standard. OpenTelemetry is now the vendor-neutral lingua franca for traces, metrics and logs, and it is not a theory: teams run it in production every day.

The top layer is the platform: the backend that stores, queries and visualises the signal. That is the layer you rent, and renting it is a perfectly good decision, as long as you have not welded your instrumentation to it. When the contract, the pricing, or the vendor changes, and it will, you repoint your pipeline and carry on. You change the platform without changing the plumbing.

Own the signal. Rent the platform. That one distinction turns a re-migration into a reconfiguration.

This is not a free lunch, and I would not be doing my job if I pretended it was.

Owning the signal is real work. OpenTelemetry moves the effort from the vendor's agent to your own instrumentation and your own Collector, and running the Collector well at scale, with sensible sampling and pipelines, is a genuine engineering commitment. Ask anyone running it in production and they will tell you the Collector is where the operational reality lives. eBPF buys you breadth without code changes, but carries its own caveats around kernel versions and coverage.

Portability is directional, not absolute. Open instrumentation makes moving between backends far cheaper. It does not make it free. Semantic conventions are still settling, some capabilities lean on backend-specific features, and you still rent storage and query somewhere. “Own the signal” does not mean observability is now free. It means the expensive, slow, political part, re-instrumenting a whole estate, is the part you stop repeating.

That trade is worth making. You are choosing a known, upfront engineering cost over an open-ended, recurring lock-in cost. For most enterprises, that is the right side of the ledger.

You do not prove this with a big-bang migration. You prove it on a slice.

Pick a handful of applications that actually matter, wrap a defined pilot window around them, and instrument that slice on the open standard. Send the telemetry to your current platform first, so nothing breaks. Then prove you can repoint it to a second backend without re-instrumenting a thing. That is the whole thesis, demonstrated in miniature, at low blast radius.

And measure the pilot honestly. A hard return-on-investment figure on a consolidation takes too long to land to be your only yardstick, so watch a softer signal alongside it: are the people using the new view actually happier with it? Are they finding answers faster, reaching for it first? If the engineers who live in the tool prefer it, you have something real, well before the finance case fully closes.

There is a wider mood worth naming. Info-Tech's mid-year 2026 report put it plainly: after two years of chasing AI, CIOs are being pushed back to IT fundamentals, resilience, cost discipline, getting the basics right. Observability consolidation is exactly that kind of fundamentals exercise. It is not a headline platform swap, and it is not an AI feature you can buy. It is the unglamorous work of deciding what you own and what you rent, and building your signal so it outlives whichever logo is on the dashboard this year.

Own the signal. Rent the platform. Everything else is a renewal you have not had yet.

Does “own the signal” mean self-hosting everything? No. You can still buy a managed backend. Owning the signal is about the instrumentation and collection layer being open and portable, not about running every component yourself.

Is OpenTelemetry mature enough to standardise on? For traces and metrics, yes, it is widely used in production. Logs are further behind but moving. Standardise where it is strong and let the rest follow.

What about eBPF? It is a powerful way to collect telemetry without changing application code, useful for breadth, with caveats around kernel support. Treat it as complementary to OpenTelemetry, not a replacement.

We already have five tools. Where do we start? One high-value slice, one pilot window. Instrument on the open standard and prove you can repoint the backend. Consolidate the platform after you own the signal, not before.

Sources: Google Cloud Observability pricing (cloud.google.com/products/observability/pricing); Info-Tech Research Group, Best of 2026 Mid-Year Report (June 2026); OpenTelemetry (opentelemetry.io).