Ideas
Standardise the collection, not the tool
With OpenTelemetry, the standard belongs in what touches every service, its instrumentation and its collector, and the backend becomes a choice each team can change
Most observability programmes start by choosing the backend. One platform, one licence for everyone, and every team migrates to it. Then the licence comes up for renewal, or a team needs what the platform does not do, and the migration starts again, in every application.
That is the wrong layer to standardise. What is expensive in observability is not the dashboard but the instrumentation, because it lives in the code of every service. That is where a standard pays.
OpenTelemetry gives that layer a shape. Applications produce traces, metrics and logs through its SDKs or agents and send them, ideally over a single protocol, OTLP, to a collector. The collector receives, processes and exports: it can filter, batch, strip sensitive attributes, and send the same data to one backend or to several.
The collector is the seam. Code on one side, tools on the other, and neither knows the other
So the standard I set is the collection: telemetry leaving every service the same way, one collector per environment, close to the applications and sized per business domain, sensitive data filtered there before it leaves, several collectors behind a gateway in production. None of this is negotiable, because every team depends on it.
Behind the collector, the backend can vary. In the reference architecture I drew up this year, the same collection layer exports to an OpenSearch stack or to a Grafana stack with Loki, Tempo and Mimir, and leaves room for other tools. Nothing requires the same tool in every environment, and commercial suites are expensive: a team or an environment picks what it needs, or changes it, by editing an exporter, not its code.
This does not mean letting every team choose everything. One layer is fixed so that the others can move.
Freedom on the backend is earned by discipline on the collection