You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We've been discussing JVM runtime semantic conventions in the JVM metrics SIG and a question has come up of what to do when overlaps with process metrics occur.
For example, we'd like to be able to capture the CPU time of the JVM, e.g. process.runtime.jvm.cpu.time. However, there's already a process.cpu.time semantic convention, which overlaps with our JVM CPU time conceptually, but whose attributes we would not be able to populate from JVM data.
It seems good to capture CPU time as provided by the JVM, since the information is useful in scenarios where a separate process isn't already reporting the process CPU time.
Some options:
Introduce separate runtime metrics that somewhat duplicate process metrics. CPU time and memory may appear in both process and runtime metrics, but have different attributes that differ and make each useful. Note that this implies that concepts like CPU time and memory usage may have many definitions as each runtime may record it own definition with minor variations.
Allow runtimes to report process metrics to the extent that they have the information. E.g. a JVM could report process.cpu.time, but omit the attributes which it cannot populate.
I'm in favor of the first option because trying to force all runtimes to report against a common standard will cause attributes to be omitted that would otherwise be useful.
The text was updated successfully, but these errors were encountered:
I'm thinking now that it may be good to reuse system.cpu.time, process.cpu.time, and system.cpu.count in Java at least, since there aren't any JVM-specific attributes that we want to capture on them.
trying to force all runtimes to report against a common standard will cause attributes to be omitted that would otherwise be useful
👍 I think it would be ok for the decision to use common vs runtime-specific metric to be on a case-by-case basis, based on whether the runtime wanted to provide additional useful attributes for a particular metric (e.g. process.runtime.jvm.memory.usage)
If I'm not mistaken this conversation seems to resolve this issue with the conclusion that if a process wishes to observe system level metrics, it should do so under the process namespace.
Closing for now - can reopen if I've misinterpreted.
What are you trying to achieve?
We've been discussing JVM runtime semantic conventions in the JVM metrics SIG and a question has come up of what to do when overlaps with process metrics occur.
For example, we'd like to be able to capture the CPU time of the JVM, e.g.
process.runtime.jvm.cpu.time
. However, there's already aprocess.cpu.time
semantic convention, which overlaps with our JVM CPU time conceptually, but whose attributes we would not be able to populate from JVM data.It seems good to capture CPU time as provided by the JVM, since the information is useful in scenarios where a separate process isn't already reporting the process CPU time.
Some options:
process.cpu.time
, but omit the attributes which it cannot populate.I'm in favor of the first option because trying to force all runtimes to report against a common standard will cause attributes to be omitted that would otherwise be useful.
The text was updated successfully, but these errors were encountered: