Add semantic conventions for jvm cpu metrics

[jonatan-ivanov]

Initial draft for JVM runtime cpu semantic conventions.
I created a gist where you can see where these values are coming from: https://gist.github.com/jonatan-ivanov/0449619cb6f851ce67d70e47a6a1fb73

/cc @trask @jack-berg

[linux-foundation-easycla]

The committers are authorized under a signed CLA.

• ✅ Jonatan Ivanov (f1dffdd, 7dad51a, bac4a56)

[jack-berg]

Here's a summary of the proposed metrics and their corresponding sources. Hopefully this makes it a bit easier to evaluate the value of these. This summarizes the information from @jonatan-ivanov's gist.

• process.runtime.jvm.cpu.time - com.sun.management.OperatingSystemMXBean#getProcessCpuTime()
• process.runtime.jvm.cpu.utilization - com.sun.management.OperatingSystemMXBean#getProcessCpuLoad()
• process.runtime.jvm.common.pool.parallelism - java.util.concurrent.ForkJoinPool#getParallelism()
• process.runtime.jvm.system.cpu.utilization - com.sun.management.OperatingSystemMXBean#getSystemCpuLoad()
• process.runtime.jvm.system.cpu.count - java.lang.Runtime#availableProcessors()
• process.runtime.jvm.system.cpu.load.average.1m - java.lang.management.OperatingSystemMXBean#getSystemLoadAverage()

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[jack-berg]

We discussed in the 2/24/2022 Java SIG meeting. Can java folks take a look at this and comment?

/cc @kittylyst @trask

My thoughts:

• process.runtime.jvm.cpu.time, process.runtime.jvm.cpu.utilization are obvious and we should merge those quickly.
• process.runtime.jvm.common.pool.parallelism seems more related to the thread pool topic we discussed. Maybe we should save it for a future PR where we declare the conventions for thread pools.
• process.runtime.jvm.system.cpu.utilization has overlap with the more general system.cpu.utilization, but we don't have access to the data required for the attributes. I think we should include this now.
• process.runtime.jvm.system.cpu.count I think we should incude this now.
• process.runtime.jvm.system.cpu.load.average.1m useful, but overlaps with process.runtime.jvm.cpu.time & process.runtime.jvm.cpu.utilization. I'd be fine skipping this for now.

[trask]

I'm thinking now that it may be good to reuse system.cpu.time, process.cpu.time, and system.cpu.count since there aren't any JVM-specific attributes that we want to capture on them.

I have sent #2388 to clarify that these should be interpreted as container-level and not host-level metrics when emitted from inside a container.

Should we scale back this PR for now to just these two?

• process.runtime.jvm.cpu.utilization
• process.runtime.jvm.system.cpu.utilization

I noticed there's already a system.cpu.utilization metric (and so seems likely to be a process.cpu.utilization metric), but this is defined in a way that I think is incompatible with what the JVM gives us:

system.cpu.utilization is defined as the difference in system.cpu.time measurements divided by the elapsed time

so I don't think we should reuse in this case and need one under process.runtime.jvm.*

[trask]

I think we have more clarity now from discussions in #2384 and #2388.

I think there's still one open question #2392 (comment) and then I think we'll have clarity on how to proceed.

@jonatan-ivanov thanks for your patience

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[trask]

/unstale

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[trask]

@open-telemetry/technical-committee is this not the right place to define JVM metrics that we want to emit? would it be better if we just document these in the Java repo and create our own "jvm metrics" schema url? thx

The reason to block was resolved, still a very confusion proposal for system under process

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[reyang]

I've removed the Stale tag.
Given we've got a good number of approvals from Java experts, I want to see if there is any blocker from @bogdandrutu and @jsuereth. If there is no blocker, I think we should move forward.

[reyang]

@jonatan-ivanov would you resolve the merge conflicts and clear the CI? Thanks!

[jonatan-ivanov]

@reyang Would you approve the workflow to run?

[reyang]

LGTM.

[reyang]

@jonatan-ivanov please send a follow up PR to update the changelog (which is an editorial/trivial change).

[jonatan-ivanov]

@reyang Thanks! Here is the PR for the changelog entry: #2584