OpenTelemetry forces you into real decisions: control planes, sampling, routing, and architecture.
OpenTelemetry Has Won. Now the Hard Part Begins.
The instrumentation wars are over. OpenTelemetry is the standard. What that means for your vendor relationships, your architecture decisions, and your team’s operational capacity is a more complicated story than the conference slides suggest.
For years, observability teams had to make a consequential choice early. Pick a vendor, install that vendor’s agents, adopt that vendor’s data model, build dashboards around that vendor’s assumptions, and hope the platform still made sense three years later when the contract renewed. The cost of switching backends was never measured in licensing fees. It was measured in weeks of re-instrumentation work, broken dashboards, and the organizational risk of degraded visibility during the migration window. Vendors knew this. Pricing reflected it.
OpenTelemetry broke that dynamic.
By early 2026, the CNCF had classified OpenTelemetry as the second most active project in its portfolio by contributor count, trailing only Kubernetes. The OTel Collector was processing over 10 billion daily spans across known public deployments, a four-fold increase from 2023. That is not a niche standard gaining traction at the edges. That is an industry realignment that has already happened.
The central thesis here is straightforward: OTel protects the most expensive part of observability, which is the instrumentation work distributed across every service, every team, and every deployment pipeline. Once that layer is decoupled from any single vendor, the commercial decision shifts. Vendors must compete on the quality of their analytics, intelligence, and operational experience rather than on the cost of your exit. That is structural leverage, and understanding which vendors have genuinely embraced the standard versus bolted it onto a proprietary architecture is where the real practitioner work begins.
The Architecture Distinction That Actually Matters
OpenTelemetry is a vendor-neutral, CNCF-backed framework for collecting, processing, and exporting telemetry: traces, metrics, and logs. The SDKs instrument application code and emit telemetry in the OpenTelemetry Protocol, OTLP. The Collector receives that telemetry, applies processing rules, and routes it to one or more backends. The Semantic Conventions define a shared vocabulary for what spans, metrics, and resource attributes mean across systems.
The distinction practitioners must internalize is between ingestion and export. Ingestion means the vendor accepts OTLP at its intake layer before converting it to their internal model. What happens to the data afterward is the vendor’s decision, and that decision carries real consequences for fidelity, queryability, and translation loss. Export means the OTel Collector acts as the central telemetry control plane, handling routing, sampling, enrichment, and fanout. Your application instrumentation does not move when your backend does. Changing vendors becomes a Collector configuration change, not an engineering program.
When a vendor says “we support OpenTelemetry,” the next question should be: how? Specifically: Do you require your own agent, or can I use the upstream Collector? Do Semantic Conventions survive your intake intact? Can I route the same telemetry to a second backend? What happens to my dashboards and alerts if I need to migrate in two years? These are not theoretical questions. They determine whether OTel is functioning as a real portability layer or merely as another input format.
How the Major Vendors Actually Relate to OTel
The vendor landscape has sorted into two categories: platforms built before OTel existed that have added OTLP support as an ingestion path, and platforms built with OTel at their core. The distinction matters because it determines what survives translation and what the data looks like after it crosses the vendor’s intake boundary.
Datadog ingests OTLP directly through its Agent or any upstream-compatible Collector, with no Datadog-specific exporter required at the edge. Datadog has CNCF board representation, repo maintainers across multiple specification groups, and active upstream contributions. What Datadog does not do is store telemetry in an OTel-native format. Once data enters Datadog’s backend, it is translated into Datadog’s internal conventions. Some contextual richness from OTel’s Semantic Conventions does not survive that translation intact. For teams that value Datadog’s correlation depth and full-stack coverage across APM, RUM, synthetics, security, and infrastructure, that tradeoff is often worth accepting. The key is accepting it deliberately. Best fit: organizations that want a polished managed platform with fast time to value and broad integrations. Watchpoint: use OTel instrumentation and a Collector-based architecture to preserve leverage if costs rise or a second backend becomes necessary.
Dynatrace accepts OTLP through its OpenPipeline layer alongside its proprietary OneAgent. Its differentiation is automated operational intelligence: Davis AI performs root cause analysis, and OneAgent delivers automatic topology discovery. For organizations where automated dependency mapping matters more than hand-building every query path, Dynatrace delivers outcomes that vendor-neutral stacks require substantial engineering to replicate. Best fit: large enterprises with complex estates and a need for automated incident intelligence. Watchpoint: decide intentionally where vendor-native intelligence ends and vendor-neutral portability begins.
New Relic made an early public commitment to OTLP as a first-class ingestion path. OTLP data lands in New Relic’s proprietary NRDB storage and is queryable via NRQL. For teams modernizing from older APM agents, New Relic functions as a bridge: move instrumentation toward OTel while keeping a managed commercial backend in place. Best fit: teams that want managed observability with a transparent path from proprietary agents toward OTel-based telemetry. Watchpoint: per-user seat pricing compounds at scale, and portability depends on how much logic accumulates in vendor-specific dashboards and alerts.
Honeycomb is purpose-built for high-cardinality event analysis and trace debugging. Its onboarding assumes OTel-first instrumentation, though incoming data is converted into Honeycomb’s own event-based model at the storage layer. Best fit: engineering teams that need deep trace analysis and fast investigation of unknown behaviors in complex distributed systems. Watchpoint: narrower coverage breadth than full-stack platforms; a cultural shift may be required for teams expecting traditional infrastructure dashboards.
Splunk supports OTel through its distribution of the OTel Collector, routing traces to Splunk APM, metrics to Infrastructure Monitoring, and logs to the Splunk platform. Best fit: organizations with major log, SIEM, security, or compliance investments that want to modernize telemetry collection without abandoning existing Splunk expertise. Watchpoint: ingestion strategy must be governed carefully; OTel pipelines can filter and route before data becomes a cost problem.
Elastic covers logs, metrics, APM, traces, RUM, synthetic monitoring, and profiling, and donated its Universal Profiling agent to the OTel project upstream. Its differentiation is the combination of search, correlation, and security analytics that pure-observability platforms do not deliver. Best fit: organizations that need search, log analytics, and security observability in a single architecture. Watchpoint: self-managed, cloud-hosted, and commercial deployment patterns carry significantly different operational and cost profiles.
Grafana Labs is the most open-source-aligned option in the mainstream ecosystem. The LGTM stack, Loki for logs, Grafana for visualization, Tempo for traces, Mimir for metrics, provides complete signals coverage with OTel integration throughout. Grafana Alloy is a supported OTel Collector distribution for this stack. Best fit: platform engineering teams that want open architecture, Kubernetes and Prometheus alignment, and the option to choose between managed and self-managed. Watchpoint: three separate query languages across the stack means correlating a metric spike to its traces and logs crosses three systems rather than a unified data layer, and running this infrastructure at scale is a full-time engineering commitment.
SigNoz was built from the ground up on OTel and ClickHouse. All three signals live in a single datastore with a unified query experience, and OTel Semantic Conventions are preserved without translation loss. An organization that instruments with OTel and sends to SigNoz is operating in a genuinely portable architecture where the instrumentation, data model, and storage conventions are all open standards. Best fit: startups and cost-sensitive platform teams that want an OTel-native backend without assembling every component manually. Watchpoint: self-hosting still requires ownership of ClickHouse, Collectors, storage, and retention; managed SigNoz resolves that but becomes a commercial SaaS decision.
Four Real-World Examples That Illustrate the Stakes
STCLab’s CNCF-published migration to a full OTel-plus-LGTM architecture, documented in late 2025, demonstrates how OTel portability makes backend migrations executable. Facing observability gaps during peak-load flash sales and voting events, STCLab unified observability across disparate Kubernetes clusters using a centralized multi-tenancy architecture rather than full LGTM stacks per environment. The key condition that made the investment defensible: OTel instrumentation meant no re-instrumentation program was required during the migration.
Datadog’s Q3 2025 earnings call produced a signal worth noting. CEO Olivier Pomel disclosed that 34% of new enterprise customers were arriving with existing OTel instrumentation already in place, and acknowledged it was reshaping both onboarding workflows and pricing conversations. The structural shift OTel was theoretically supposed to produce has materialized as a real commercial dynamic. Enterprises are no longer willing to discard instrumentation as part of a vendor onboarding process.
The Semantic Convention disruption at Datadog, described in a 2025 SREcon Americas presentation by Datadog’s OTel team, illustrates the cost of the ingestion-with-translation model. Changes to HTTP and Deployment Semantic Conventions upstream broke alert logic and created monitoring gaps for enterprise clients whose data had been translated into Datadog’s internal conventions. Datadog co-developed the Schema Processor with the OTel community to handle future convention migrations. Platforms built natively on OTel face a different category of problem: the specification is their data model.
The Collector at ten billion daily spans is the scale signal practitioners still treating the Collector as optional infrastructure need to hear. At that volume, the organizations running it have decided it is foundational. A team with a Collector-based architecture can evaluate a new vendor, run a proof of concept against production traffic, or execute a backend migration through configuration changes rather than by touching application code.
Which Architecture Fits Which Operating Model
Choose a commercial all-in-one platform when you need fast implementation, have limited internal platform engineering capacity, need enterprise support, and value operational speed over maximum control. Datadog, Dynatrace, New Relic, Splunk, Elastic Cloud, Grafana Cloud, and Honeycomb all fit depending on requirements.
Choose an open-source-first stack when you have strong platform engineering capacity, need cost control at scale or data residency guarantees, and are prepared to own the observability platform as an internal product with appropriate staffing. Prometheus, Mimir, Loki, Tempo, Jaeger, Grafana, and SigNoz are the common candidates.
Choose an OTel-native hybrid when you want commercial backend support without proprietary instrumentation lock-in, expect multiple backends or a migration in the medium term, or want credible leverage in future vendor negotiations. For most mature enterprises with mixed environments and evolving commercial relationships, this is the most durable answer.
In all three cases, the architectural pattern that provides the most resilience is identical: instrument with OTel SDKs, establish the Collector as the central telemetry control plane, and use it to normalize, enrich, sample, filter, and route before data reaches the backend. The backend decision remains separable from the instrumentation decision. That is the point.
Open Source Is Not for Everyone, and That Is a Legitimate Position
Running the LGTM stack or SigNoz at scale is not a cost-saving measure if your organization does not have the engineering capacity to do it well. An underfunded open-source observability stack that misses incidents and requires heroic effort to maintain during upgrades is not cheaper than Datadog. It is more expensive, measured in engineer hours, undetected incidents, and organizational trust.
The organizations that run open-source observability backends well have made a deliberate decision to treat that infrastructure as a product they own and staff accordingly. Organizations hoping to reduce observability spend by self-hosting without increasing platform engineering headcount are making an accounting error that will surface at the worst possible time.
OTel’s contribution to this question is not that it makes open source the right answer for everyone. It is that it removes instrumentation cost from the backend decision entirely. If your commercial platform relationship changes, if pricing becomes untenable, if a better-fit tool emerges, the migration is an infrastructure decision, not an engineering program. The mistake is not choosing a commercial vendor. The mistake is allowing that vendor to own your instrumentation strategy.
The organizations that manage observability well across a range of sizes share one characteristic: they made an explicit decision about which backend architecture fits their team’s capacity, they built on OTel instrumentation regardless of that backend choice, and they treated the Collector as first-class infrastructure.
The organizations that struggled made the decision implicitly, embedded proprietary agents for convenience, and discovered the consequences when the renewal conversation arrived with no credible alternative. Essentially, they hired a bunch of cosplaying SREs from outside their Southington, CT Spirit Halloween, and gave them Prod access. What were they expecting other than abject failure?
OTel does not prevent that outcome automatically.
It makes it avoidable.
Nabeil Sarhan, MBA, is a dynamic technology delivery manager with over 15 years of experience in tech, cybersecurity, and computing scalability. He excels in leading diverse teams and delivering enterprise-class systems across industries such as healthcare, finance, and retail. Nabeil’s passion for solution design, systems architecture, and performance optimization makes him a sought-after consultant. He holds degrees from Harvard, MIT, and Bryant University. Connect with Nabeil on LinkedIn