Observability stacks and the new lock-in surface

Observability, in practice, is an organization’s ability to work out what a running system is doing. The raw material for that is telemetry: signals such as logs, metrics and traces emitted by applications and infrastructure.

But almost nobody operates on raw telemetry. What an operations team actually uses is everything built on top of those signals — the queries that retrieve the relevant slice, the dashboards that arrange it, the alert rules that decide when it matters, the label and metadata conventions that make it joinable, the integrations that route it into ticketing and paging, the incident practices that turn a signal into an action, and the accumulated knowledge held by the people who have used the system through past failures.

If the underlying telemetry can move, does the organization’s ability to interpret and act on it move as easily?

That is the question of this paper. It is deliberately not answered here, and the answer is not assumed to be no. Open standards have changed this landscape materially, and any honest treatment has to start there.

OpenTelemetry describes itself as a vendor-neutral, open-source observability framework for instrumenting, generating, collecting and exporting telemetry data — traces, metrics and logs (OpenTelemetry documentation). The OpenTelemetry Collector is documented as a vendor-agnostic way to receive, process and export telemetry, able to send data to one or more open-source or commercial backends (Collector documentation).

This is a genuine reduction in dependency, and it should be stated plainly rather than hedged. Instrumentation can be built against vendor-neutral OpenTelemetry APIs and SDKs rather than a proprietary agent interface, while OTLP provides a standardized path for transporting telemetry. A collector sitting between the estate and the backend means the destination can, in principle, be changed without re-instrumenting the applications that produce the data.

Take a documented example. Grafana Loki uses its own query language, LogQL, to query stored logs (Loki query documentation). That is a factual property of one system, chosen here because it is clearly documented. It is not a criticism of Loki, and the mechanism described below is not specific to it: query languages differ across backends generally.

The System Drift interpretation concerns what queries become over time. A mature query is rarely a search. It encodes operational knowledge: how this team identifies a particular class of failure, how it isolates one service from its neighbours, which labels are trustworthy enough to filter on, how an error rate is calculated in this estate specifically, and what shape of output counts as abnormal.

A telemetry stream may be portable while the queries through which an organization understands that telemetry remain tied to a particular query model.

This is an analytical claim about structure, not a measurement. What can be said as fact is only that backends expose distinct query languages and that operational queries are written against them.

Grafana documents that LogQL queries can be used to build persistent Grafana dashboards over Loki data (visualizing Loki data in Grafana). Again, the documented fact is modest. The analytical point is about what accumulates.

A dashboard is not a view of data. It is a set of decisions that somebody made and nobody has since had reason to revisit: which signals are worth watching, which queries retrieve them, how they are transformed and aggregated, what thresholds are drawn, which variables parameterise them, which services are shown adjacent to which others, and how all of that is arranged for someone reading it at three in the morning.

System Drift’s interpretation: moving the telemetry does not automatically recreate the operational representation built around it. The data may arrive intact at a new backend while the organization’s way of looking at that data does not travel with it. We make no claim about how much effort or cost such reconstruction involves — we have no evidence that would support a figure, and we decline to estimate one.

Grafana documents that Grafana-managed alert rules can be created from LogQL metric queries against a Loki data source, and that Loki can also store and evaluate data-source-managed alert rules (Loki alerting documentation).

The structural consequence is worth stating carefully. An alert rule is operational logic. It asserts: when this specific condition appears in this specific data, treat it as significant enough to interrupt a person. Each rule can encode a small piece of institutional judgement: which condition matters, where its threshold sits, and when it warrants interruption. Where that logic is not reproduced elsewhere, the alert configuration itself becomes one place in which that judgement is retained.

The System Drift interpretation is that as alert rules accumulate, a portion of the organization’s operational knowledge comes to reside inside the observability platform — expressed in that platform’s query semantics, and evaluated by its machinery. Where those rules are stored and evaluated is a documented, checkable property of a deployment; what their accumulation implies for dependency is our analysis.

There is one directly relevant documented data point. Grafana compares Loki’s older OpenTelemetry-exporter path with its native OTLP endpoint, and notes that moving to native OpenTelemetry ingestion can require LogQL queries to be rewritten — including queries embedded in dashboards, in alert rules, and in saved or starred queries in Grafana Explore (native OTLP endpoint versus Loki exporter).

That is a vendor-documented fact, and it is unusually useful because it describes a change within an OpenTelemetry-compatible environment. No supplier is being replaced. The telemetry is not being stranded. Only the ingestion path and the resulting representation change — and the effect propagates upward into dashboards, alerts and saved queries.

Even inside an OpenTelemetry-compatible environment, changing how telemetry is represented can propagate into the operational layers built on top of it.

The limits of this evidence should be stated as clearly as the evidence itself. This is one documented case, in one system, concerning one ingestion change. It does not establish that observability migrations generally require extensive rewriting, and this paper does not claim that. What it does establish is that telemetry portability and operational portability are not the same property — because here the first was preserved and the second was not automatic.

A useful way to hold the whole picture is as a chain:

Instrumentation → Collection → Transport → Storage → Query → Dashboard → Alert → Operational practice

OpenTelemetry addresses the left-hand side of that chain substantively: instrumentation, collection and transport, with the Collector explicitly positioned as a vendor-agnostic layer able to export to multiple backends (Collector documentation). System Drift’s question concerns what happens further right.

The progression matters because each step adds organizational meaning to data that was, at the left-hand end, generic:

• a trace is data;
• a query expresses how the organization interrogates that data;
• a dashboard expresses what it has chosen to watch;
• an alert expresses what it considers important enough to act upon;
• an incident practice expresses what people have learned to do when those signals appear.

The proposition this paper advances is that dependency deepens along that progression — not because the artefacts are proprietary in any legal sense, but because each one is increasingly specific to the organization and to the platform’s semantics at the same time. This is the accumulation pattern described in R-001, appearing in the operational tooling layer.

At the far right of the chain is something that is not stored in any system: what the people operating it have learned.

Engineers who have run an observability platform through several incidents accumulate a working model of it. They know where particular signals appear and where they are unreliable. They know which query exposes a particular failure mode quickly. They know which dashboards are trusted and which have quietly drifted out of date. They know which alerts are noisy and are, in practice, ignored. They know which labels are applied consistently. They know which combination of signals means a real incident rather than a deploy.

The deepest observability dependency may not be the telemetry format. It may be the accumulated organizational knowledge built around interpreting that telemetry.

This is offered as an analytical proposition, not a measured finding. System Drift has not surveyed engineers, timed onboarding, or measured incident performance across a platform change, and no such evidence should be read into the paragraphs above. The proposition is falsifiable in principle and, to our knowledge, has not been tested publicly. It is stated here because it follows from the structure of the preceding sections, not because it has been demonstrated.

The narrow definition of observability portability is: can we export the telemetry? Judged by that standard, the situation has improved enormously, and OpenTelemetry deserves the credit.

A more useful question is whether an organization could change observability platform while preserving instrumentation, telemetry, useful historical context, its important queries, its dashboards, its alert logic, its integrations, and the operational understanding that ties those together.

This distinction is the analytical contribution of R-004, and it connects directly to F·02 Reversibility and to F·05 Exit Complexity: an exit that preserves the data but not the operating capability is not a completed exit.

These are diagnostic questions rather than recommendations. Most are answerable from an organization’s own configuration.

• Which parts of our telemetry pipeline use open standards?
• Which components depend on platform-specific formats or semantics?
• How many of our operationally important queries depend on one query language?
• Which dashboards would need reconstruction if the backend changed?
• Where are alert rules stored, and where are they evaluated?
• Which integrations depend on platform-specific behaviour rather than a standard interface?
• Can historical telemetry be moved, or queried, somewhere else?
• How much operational knowledge exists only inside dashboards, alert rules and team habit?
• If the telemetry backend changed tomorrow, what would remain usable on day one?

System Drift does not attach scores to these questions. Any numerical index here would imply a measurement basis that does not exist.

OpenTelemetry materially improves the portability of observability data and collection. That is a real counterforce to dependency, and this paper should not be read as diminishing it. But it does not make an observability environment automatically portable. Dependency can migrate upward — out of agents and telemetry formats, into queries, dashboards, alerts, integrations and the knowledge of the people who use them.

Read against System Drift’s wider research, the interesting form of lock-in is not necessarily the inability to extract data. It may be the increasing difficulty of reconstructing the operational meaning built around that data — a difficulty that may grow as more queries, dashboards, alerts and operating practices accumulate around the platform. That is the same mechanism described in R-003 arriving through a different layer.

Nothing here implies that proprietary functionality is undesirable or that vendors design for entrapment. Query languages, dashboards and alerting engines are differentiated products doing useful work, and the accumulation described above is a by-product of using them well. The subject of this paper is structural dependency, not vendor intent.