Keep Your Observability Stack Replaceable with OpenTelemetry

The worthwhile OpenTelemetry strategy is to make the Collector, not the observability supplier, the point at which telemetry leaves your systems. That gives teams room to test another backend or change course without turning a platform decision into a service-by-service rewrite.

That boundary is valuable, but it isn’t magic. OpenTelemetry won’t carry saved dashboards, query languages, alerting models, retention policies or a vendor’s correlation features to the next platform. What it can make portable is the collection and meaning of much of the raw telemetry. Get that distinction right and an organisation can test alternatives properly, negotiate harder and avoid starting again in source code.

Start with the dependency you already have

When an application uses a supplier’s tracing SDK (software development kit) directly, emits proprietary metric names and sends data to that supplier’s ingestion endpoint, the observability platform is embedded in the estate. Replacing it is more than a credentials change. Instrumentation, deployment manifests, agents, service naming and alert thresholds may all need attention at once.

OpenTelemetry breaks that dependency into layers. Application code can use its APIs (application programming interfaces) and SDKs, or automatic instrumentation where that fits; it can export telemetry using OTLP, the OpenTelemetry Protocol; and a Collector can receive, process and forward that data to one or more destinations. OTLP defines the delivery mechanism between telemetry sources, collectors and backends, with stable support for traces, metrics and logs. Profiles remain a development-status signal, so don’t treat them as equally mature in a portability plan. The OTLP specification is the contractual layer that matters here. (opentelemetry.io)

None of this requires removing every existing agent on day one. It does mean making a deliberate choice: new application instrumentation should normally speak an open protocol to an endpoint you control, rather than making a backend agent part of the application’s permanent architecture.

Put the boundary at the Collector

The OpenTelemetry Collector is the practical hinge point: a vendor-agnostic service for receiving, processing and exporting telemetry. Its pipelines consist of receivers, optional processors and exporters, and exporters can fan out the same data to more than one destination. Applications can keep sending to one OTLP endpoint while a centrally managed configuration changes the backend route. The Collector architecture documentation sets out that receiver-to-processor-to-exporter model. (opentelemetry.io)

In a small environment, sending OTLP straight to a backend may be entirely sensible. Across a larger estate, a Collector beside workloads or at a gateway is usually the better control point for batching, retries, credentials, filtering and routing. The OpenTelemetry project recommends a Collector alongside services in general, while recognising that direct export is reasonable for getting started or small-scale use. Its Collector guidance also makes the less glamorous point: the Collector is another system to run, monitor and secure. (opentelemetry.io)

A gateway pattern, in which a central Collector receives telemetry before forwarding it to backends, is particularly useful when applications span Kubernetes, virtual machines and managed services. Services send to a stable internal OTLP address; gateways hold backend credentials and export rules. That keeps a commercial supplier’s ingestion keys out of application configuration, while providing one place to redact fields, limit noisy attributes and apply a consistent sampling policy.

There is a cost to that control. A gateway adds latency, cost and a failure domain. OpenTelemetry’s deployment guidance notes the operational overhead and warns that multi-stage Collector designs need deliberate routing when policies such as tail sampling require every span in a trace to reach the same processing point. The gateway deployment pattern is a design reference, not an excuse to build a complex hierarchy by default. (opentelemetry.io)

Define telemetry that belongs to you

It does mean making a deliberate choice: new application instrumentation should normally speak an open protocol to an endpoint you control, rather than making a backend agent part of the application's permanent architecture.

Transport portability is only half the job. Data arriving over OTLP with arbitrary, backend-shaped names is still awkward to move, because dashboards and alert rules will be built around those names. OpenTelemetry semantic conventions provide common names for resources, operations and attributes across traces, metrics and logs. Use them where they fit, especially for service identity, HTTP, database and messaging activity. The semantic-conventions documentation explains their role as a shared naming scheme. (opentelemetry.io)

Each organisation also needs a small telemetry contract of its own: mandatory resource attributes, approved business dimensions, rules for tenant, customer and user identifiers, and fields that must never leave a workload. Keep that contract in version control alongside Collector configuration, not in a vendor’s point-and-click configuration screen.

This is where discipline matters more than another agent. A stable service.name helps. A new metric label containing an unbounded customer ID is a bill and a performance problem waiting to happen. Set cardinality limits before the first large rollout, then remove or aggregate unwanted attributes in the pipeline where possible. The Collector supports processors for transformation, filtering, enrichment and redaction, but component maturity varies. Check production choices individually rather than assuming they are stable because they carry the OpenTelemetry name. (opentelemetry.io)

What remains vendor-specific

Observability suppliers often present OpenTelemetry ingestion as if it settles the lock-in question. It doesn’t. A backend can accept OTLP while keeping its most differentiated capabilities proprietary.

• Queries and dashboards: the data may arrive in a standard form, but the query language, dashboard format and visualisation behaviour are normally backend-specific.
• Alerts and incident workflows: alert evaluation, notification routing, service catalogues, on-call integration and access controls are operating models, not portable telemetry.
• Derived data: vendor-created service maps, anomaly detection, trace-derived metrics and dependency analysis may not reproduce exactly elsewhere.
• Metrics semantics: backends differ in how they ingest histograms, exemplars, aggregation temporality and high-cardinality series. OTLP has a carefully defined metrics model, but translation does not assure that every downstream product exposes identical behaviour. (opentelemetry.io)
• Retention and cost: storage periods, rehydration, indexing limits and pricing are commercial choices. OpenTelemetry can’t make an expensive telemetry design inexpensive.

Automatic instrumentation is an accelerant, not a substitute for application knowledge. It commonly instruments libraries such as HTTP clients, database drivers and message queues, but it doesn’t normally understand business operations in an application’s own code. Important events such as “quote accepted”, “payment authorised” or “report generated” still need deliberate manual spans, metrics or logs. A span is an individual timed operation within a trace. OpenTelemetry’s zero-code guidance is explicit about that limitation. (opentelemetry.io)

A migration approach that leaves a way back

Don’t begin by moving the whole observability platform. Pick a small service group with representative traffic, meaningful traces and tolerable risk. Replace direct backend export with OTLP to a Collector, normalise service identity and semantic attributes, then export to the current backend. Users needn’t see a difference yet, but the application-to-backend dependency has been cut.

Then run a time-limited dual-export test. Send the same carefully governed telemetry to the incumbent and candidate backend, and compare what operators actually need: trace continuity, error-rate and latency metrics, log correlation, alert behaviour, search speed, access boundaries and expected spend. Collector pipelines can fan out to multiple exporters, but don’t casually double every high-volume log stream. This is a controlled migration exercise, not a standing invitation to pay twice.

Keep sampling policy visible. Head sampling, decided in the SDK before a trace leaves the application, is cheap but can’t know whether a request will later fail or run slowly. Tail sampling at a Collector can make better decisions from a complete trace, but it needs state, capacity planning and consistent trace routing. Often, a modest baseline sample plus rules that retain errors and slow requests is better than an elaborate policy nobody can explain at 03:00.

For metrics, validate rate calculations and histogram percentiles rather than merely checking whether metric names exist. Temporality and aggregation choices affect what a backend can calculate. The OpenTelemetry metric model supports cumulative and delta representations and specifies some transformations, but it is not intended as a perfect universal conversion layer between every legacy format. (opentelemetry.io)

Design rollback and validation before cutover

A credible rollback is straightforward: applications continue exporting OTLP to the same Collector endpoint, and a reviewed configuration change restores the old exporter route. That is materially safer than asking dozens of teams to reverse SDK or agent changes under pressure. Store Collector configurations in source control, promote them through the same environments as application changes, and test configuration validation before deployment.

Validation needs more than a green ingestion counter. Choose known transactions and confirm that trace parentage remains intact, resource attributes stay consistent, logs correlate with trace context where expected, and alert thresholds behave as intended. Check for duplicate metrics and broken rate graphs after a route change. OpenTelemetry’s gateway guidance highlights the single-writer principle for metric streams: overlapping writers can cause data-quality problems and backend ingestion errors. (opentelemetry.io)

Before you buy an “OpenTelemetry-native” platform

The last question isn’t pedantry. OpenTelemetry publishes several Collector distributions, including third-party distributions, and says it does not validate or endorse those third-party options. A vendor distribution may be convenient, but it is another dependency worth assessing. The Collector distributions list helps identify that distinction. (opentelemetry.io)

Portability is a design choice

OpenTelemetry gives enterprises a common language for instrumentation and a practical routing layer for telemetry. That’s an improvement over tying every workload to one supplier’s libraries and endpoints. The benefit only holds, though, when teams keep a clean OTLP boundary, standardise their data, own their Collector configuration and budget for the work that genuinely isn’t portable.

Use OpenTelemetry to turn a backend change into an engineering project with a known scope, rather than a forensic exercise across every application. It’s a more modest promise than much observability marketing. It is also a useful one.