OpenTelemetry goes 'stable by default': what it means for Kubernetes telemetry, and how to migrate

What 'stable by default' means

The committee's goals were explicit¹:

• All OpenTelemetry distributions should be stable by default, with standard mechanisms to opt in to experimental features.
• A single, consistent set of stability criteria, including documentation, performance testing and benchmarks.
• Easier stabilisation of instrumentation libraries, and federation of semantic conventions.
• Epoch releases that are easier for organisations to consume.

For a platform team, the practical promise is fewer surprises: stable components you can rely on, and clearly marked opt-ins for anything that isn't.

The Kubernetes example

The Kubernetes attributes processor, which enriches telemetry with metadata such as pod, namespace and node, shows what that journey involves. Its stability depended on the Kubernetes semantic conventions it emits, so the two efforts moved together²³:

The v1.0.0 announcement is clear that moving to the new convention names means some breakage for existing users, and points to a migration guide³⁵. During the transition the processor provided feature gates, processor.k8sattributes.EmitV1K8sConventions and processor.k8sattributes.DontEmitV0K8sConventions, so teams could emit the new attributes before dropping the old ones².

Why attribute renames hurt more than they look

Kubernetes attributes are everywhere in an observability estate: dashboard filters, alert rules, service level objectives, cost allocation by namespace, retention policies, access controls and the queries engineers keep in runbooks. A renamed attribute doesn't throw an error. It just makes a filter match nothing, so a dashboard goes quiet and an alert never fires.

The migration plan I use

1. Inventory dependencies on attribute names. Export dashboards, alert rules, recording rules and saved queries, and search them for the Kubernetes attributes in your telemetry. Include cost reports that group by namespace or workload, as in Kubernetes FinOps.
2. Read the migration guide for your exact version of the Collector and processor⁵, and list old and new names side by side.
3. Emit both, then switch. Where your version supports it, emit the new conventions alongside the old in a non-production environment, update dashboards and alerts to the new names, then stop emitting the old ones.
4. Use the gateway layer to manage the transition centrally rather than on every node, which is one reason I favour the agent-to-gateway pattern in Collector deployment patterns.
5. Add canary checks: alerts that fire when a key dashboard query returns no data, so silent breakage is caught.
6. Pin Collector versions and upgrade deliberately, with a changelog review for every component you use.

A broader stability strategy

The Kubernetes processor is one component among many working towards stability³. The same pattern applies elsewhere, from the span events deprecation to GenAI conventions that are still evolving, covered in LLM observability. My rules for platform teams:

• Prefer stable components in production, and record each experimental component you depend on with the reason and an owner.
• Treat telemetry schemas as interfaces, with the same versioning discipline as APIs and the contract thinking in data contracts.
• Budget a small, regular amount of time for observability upgrades, rather than a painful catch-up every two years.

How I can help

I design and modernise observability platforms on OpenTelemetry and Kubernetes, including migrations like this one that keep dashboards and alerts working. As a fractional CTO I can own that roadmap. Or analyse your challenge and bring the result to a call.