What creates instrumentation lock-in across a service fleet, and what would you standardise to reduce it?

## Three layers, three very different costs "Lock-in" is usually discussed as though it lived in the code that emits telemetry. It rarely does. An instrumentation estate has three layers, and their migration costs differ by orders of magnitude. | Layer | What it is | Cost to move | | --- | --- | --- | | Emission | The agent attached, or the calls in your code | A redeploy per service — bounded, mechanical | | Transport and pipeline | The wire format and whatever sits between apps and storage | A translation or a re-point — bounded, one team | | Derived assets | Dashboards, alert rules, saved searches, runbook links, reports | Unbounded, spread across every team, and nobody has an inventory | Almost everyone underestimates the third row, because it is the only one not represented in a repository anybody owns. The dashboards were built over four years by people who have moved on. The alert rules encode judgement nobody wrote down. Each of them hardcodes span names, metric names and attribute keys — and that, not the agent binary, is what actually holds you in place. ## Why the vocabulary is the portable asset Every derived asset is a query, and every query names things. Which means the property that makes an estate movable is not which mechanism produced the telemetry but whether the same concept is spelled the same way everywhere. Consider three services in one fleet describing the same HTTP outcome as `http.status_code`, `httpStatus` and `resp_code`, and the same customer as `tenant.id`, `school` and `org_id`. Nothing is broken. Each service's own dashboard works. But no single alert rule covers all three, no fleet-wide query is possible, and a migration must be negotiated service by service because there is no shared thing to port. Now invert it. If the fleet spells each concept one way, the derived assets are portable in the only sense that matters: they must be re-authored in the new query surface, but they are re-authored against the same names, mechanically, by one team, in a known amount of time. **A consistent vocabulary converts an unbounded organisational migration into a bounded engineering task.** That is why naming discipline is worth more than mechanism choice, and it is the answer interviewers are listening for. ## What to standardise — and what to leave alone Standardise: 1. **Service identity** — one spelling of what a service is called, and it must match what deploys and pages call it. 2. **Operation naming** — low-cardinality names for the units of work, so a name is a groupable thing rather than a unique string per request. 3. **Outcome** — one key for status and one convention for what counts as an error, because every alert rule in the estate reads it. 4. **The two or three business dimensions everyone slices by** — tenant, region, plan — spelled identically in every service. 5. **Units** — pick milliseconds or seconds and never mix them within one concept. Leave alone: which mechanism each service uses, and the internals of any one service's own spans. A batch job in one language and a request service in another can be instrumented completely differently and still be perfectly portable, as long as they agree on the five things above. Standardising mechanism is the seductive wrong answer — it is highly visible, it generates a long migration, and it buys much less portability than agreeing on names. ## Making the vocabulary hold Publishing a naming document changes nothing on its own. What works is making the standard the path of least resistance and then checking it: - Ship a shared library or base configuration that emits the agreed keys by default, so the standard is what you get by doing nothing. - Do the rewriting in one place where possible, so a service that got a key wrong is corrected without a fleet-wide code change. - Check emitted names against the agreed list automatically and report drift to the owning team, rather than discovering it mid-incident. - Keep the list short. Twelve keys get followed; two hundred is a document. ## The evidence test A useful way to size real portability: suppose a regulator asks for six months of evidence about a service's behaviour, and the backend changed three months ago. What has to be true? The **names** must be identical either side of the change, or the two halves cannot be compared at all. The **data** must be exportable in a form readable without the vendor's own interface. And **retention** must be a decision you own rather than one you inherit from whatever tier you happen to be on. If any of those three is false, the answer is that the evidence does not exist — and that is a lock-in cost measured in obligations, not in engineering days. ## Where accepting lock-in is rational Not all of it is worth fighting. The query and visualisation surface is where a product's value actually lives, and re-authoring queries is bounded work once names are stable, so binding to one is a reasonable trade. What is not reasonable is letting the emission vocabulary fragment: that cost is unbounded, paid by every team rather than one, and it grows every quarter you defer it. Standardise the names, stay relaxed about the mechanism, and treat the derived assets as an inventory you must be able to count.