Keep process-metric release candidates out of stability dashboards

A release candidate is a request to test

On October 13, 2026, OpenTelemetry announced that Collector Contrib v0.160.0 can emit release-candidate process semantic-convention metrics from the hostmetrics receiver’s process scraper. The announcement describes this as a step toward stable v1 and asks users to try the versioned output and report what breaks (OpenTelemetry’s announcement of RC process metrics in hostmetrics).

I would treat that as an invitation to explore, not a reason to point production dashboards at new metric names. A release candidate can be useful before it is a dependable interface. The risk is not that the metrics are inherently bad; it is that a provisional shape can quietly become a dependency. Once a dashboard, alert, recording rule, or downstream consumer assumes that shape, changing it becomes an operational migration rather than a harmless collector upgrade.

The distinction I care about is between exploratory telemetry and an operational contract. Exploratory telemetry helps me learn whether a proposed convention describes the system well. An operational contract is what I am willing to have on-call decisions depend on. The same metric can move from one category to the other, but I want that move to be deliberate.

Inventory what depends on the current output

Before enabling the RC broadly, I would find out what already consumes process telemetry. That means more than grepping dashboards for a metric name. I would inventory the metric names and attributes used by dashboards, alert expressions, recording rules, and any downstream system that receives or transforms the data. I would also check the unit and meaning of each measurement: two metrics with similar names are not interchangeable if they describe different things.

That inventory matters especially in Prometheus. A time series is identified by its metric name and its set of labels, so a change to either can change what a query selects and what data it sees (Prometheus’s data model). Prometheus recommends choosing metric and label names deliberately, and notes that labels distinguish characteristics of the thing being measured (Prometheus metric and label naming guidance). In practice, a query can stop matching after a rename, or continue matching while accidentally aggregating a changed set of series. Neither outcome is obvious just from the fact that collection is still running.

I would make a small dependency map: which consumers use which measurements, which attributes they filter or group by, and which of those consumers are operationally important. That gives me a baseline to compare against the RC output. It also exposes dependencies that nobody meant to create—for example, a dashboard panel that has become part of an incident workflow even though its query was originally written just to inspect a new metric.

I would not assume a collector upgrade is the same thing as a telemetry migration. The OpenTelemetry process conventions cover attributes, metric names, and units, and the conventions page warns existing instrumentation not to adopt breaking changes before the conventions are stable (OpenTelemetry’s OS process metrics conventions). That is a useful way to think about the boundary: verify the actual output and the consumers, rather than treating a version number as proof that the change is safe.

Give exploration its own path

The announcement says the RC output is opt-in through a feature gate. In v0.160.0, the gate is alpha and disabled by default; enabling it selects the new versioned output (OpenTelemetry’s hostmetrics RC announcement). That opt-in is a good place to start a controlled evaluation:

./otelcontribcol --config=collector.yaml --feature-gates=scraper.process.EmitV1SystemConventions

I would run that in a canary or other explicitly exploratory path and keep its output separate from the metrics that production dashboards and alerts treat as stable. The exact separation depends on the deployment: it might be a separate collector, a separate scrape target, or another boundary that keeps the RC series out of operational queries. The design goal is simple: a person looking at a production dashboard should not have to know whether a release candidate is enabled somewhere to interpret the chart.

In that exploratory path, I would compare the RC output with the current output using representative hosts and realistic queries. I would check whether the new metrics convey the information I need, whether attributes support the filters and groupings that matter, and whether the new names and units require query changes. I would also check the downstream route, not just the collector’s own logs: an exporter or translation step can affect what a Prometheus-compatible backend actually sees.

I would avoid making an experimental dashboard look like an operational one. Label it as an evaluation, keep its queries out of production alerts, and make the source of the data visible. This is not ceremony. It prevents a convenient exploratory panel from being copied into an on-call dashboard and becoming an undocumented promise.

Promote the change explicitly

After the comparison, I would write down the decision: adopt the RC output, defer it, or keep testing. If I adopt it, I would treat the change as a migration with named consumers and an owner for each one. I would update dashboards, alerts, recording rules, and downstream queries intentionally, then verify that each still expresses the question it was meant to answer. A query that returns data is not necessarily a query that still means the same thing.

I would also define what happens to the old output. Keeping both forms indefinitely can make it unclear which one is authoritative; removing the old form before consumers have moved can break the very dashboards the transition is meant to improve. So I would make the overlap and removal conditions explicit, and keep the ability to roll back while the new path is being evaluated. The release-candidate label is a reason to expect feedback and possible change, not a guarantee that a particular name or attribute will remain untouched.

The key decision is not whether to try the new process conventions. OpenTelemetry has made trying them possible without silently changing the existing configuration. The decision is whether I am ready to make their output part of the operational contract. I would let the RC earn that place through an isolated evaluation and a visible migration—not by letting it drift into a dashboard that promises stability.