Promote attributes used by hostmetrics system metrics to RC - #4055
osullivandonal wants to merge 1 commit into
Conversation
There was a problem hiding this comment.
Pull request overview
Promotes several attribute definitions (primarily in the system namespace, plus related cpu and network attributes used by system metrics) from development to release_candidate, and updates the generated registry/docs surfaces and changelog accordingly as part of the broader effort to stabilize system semantic conventions (#1804).
Changes:
- Updated attribute stability to
release_candidateforsystem.device, severalsystem.memory.*/system.paging.*enums, andsystem.filesystem.*attributes. - Promoted related attributes in other namespaces used by system metrics (
cpu.logical_number,network.connection.state) torelease_candidate. - Refreshed the generated attribute registry docs and added a
.chloggenentry.
Reviewed changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| model/system/registry.yaml | Promotes multiple system.* attributes/enums to release candidate. |
| model/network/registry.yaml | Promotes network.connection.state enum members and attribute to release candidate. |
| model/cpu/registry.yaml | Promotes cpu.logical_number to release candidate. |
| docs/system/container-metrics.md | Updates rendered stability badge for system.device in system container metrics docs. |
| docs/registry/attributes/system.md | Updates generated registry page stability badges for affected system.* attributes/enums. |
| docs/registry/attributes/network.md | Updates generated registry page stability badges for network.connection.state. |
| docs/registry/attributes/cpu.md | Updates generated registry page stability badge for cpu.logical_number. |
| .chloggen/promote-system-attributes-used-in-hostmetrics.yaml | Adds changelog entry describing the promotion. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| stability: release_candidate | ||
| deprecated: | ||
| reason: uncategorized | ||
| note: "Removed, report shared memory usage with `metric.system.memory.linux.shared` metric" |
There was a problem hiding this comment.
Good spot, the attribute shared should not be promoted to RC as its deprecated. This has been removed.
| stability: development | ||
| stability: release_candidate | ||
| brief: "The filesystem mode" | ||
| examples: ["rw, ro"] |
dc06045 to
c82d5bf
Compare
Pull request dashboard statusWaiting on reviewers · refreshed 2026-09-22 15:48 UTC Review the latest changes. Status above doesn't look right?
|
ChrsMark
left a comment
There was a problem hiding this comment.
Overall looks good to me. Left one question about the linux slab state attribute.
c82d5bf to
e06b025
Compare
|
|
||
| # A brief description of the change. Surround your text with quotes ("") if it needs to start with a backtick (`). | ||
| note: Promote `jvm.file_descriptor.count` and `jvm.file_descriptor.limit` metrics to `release_candidate` | ||
| note: Promote attributes used by hostmetrics system metrics to RC |
There was a problem hiding this comment.
it seems there are some outstanding issues affecting some of these attributes. They maybe out-of-date and maybe SIG decided on them long time ago, but please, can you go through and resolve them? Thanks
- [#1474](
system.devicevsdevice.idvshw.id#1474) -system.device- Could rename it tosystem.device.id, merge it withhw.id, or turnsystem.deviceinto a namespace. This directly changes the attribute name or meaning. - [#3826](Mark
system.filesystem.*attributes as release candidate #3826) -system.filesystem.state,system.filesystem.mode,system.filesystem.mountpoint,system.filesystem.type- Could renamestate, revise value meanings, or change definitions to cover non-Unix systems consistently. - [#3986]([k8s][system] Reconcile k8s/container filesystem metrics with system.filesystem.* #3986) -
system.filesystem.state- A different model could replace the state attribute with separateusageandavailablemetrics. Recent discussion favors keeping the current model, so this risk is lower. - [#2934](Inform reader cpu logical number refers to core number #2934) -
cpu.logical_number- Could clarify or change whether the value identifies a logical processor, hardware thread, or core. Existing producers may then have the wrong interpretation. - [#3659](Clarification needed between CPU-related namespaces #3659) -
cpu.logical_number- Could change the scope ofcpu.*attributes or move CPU identification into an entity-based model. - [#2991](Align cpu hw metrics with system cpu metrics #2991) -
cpu.logical_number- Could deprecate thesystem.cpu.*metrics that currently use this attribute, potentially leaving it without those consumers.
This list is generated with AI, feel free to push back on relevance.
There was a problem hiding this comment.
Will take this back to SIG to discuss.
There was a problem hiding this comment.
PR created to rename system.device to system.device.name: #4119
Promotes to release candidate all attributes referenced by the system metrics that are emitted by the hostmetrics receiver. A follow-on PR will promote the corresponding system metrics to release candidate.
e06b025 to
47f90e6
Compare
Works towards #1804
Changes
Promotes to release candidate all attributes referenced by the system metrics that are emitted by the hostmetrics receiver. A follow-on PR will promote the corresponding system metrics to release candidate.
Some of the attributes here are not referenced directly by the hostmetrics receiver's configuration, the reason they have been moved to RC is that the metric that uses the attribute is being used by hostmetrics receiver.
Note: this work also touches the
cpuandnetworkregistries, since some attributes used by system metrics live in those namespaces.These attributes have been promoted to RC:
(https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/hostmetricsreceiver/internal/scraper/pagingscraper/metadata.yaml)
(https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/hostmetricsreceiver/internal/scraper/filesystemscraper/metadata.yaml)
(https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/hostmetricsreceiver/internal/scraper/networkscraper/metadata.yaml)
(https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/hostmetricsreceiver/internal/scraper/memoryscraper/metadata.yaml)
(https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/hostmetricsreceiver/internal/scraper/memoryscraper/metadata.yaml)
(https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/hostmetricsreceiver/internal/scraper/pagingscraper/metadata.yaml)
(https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/hostmetricsreceiver/internal/scraper/pagingscraper/metadata.yaml)
(https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/hostmetricsreceiver/internal/scraper/filesystemscraper/metadata.yaml)
(https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/hostmetricsreceiver/internal/scraper/filesystemscraper/metadata.yaml)
(https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/hostmetricsreceiver/internal/scraper/filesystemscraper/metadata.yaml)
(https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/hostmetricsreceiver/internal/scraper/filesystemscraper/metadata.yaml)
(https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/hostmetricsreceiver/internal/scraper/cpuscraper/metadata.yaml)
(https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/hostmetricsreceiver/internal/scraper/networkscraper/metadata.yaml)
Important
Pull request acceptance is subject to the triage process as described in Issue and PR Triage Management.
PRs that do not follow the guidance above may be automatically rejected and closed.
Merge requirement checklist
Footnotes
Yes, I can answer maintainer questions about the content of this PR without using AI. ↩