In March 2026, OpenTelemetry‘s declarative configuration specification reached stable 1.0. No press release. No vendor marketing push. But if you’re running OTel Collectors at any kind of scale, it changes things.
Most teams today are managing Collectors with hand-edited YAML files, scattered environment variables, and no reliable way to audit what is actually running in production. That gap — between what you intend your observability pipeline to run and what it is actually running — is configuration drift. It compounds silently. Until an incident exposes it.
The stable spec closes that gap. You can now treat observability pipeline configuration with the same version-control and CI/CD rigour you apply to application code. And it fits neatly into the broader enterprise OpenTelemetry migration playbook.
What is OpenTelemetry declarative configuration and why does the “stable” milestone matter?
OpenTelemetry declarative configuration lets you define every OTel SDK setting — exporters, samplers, resource attributes, trace providers, metric readers, log processors — in a single YAML file. Point the SDK at it using the OTEL_CONFIG_FILE environment variable and it initialises from that file instead of scattered env vars or in-code setup calls.
The meaningful event here is the JSON Schema reaching 1.0.0 in the open-telemetry/opentelemetry-configuration repository. A frozen, versioned schema means CI pipelines can validate a configuration file before the change merges — catching typos, missing required fields, and invalid values before they reach staging. That’s the property that makes declarative configuration the foundation for GitOps-managed observability.
Language SDK completeness varies. Java and PHP are fully compliant. Go is partial. .NET and Python are still in development. The Specification Compliance Matrix in the open-telemetry/opentelemetry-specification repository on GitHub is the canonical reference for your stack.
What is configuration drift in observability infrastructure and why is it a production risk?
Configuration drift is the gap between what you intend your OTel Collectors to run and what they are actually running. It accumulates through manual edits, hotfixes that were never cleaned up, and environment variable overrides that outlasted the incidents that prompted them.
If you’ve used Ansible or Terraform, you already understand this problem at the server layer. Declarative configuration for observability is the same class of problem, arriving about a decade later.
At the scale of dozens or hundreds of Collectors, drift creates real failures. An exporter falls off a Collector because someone edited the YAML to debug a timeout and never reverted. A sampling rate set during an incident is never restored. A security change applied in dev never makes it to prod. None of these are loud failures. They degrade observability quietly until an incident happens and there is nothing to look at.
How does GitOps for observability work with OpenTelemetry declarative configuration?
The principle is straightforward. Every OTel SDK config and Collector pipeline config lives in a Git repository. Changes go in via pull request. CI validates the YAML against the JSON schema before merge. The approved config is the deployed config.
In practice: define telemetry settings in a YAML file, validate against the OTel JSON Schema in CI, merge to main, then deploy via OTEL_CONFIG_FILE or push via OpAMP to running agents. The Git commit history answers “what changed, when, and who approved it” for any Collector in the fleet.
The payoff is that observability infrastructure managed this way meets the same governance and auditability standards as application code. It can be reviewed, rolled back, and included in compliance evidence. In regulated industries, that is not a nice-to-have. There’s also a security payoff: declarative config reduces drift that creates undetected CVE exposure — when every Collector’s configuration is version-controlled, answering “are we affected by this CVE?” becomes a grep rather than a fleet survey.
One more thing worth noting: the OTel project has changed its specification proposal process to “declarative configuration first.” Any new SDK feature must include the corresponding config schema types alongside it. Every new OTel capability will be declaratively manageable from day one.
What is OpAMP and how does it deliver declarative configuration to a fleet of Collectors at runtime?
Declarative configuration defines what an agent should run. The Open Agent Management Protocol (OpAMP) is the mechanism that delivers that configuration to running agents and confirms it was applied — without a manual restart or an SSH session into each host.
Think of it this way. OTLP is the data plane — it carries telemetry signals (traces, metrics, logs) from agents to backends. OpAMP is the control plane — it handles configuration delivery, health reporting, and lifecycle management. OTLP is the highway for observability data. OpAMP is the traffic management system.
There are three implementation patterns for the OTel Collector. The OpAMP Extension runs inside the Collector, reporting health and config — but it crashes with the Collector and can’t apply changes. The OpAMP Supervisor is a separate binary wrapping the Collector; it owns the OpAMP connection independently, manages restarts after config changes, and survives Collector crashes. For production fleet management, the Supervisor is the right choice. The OpAMP Gateway Extension (open-sourced by Bindplane) consolidates many agent connections at the network boundary — which solves the firewalled-environment problem at scale.
Bindplane and Honeycomb use OpAMP to power their fleet management products. Datadog offers Fleet Automation as a proprietary alternative — the trade-off being a vendor control plane rather than an open protocol. For fleet-scale pipeline management in practice, see Adobe’s OpenTelemetry Pipeline Architecture at Enterprise Scale.
What does the Thoughtworks Technology Radar Vol. 34 signal about OpenTelemetry ecosystem maturity?
The Thoughtworks Technology Radar uses four rings: Adopt, Trial, Assess, and Hold. Trial means worth running in production for the right use case. Assess means worth exploring and understanding. Three OTel-native platforms landing in a single volume is worth paying attention to.
Thoughtworks Technology Radar Vol. 34 (April 2026) placed all three.
SigNoz received Trial placement — an open-source, OTel-native observability platform on a ClickHouse backend, described as a strong self-hosted Datadog alternative that has reduced infrastructure costs without compromising performance. It belongs on your shortlist.
ClickStack received Assess placement — an OTel-compatible platform unifying logs, traces, metrics, and sessions in ClickHouse with sub-second high-cardinality query performance. Your architecture team should be exploring it.
Langfuse received Trial placement — an open-source LLM engineering platform with Python and TypeScript SDKs built natively on OpenTelemetry. If you’re already running OTel-based infrastructure, you get LLM observability essentially for free.
Three OTel-ecosystem entries in a single Radar volume is an analyst statement about where observability infrastructure is heading. It’s hard to ignore.
How does declarative configuration close the CVE exposure blind spot for OpenTelemetry deployments?
Without a declarative configuration record, answering “are we affected by this CVE?” in a large OTel fleet is a fleet survey problem. You need to inspect each running Collector. The blast radius is unknown until you finish — and in a live production incident, that delay is costly. With version-controlled declarative configurations, the same question becomes a grep.
CVE-2026-40182 affects OpenTelemetry .NET 1.13.1–1.15.1: if the backend returns a 4xx or 5xx response, the response body is read into memory with no upper bound — memory exhaustion when the endpoint is attacker-controlled. Fix: version 1.15.2. CVE-2026-41078 affects the deprecated OpenTelemetry.Exporter.Jaeger for .NET — no patch coming. Teams running custom Collector distributions that excluded the Jaeger exporter have zero exposure. Teams running vanilla Collectors may not know whether they are affected.
Custom Collector distributions, built using the OTel Collector Builder (ocb), give you a structural security advantage: excluded components simply cannot be exploited. Adobe’s quarterly upgrade cadence is the operational template — minimal custom distribution, quarterly upgrade cadence, version-controlled configuration via Helm charts. Bindplane’s otel-distro-builder can generate a distribution manifest from an existing config.yaml. For the full security context, see OpenTelemetry Security: CVEs, Trust Boundaries, and What to Patch Now.
Is OpenTelemetry declarative configuration stable enough to use in production today?
Yes — but you need to be precise about what is stable and what is still in development.
The specification is stable and the JSON Schema is frozen. The Collector pipeline YAML has been stable longer still. What varies is SDK completeness per language. Java and PHP are production-ready without caveats. .NET and Python are still in development for declarative configuration.
The practical recommendation: start with Collector pipeline YAML in Git now. Get it under version control and CI validation — the tooling setup cost is minimal. Layer SDK declarative configuration on top as language support matures in your stack.
Multiple signals are all pointing in the same direction: declarative configuration stable (March 2026), OTel Collector approaching 1.0, CNCF graduation as the confirmed 2026 target, three OTel-native platforms on the Thoughtworks Radar, and Airbnb running OTel-based infrastructure at 100 million samples per second. The Bindplane KubeCon 2026 recap put it plainly: “If you’ve been waiting for the ecosystem to settle before going all-in, that moment is getting very close.”
Get this right before your fleet scales to the point where drift becomes a visible problem. See the enterprise OpenTelemetry migration playbook for where declarative configuration fits in the broader migration.
Frequently Asked Questions
What is the difference between OpenTelemetry declarative configuration and the OTel Collector YAML config?
These are two distinct surfaces. SDK declarative configuration (OTEL_CONFIG_FILE) defines how your application’s OTel SDK is initialised. Collector pipeline YAML defines how the standalone Collector routes and processes telemetry. Both benefit from GitOps management — they just govern different layers and complement each other.
What is OpAMP and how is it different from OTLP?
OpAMP is the control plane — configuration, health, and lifecycle management for telemetry agents, over WebSocket. OTLP is the data plane — it carries traces, metrics, and logs from agents to backends. They operate independently and serve entirely different purposes.
Can I version-control my OpenTelemetry Collector configuration like application code?
Yes — this is exactly what declarative configuration enables. The JSON Schema CI validation step is what separates “YAML file in a repository” from “GitOps-managed configuration.” Schema validation catches structural errors before deployment, not during an incident.
How do big companies manage hundreds of OpenTelemetry Collectors without configuration drift?
Two approaches, and they can be combined. First: fleet management via OpAMP — Bindplane, Honeycomb Telemetry Pipeline, or self-managed — where the Supervisor pattern pushes config changes and confirms application. Second: Adobe’s approach of a custom distribution, Helm charts, and a quarterly upgrade cadence — fleet-scale management without a commercial OpAMP product.
What does Thoughtworks placing SigNoz at “Trial” mean when evaluating observability backends?
Trial means Thoughtworks recommends running this in a real project — it has cleared “worth evaluating.” SigNoz belongs on your shortlist as a self-hosted, OTel-native Datadog alternative, backed by observed cost reductions in real deployments.
What is the OTel Collector Builder (ocb) and why would I build a custom distribution?
OCB assembles a custom OTel Collector binary containing only the components your deployment actually uses. The benefits: reduced attack surface, smaller binary, explicit dependency management, and scoped quarterly upgrades. Bindplane’s otel-distro-builder can generate a distribution manifest from an existing config.yaml.
Is OpenTelemetry ready for enterprise production use in 2026?
Yes, with a language caveat. Declarative configuration is stable, the Collector is approaching 1.0, CNCF graduation is confirmed, and three OTel-native platforms landed on the Thoughtworks Radar. Java and PHP are fully compliant. .NET and Python are still in development for declarative configuration — but the Collector pipeline YAML path is viable right now.
What is the “declarative config first” norm emerging in the OTel project?
Any new SDK feature proposal must include the corresponding declarative configuration schema types — the config schema is now a core part of the SDK user experience, not an afterthought. Every new OTel capability will be declaratively manageable from the moment it ships.
What happens if I use environment variables instead of declarative configuration in OpenTelemetry?
Environment variables still work and are not deprecated. The trade-off: settings are scattered, cannot be validated as a unit, and require careful management to version-control. That scattered model’s operational cost compounds at scale and in regulated environments.
What is the Spec Compliance Matrix and where do I find it?
It’s a GitHub-hosted table tracking per-language implementation status of every OTel API/SDK specification feature, including declarative configuration. Find it in the open-telemetry/opentelemetry-specification repository — fine-grained detail is in the Language Support Status document in open-telemetry/opentelemetry-configuration.
What is dynamic or remote configuration in OpenTelemetry and is it available yet?
Dynamic configuration means pushing config changes to running agents without a restart. As of 2026 it’s on the OTel roadmap. The OpAMP Supervisor already delivers configuration with managed restarts — minimal downtime, not zero-downtime streaming. True hot-reload is still in development.
How does declarative configuration relate to OpenTelemetry’s CNCF graduation path?
CNCF graduation is the Cloud Native Computing Foundation’s highest maturity designation — and for many enterprise procurement teams, it’s the proxy for “production-grade open source.” Declarative configuration stability contributes directly to the Collector reaching 1.0, which is required for graduation. When graduation lands, it removes the “is this project mature enough?” objection from enterprise procurement conversations.
