Consider additional JVM metrics from MicroProfile specification

[trask]

From https://download.eclipse.org/microprofile/microprofile-metrics-5.0.0/microprofile-metrics-spec-5.0.0.pdf:

• jvm.uptime (RuntimeMXBean#getUptime)
• thread.max.count (ThreadMXBean#getPeakThreadCount)
• threadpool.*
• cpu.availableProcessors (OperatingSystemMXBean#getAvailableProcessors)
• cpu.processCpuTime (OperatingSystemMXBean#getProcessCpuTime)

[breedx-splk]

As we discussed this morning, here's my input on these:

• jvm.uptime - Seems useful. Maybe call it process.runtime.jvm.uptime and we can spec it as a DoubleCounter (monotonically increasing floating point seconds).
• thread.max.count - I'm ok leaving this out of the initial stability set.
• threadpool.* - I don't think these need to be in the initial group of stable metrics.
• cpu.availableProcessors - Quite important when trying to get a comprehensive picture of compute utilization, but IMO this is not a JVM specific consideration and we could leave it out of the initial JVM set.
• cpu.processCpuTime - Seems useful. Maybe call it process.runtime.jvm.cpuTime and we can spec it as a DoubleCounter (monotonically increasing floating point seconds).

[trask]

we may need cpu.availableProcessors under jvm since jvm reports non-fractional (no millicores)

let's see about reporting cpu.processCpuTime as standard process.*

[jack-berg]

Can we wait for a generic runtime uptime metric rather than introducing one that is JVM specific?

[trask]

process.cpu.time or process.runtime.jvm.cpu.time?

some concern about process.cpu.time conflicting with collector

should process.cpu.time be opt-in on JVM side to avoid conflicting with collector?

[trask]

Based on discussion today we are leaning towards process.runtime.jvm.cpu.time

[jackshirazi]

Are we also going to include the OS memory metrics available from JMX?

[trask]

No but I agree those are useful, I'll open an issue to discuss / track 👍

[trask]

I think we can close this now, the remaining issues are tracked in #3490, open-telemetry/semantic-conventions#1038 and #3473