Consider merging *.cpu.state metric attributes

[ChrsMark]

Area(s)

area:container
area:system
area:process

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

At the moment we have 3 different metric attributes representing the cpu.state:

• system.cpu.state
• process.cpu.state
• container.cpu.state

Based on the global flat registry idea it would be nice if we had one single definition for this attribute and then be able to re-use it in the various namespaces.

Describe the solution you'd like

As it is explained at #681 (comment) we could consider merging into one single one called cpu.state similar to the disk.io.direction and network.io.direction.

Describe alternatives you've considered

Maybe the embed concept would be sth to think of here: open-telemetry/build-tools#240

Additional context

No response

cc @open-telemetry/semconv-system-approvers @open-telemetry/semconv-container-approvers @open-telemetry/semconv-k8s-approvers

[ChrsMark]

So to summarize the situation here, we have the following:

System Metrics

Values for system.cpu.state:

• user
• system
• nice
• idle
• iowait
• interrupt
• steal

Process Metrics

Values for process.cpu.state:

• user
• system
• wait

Container Metrics

Values for container.cpu.state:

• user
• system
• kernel

Based on @braydonk's comment we can change the wait value of the process.cpu.state to idle and hence the process.cpu.state will be a subset of the system.cpu.state. Then we can use the superset for both.

Then the only difference with the container.cpu.state is the kernel value.
Checking the dockerstatsreceiver implementation, this value comes directly from the Docker API. For now I guess we should use it as is unless we find way to properly correlate it with rest of set's values. @jamesmoessis feel free to comment here if you have more information.

My first proposal would be to unify the attribute to cpu.state with possible values being the following [user, system, nice, idle, iowait, interrupt, steal, kernel].

What do you @open-telemetry/semconv-system-approvers think about this?

[AlexanderWert]

I like the proposal, it simplifies things.

@lmolkova Can we limit the valid values of an attribute when used in a concrete context to a subset of the overall allowed values through the tooling?

[ishleenk17]

@ChrsMark : Primarily for system metrics, we consider the states mentioned here. IThere's an additional state softirq, which I didn't find in the code you referenced.
Just a thought, if we want to consider that as another member of the state as well.

[joaopgrassi]

Removing the triage label, as this sounds like a good plan. Unifying them makes sense to me.

[ChrsMark]

@lmolkova any thoughts on #840 (comment)?

[mx-psi]

I am in favor of this.

IThere's an additional state softirq, which I didn't find in the code you referenced.

@ishleenk17 I think this is Linux-specific, so it should go into its own separate metric like we did on open-telemetry/build-tools#323

[trisch-me]

@ChrsMark it's not possible yet but we are discussinga few weeks ago this option, one similar reference would be open-telemetry/weaver#479 to exend enum from some base one, but option to use specific fields will be most probably also implemented