Are processes allowed to report their process.cpu.time?

[trask]

What are you trying to achieve?

Clarification on whether language-based instrumentation is allowed to report process.cpu.time for its process.

The specification currently says:

OS process metrics are not related to the runtime environment of the program, and should take measurements from the operating system. For runtime environment metrics see semantic conventions for runtime environment metrics.

I think there are roughly three options:

• Allow instrumentations to report process.cpu.time for their own process (resource attributes would differentiate it from process.cpu.time reported by the OpenTelemetry Collector)
• Don't allow it, and make a local OpenTelemetry Collector a requirement for all deployments (that want this key metric of application health)
• Don't allow it, and make a copy of this metric under process.runtime.* or process.runtime.[jvm].*, e.g. process.runtime.cpu.time or process.runtime.[jvm].cpu.time

[bogdandrutu]

I think this is not about "allowing", it is about is it expected to have this instrumentation? Do we want to maintain this in all the language? etc.

/cc @yurishkuro

[trask]

I think this may be a language-ecosystem thing.

The JVM has been emitting "process cpu time" for almost 2 decades, so Java users very much expect this to be emitted by any Java metric library.

[alanwest]

Allow instrumentations to report process.cpu.time for their own process (resource attributes would differentiate it from process.cpu.time reported by the OpenTelemetry Collector)

Did you also mean process.cpu.utilization? Looks this issue was opened based on conversation from #2436.

I'm beginning to question if it is even possible for an instrumentation library to support process.cpu.utilization given its current definition:

Difference in process.cpu.time since the last measurement, divided by the elapsed time and number of CPUs available to the process.

In the event of multiple meter providers, their reporting intervals may be different. So, calculating the difference in process.cpu.time since the last measurement requires the instrumentation to maintain some state per meter provider. I don't think the metric API spec offers the support necessary for this.