Unify system.cpu.state, process.cpu.state, container.cpu.state into cpu.mode?

[lmolkova]

process.cpu.state

Attribute	Type	Description	Examples	Stability
process.cpu.state	string	The CPU state of the process.	system; user; wait

process.cpu.state has the following list of well-known values. If one of them applies, then the respective value MUST be used; otherwise, a custom value MAY be used.

Value	Description	Stability
system	system
user	user
wait	wait

system.cpu.state

Attribute	Type	Description	Examples	Stability
system.cpu.state	string	The state of the CPU	idle; interrupt

system.cpu.state has the following list of well-known values. If one of them applies, then the respective value MUST be used; otherwise, a custom value MAY be used.

Value	Description	Stability
idle	idle
interrupt	interrupt
iowait	iowait
nice	nice
steal	steal
system	system
user	user

Could we unify them?

It could also be useful on runtime-specific metrics: #1035 (comment)

cpu.mode

Attribute	Type	Description	Examples	Stability
cpu.mode	string	The state of the CPU	idle; interrupt

cpu.mode has the following list of well-known values. If one of them applies, then the respective value MUST be used; otherwise, a custom value MAY be used.

Value	Description	Stability
user	user

Only user because it seems to be the most common denominator. But effectively:

• the general definition does not specify a full list (does not have to specify anything)
• process, system, container, {runtime-specific} semconv can document applicable values

[lmolkova]

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

[lmolkova]

Also

Attribute	Type	Description	Examples	Stability
container.cpu.state	string	The CPU state for this data point.	user; kernel

container.cpu.state has the following list of well-known values. If one of them applies, then the respective value MUST be used; otherwise, a custom value MAY be used.

Value	Description	Stability
kernel	When tasks of the cgroup are in kernel mode (Linux). When all container processes are in kernel mode (Windows).
system	When CPU is used by the system (host OS)
user	When tasks of the cgroup are in user mode (Linux). When all container processes are in user mode (Windows).

[ChrsMark]

We have been evaluating this already at #1026 (issue) which currently blocked at #1026 (comment).

Any particular reason for having .*mode instead of .state? I guess that would be another major breaking change for system and process metrics at least.
/cc @open-telemetry/semconv-container-approvers @braydonk

[lmolkova]

We have been evaluating this already at #1026 (#840) which currently blocked at #1026 (comment).

Thanks!

Any particular reason for having .*mode instead of .state?

No strong opinion, same concern as in #1128 (comment) - "I feel like state normally implies the ability to transition between different values which isn't true here."

CPU state and CPU mode seem to be both used widely, but CPU mode would probably be more precise? (i.e. someone looking at the cpu.state without the context might expect failed, broken, etc there. state.mode would not have such a problem)

Also this (but we should all take it with a grain of salt)

I guess that would be another major breaking change for system and process metrics at least.

They are still experimental. Also if we are renaming them anyway, let's consider changing state to mode as well.

[lmolkova]

I'm going to close this as duplicate of #840. Let's continue the discussion on https://github.com/open-telemetry/semantic-conventions/pull/1026/files#r1635136959