OpenTelemetry Standard vs Vendor Observability Boundaries

TL;DR

OpenTelemetry splits into four package types — API, SDK, Semantic Conventions, and Contrib — and only the API is a true cross-cutting dependency; everything downstream is swappable in principle. Signals (traces, metrics, logs, baggage) run independently but share one context-propagation mechanism, which is what makes cross-signal correlation possible at all. The Collector can run as a local Agent or a standalone service, and in both modes it absorbs retries, batching, encryption, and sensitive-data filtering so application code doesn't have to. The Collector's own stability is officially "mixed" — components mature at different rates, so portability guarantees are uneven even within the standard. None of this touches what a vendor backend does with the data once it's ingested: storage, query language, alerting, and pricing model are 100% vendor territory, and that is where lock-in actually lives. For a concrete booking decision, a short architecture review can test those portability assumptions against your own stack. For a related Netics view on production architecture, see Netics AI agent architecture analysis.

What the standard actually standardizes

OpenTelemetry gets pitched as "vendor-neutral observability," which is true but underspecified. The spec is neutral about how telemetry is produced and transported. It is silent about what a backend does with it afterward. Understanding that boundary matters more than the marketing line, because it tells you exactly which parts of an observability stack you can change later without a rewrite, and which parts you're committing to for good.

The overview spec breaks each signal into four package types. API packages are the cross-cutting public interfaces — the calls that get imported directly into application and library code. SDK packages are OpenTelemetry's own implementation of that API, installed and configured by whoever owns the application, not by library authors. The spec is explicit on this split: instrumentation authors "MUST NOT directly reference any SDK package of any kind, only the API." That's not a style preference — it's the mechanism that lets a library ship OpenTelemetry instrumentation without dragging in a specific exporter, sampler, or backend choice.

Semantic Conventions are the third piece: shared keys and values for describing common concepts (an HTTP request, a database call, a Kubernetes pod) so that a span produced by one library and one produced by another use the same attribute names. They live in a separate repository from the client libraries, generated from YAML definitions treated as source of truth.

Contrib packages are the fourth category and the one most likely to blur the boundary. These are optional integrations — instrumentation for a specific web framework, exporters for a specific backend — maintained by the OpenTelemetry project but outside the SDK core. The spec draws a further distinction here worth sitting with: some plugins, like OTLP exporters and TraceContext propagators, are defined by the specification itself and count as Core packages, even though they ship as separate artifacts. Contrib, properly speaking, is everything optional and separate from the SDK. The practical read: an integration living in the "contrib" namespace doesn't automatically mean it's a Netics- or vendor-specific extension — check whether it's Core (spec-defined, portable) or genuinely optional before assuming either way.

Signals and the propagation layer that ties them together

Tracing, metrics, and baggage are described as three separate signals that "function independently from each other" but share one underlying context-propagation mechanism. That's the part that makes OpenTelemetry more than three unrelated SDKs bolted together. A trace ID generated in one service and propagated across a network boundary is what lets a metric recorded downstream, or a log line written in a completely different process, get correlated back to the same logical request.

The mechanics: a Span carries a SpanContext — a TraceId, SpanId, TraceFlags, and a Tracestate field that specifically exists so different vendors can attach their own tracing-system-specific data and interoperate with legacy ID formats. Propagation across process boundaries happens through a Propagator, and the spec currently defines one type — TextMapPropagator — for serializing these values into and out of carriers like HTTP headers.

Baggage is a related but distinct mechanism: name/value pairs propagated alongside a trace, intended primarily to feed values into OpenTelemetry's own observability signals (tagging metrics, adding context to logs) rather than to carry arbitrary application state. The spec's own caution here is worth repeating verbatim in spirit: it can be used to prototype other cross-cutting concerns, but new use cases with different requirements should generally get their own mechanism rather than overloading Baggage.

Collector: agent mode, standalone mode, and what it takes off your hands

The Collector is the component most often confused with "the vendor platform," and it's worth being precise about why it isn't one. The docs describe it as a vendor-agnostic way to receive, process, and export telemetry, and it has two primary modes of operation: Agent — a daemon running locally alongside the application — and Collector, a standalone running service. Same codebase, same configuration model, different deployment topology.

The documentation is direct about when a Collector earns its complexity: for getting started, or for a small-scale environment, sending telemetry directly from application to backend works fine. The recommended reason to add a Collector in front of that path is that it lets the application offload data quickly and hands the Collector responsibility for retries, batching, encryption, and even sensitive-data filtering — work that would otherwise sit inside application code, competing for the same CPU and memory budget as the thing actually being observed. Default OTLP exporters in each language already assume a local collector endpoint, so standing one up is closer to flipping a switch than standing up new infrastructure.

The stability boundary the standard doesn't hide

One fact from the source works against the "OpenTelemetry is a clean, uniform standard" pitch, and it belongs in this article rather than being smoothed over: the Collector's documented status is mixed, specifically because "core Collector components currently have mixed stability levels." Each component's maturity is documented in its own README, and there's a public registry to check before depending on one. Support commitments — including minimum guarantees like critical bug and security fixes — are scoped per artifact based on its intended audience, not applied uniformly across the whole Collector.

This matters operationally more than it sounds. "OpenTelemetry-compliant" is not a single stability guarantee. A receiver or exporter you pull from Contrib might be production-hardened, or might be early-stage with no stability commitment at all. Checking the component's individual status before it goes on a critical telemetry path is not optional caution — it's what the spec itself tells you to do.

Where the vendor boundary actually sits

Put the pieces together and the boundary is narrower than "OpenTelemetry vs. proprietary" suggests. The API, the Semantic Conventions, the context-propagation model, and the Core Collector components (OTLP exporters, TraceContext propagators) are all specification-defined and, in principle, backend-agnostic. Switching what backend a Collector exports to is a configuration change, not a rewrite — because the Collector already sits between instrumented code and any specific vendor.

What the standard does not touch, and cannot touch by design, is everything on the far side of ingestion: how a backend stores traces, what query language it exposes, how it prices retention and cardinality, what its alerting model looks like, and which of its own dashboards and correlation features only work with data shaped a particular proprietary way. A vendor can be fully OTLP-compliant on ingestion and still build meaningful lock-in one layer up — through query language, retention pricing, or backend-only enrichment features that don't travel if you export elsewhere. Standard-compliant ingestion is necessary for portability. It is not sufficient for it.

Take a concrete case. Imagine a Casablanca logistics SME running a handful of Node.js services with growing traffic during peak shipping windows. If their engineers instrument with the OpenTelemetry API and Contrib libraries for their framework and database client, and route everything through a self-hosted Collector rather than exporting directly to one vendor's proprietary agent, the choice of backend becomes a Collector-config edit, not a re-instrumentation project. If they'd skipped the Collector and pointed application code straight at a vendor SDK, moving backends later would mean touching every service.

Netics analysis

The commercial incentive here is straightforward and worth naming plainly: vendors have every reason to be OTLP-compliant at the front door, because compliance is now a checkbox buyers screen for, and very little reason to make their backend's differentiated features (their query language, their AI-driven anomaly detection, their pricing-favorable data model) portable to a competitor. That's not a criticism of OpenTelemetry — it's a description of where the economic pressure in this market actually points. The standard did its job by making the production and transport of telemetry boring and interchangeable. It was never going to standardize the parts vendors compete on, because that's the part they get paid for.

The practical consequence for anyone choosing an observability stack: evaluate vendors on what happens after ingestion, not on whether they support OTLP. Nearly everyone does, or will soon. The real diligence question is what you lose — in query capability, correlation, or cost — if you point the same Collector config at a different backend next year.

Booking

Auditing where your telemetry pipeline actually locks you in, versus where it's genuinely portable, is a scoping exercise worth doing before a vendor contract renews rather than after. Book a slot with Netics to walk through your current OpenTelemetry setup.

*Sources: Overview | OpenTelemetry, Collector | OpenTelemetry — opentelemetry.io, retrieved 2026-08-31.