OpenTelemetry has spent years winning mindshare as the instrumentation and telemetry standard. But there’s a second battle it has to win if teams are going to run OpenTelemetry at scale: configuration needs to become portable, testable, and upgrade-friendly. This week, the OpenTelemetry project marked a meaningful milestone: key portions of the declarative configuration specification are now labeled stable, including the data model schema and YAML representation.
That sounds like housekeeping. It’s not. Stability in config semantics is what turns the Collector from “a powerful thing you run” into “a product you can operate safely.”
What exactly became stable?
Per the OpenTelemetry blog, multiple pieces are now stable:
- The JSON schema for the declarative config data model (with a stable
1.0.0release in the opentelemetry-configuration repo). - The YAML representation of the data model for file-based configs.
- The in-memory model representation and the SDK operations used to parse YAML and instantiate components.
- Mechanisms for referencing custom plugin components and the
OTEL_CONFIG_FILEenvironment variable.
Translation: you can now treat declarative config as a real interface—one that is expected to keep working across versions.
Why platform teams should care (even if they already have “working Collector configs”)
Most teams adopt OpenTelemetry in a piecemeal way: a language SDK here, a gateway Collector there, some vendor exporter configs glued together by copy/paste. That works until you need to do any of the things that define serious production operations:
- Roll out config changes gradually (canary, staged rollout).
- Validate configs before they hit production (CI checks, schema validation).
- Upgrade collectors without discovering that a field or behavior changed.
- Support multiple teams with different needs without creating a config jungle.
A stable declarative model moves Collector configuration closer to the toolchains we already trust for infrastructure: schema validation, version control, and repeatable deployments. That’s the “Collector-as-a-product” step.
Declarative config is the bridge between “intent” and “implementation”
In the classic Collector config, you configure pipelines by directly referencing processors/exporters/receivers. That’s powerful, but it’s also tightly coupled to how the Collector is implemented and what the component names are today.
Declarative config aims to express intent in a portable way: “take these signals, apply these transformations, export to these destinations.” When a stable data model exists, tooling can evolve around it:
- Linters that catch footguns (like unbounded attribute cardinality) before they become a bill spike.
- Diff tools that render config changes as human-friendly policy changes.
- Policy guardrails that enforce org standards (PII redaction, required resource attributes, exporter allowlists).
These are the same patterns that made “infrastructure as code” workable. Observability is heading in that direction—this stability milestone is part of the path.
Operational implications: safer rollouts and fewer ‘unknown unknowns’
Config stability doesn’t eliminate mistakes, but it reduces a particular kind of pain: upgrades that break because a configuration format subtly drifted. In practice, stability unlocks a few pragmatic wins:
- Schema validation in CI/CD: treat invalid config as a build failure, not a runtime surprise.
- Golden config modules: platform teams can ship opinionated “modules” (receivers + processors + exporters) that app teams compose, rather than copy/paste.
- Safer multi-backend strategies: if you’re exporting to multiple observability backends (or migrating between them), portability matters.
What to do next (if you run OTel at scale)
If you’re already running the Collector widely, the right move isn’t “rewrite everything tomorrow.” It’s to start building the guardrails that stable config now makes possible:
- Introduce validation for declarative configs in CI, even if you keep classic config for a while.
- Define a config ownership model: who can change pipelines, exporters, or redaction rules?
- Standardize on a small set of supported patterns (e.g., per-cluster gateway + per-namespace agent, or whatever matches your org).
Bottom line
Instrumentation gets the headlines, but operations pay the bills. Stabilizing declarative configuration is OpenTelemetry’s signal that it wants to be run like real infrastructure. If you’re building a cloud-native platform, that’s the difference between “OTel as a project” and “OTel as a product.”