Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify relationship between process and runtime semantic conventions #2291

Closed
jack-berg opened this issue Jan 25, 2022 · 3 comments
Closed
Assignees
Labels
spec:metrics Related to the specification/metrics directory

Comments

@jack-berg
Copy link
Member

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 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:

  1. 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.
  2. 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.

@jack-berg jack-berg added the spec:metrics Related to the specification/metrics directory label Jan 25, 2022
@trask
Copy link
Member

trask commented Feb 26, 2022

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)

@jack-berg
Copy link
Member Author

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.

@trask
Copy link
Member

trask commented Mar 2, 2022

I think there's one more related question here that we need clarification on: #2392 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
spec:metrics Related to the specification/metrics directory
Projects
None yet
Development

No branches or pull requests

3 participants