Clarify OS specific system attributes/metrics namespace

[rogercoll]

Area(s)

area:system

Is your change request related to a problem? Please describe.

Should system semantic conventions attributes and/or metrics specific to an OS include it as a namespace? At the moment, there are example of both options:

With {os} namespace

• linux.memory.slab.state attribute
• system.{os} metrics; an example would be system.linux.memory.available

Without the {os} namespace

• process.executable.build_id.gnu attribute; gnu specific
• process.owner; Windows specific
• process.open_file_descriptor.count; Linux specific metric

Describe the solution you'd like

Whether all attributes/metrics specific to an OS contain the OS name in its namespace or not.

This concern was raised during a @open-telemetry/semconv-system-approvers SIG while considering the implications of using the linux prefix for the process.cgroup attribute.

Describe alternatives you've considered

No response

Additional context

No response

[ChrsMark]

Looking into this again, I find it weird that we encode the linux information within the metric name.
If a metric is supported by an OS or not is an implementation detail that might change in the future.

We hit the same in some host's resource attributes, like at the host.cpu.model.id which the collector skips: https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/5601dfb28d905d0802f2e450cad6a2cc80029b6b/processor/resourcedetectionprocessor/internal/system/system.go#L202-L207. Should we encode the os information in these too?

@open-telemetry/semconv-system-approvers check me here but wouldn't be just fine if we document in which operating systems a metric is supported and keep the name unified?