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

Add namespaces to JVM metric attributes? #61

Closed
trask opened this issue May 26, 2023 · 2 comments · Fixed by #20
Closed

Add namespaces to JVM metric attributes? #61

trask opened this issue May 26, 2023 · 2 comments · Fixed by #20
Assignees

Comments

@trask
Copy link
Member

trask commented May 26, 2023

Replaces open-telemetry/opentelemetry-specification#3417

There are (currently) three proposals being discussed for metric attribute namespaces in #51.

This purpose of this issue is to try to arrive at consensus for future JVM metric attribute renames based on each of these three proposals.

Today:

  • process.runtime.jvm.memory.*
    • type
    • pool
  • process.runtime.jvm.gc.duration
    • gc
    • action
  • process.runtime.jvm.threads.count
    • daemon
  • process.runtime.jvm.buffer
    • pool

Option A: No namespaces required

Possibly no change.

Maybe gc -> name to align with Option C.

Option B: Explicit namespaces required

PR already exists for this: #20

  • process.runtime.jvm.memory.*
    • type -> memory.type
    • pool -> memory.pool.name
  • process.runtime.jvm.gc.duration
    • gc -> gc.name
    • action -> gc.action
  • process.runtime.jvm.threads.count
    • daemon -> thread.daemon
  • process.runtime.jvm.buffer
    • pool -> buffer.pool.name

Option C: Namespace inherited from metric namespace

  • process.runtime.jvm.memory.*
    • type (implicitly process.runtime.jvm.memory.type)
    • pool (implicitly process.runtime.jvm.memory.pool)
  • process.runtime.jvm.gc.duration
    • gc -> name (implicitly process.runtime.jvm.gc.name)
    • action (implicitly process.runtime.jvm.gc.action)
  • process.runtime.jvm.threads.count
    • daemon (implicitly process.runtime.jvm.threads.daemon)
  • process.runtime.jvm.buffer
    • pool (implicitly process.runtime.jvm.buffer.pool)
@jack-berg
Copy link
Member

This TC vote has concluded and we should be able to proceed with resolving this issue.

I'm in favor of option c because I view it as the least risky. There's no opportunity for future conventions to disagree with the semantics we define for general memory.type / memory.pool.name / gc.name / gc.action, since all attribute names will be clearly scoped to JVM. If general semantic conventions emerge that match JVM semantics, we can adopt those and change the name of the attributes via telemetry schemas.

@jack-berg
Copy link
Member

I need to clarify my previous comment. I prefer the names of option c, but with fully qualified names rather than relying on any inheritance from the metric name's namespace:

  • process.runtime.jvm.memory.*
    • process.runtime.jvm.memory.type
    • process.runtime.jvm.memory.pool
  • process.runtime.jvm.gc.duration
    • process.runtime.jvm.gc.name
    • process.runtime.jvm.gc.action
  • process.runtime.jvm.threads.count
    • process.runtime.jvm.threads.daemon
  • process.runtime.jvm.buffer
    • process.runtime.jvm.buffer.pool

I also like option b, but don't want to get blocked on a discussion on whether the java memory, gc, thread, and buffer concepts are language agnostic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

Successfully merging a pull request may close this issue.

3 participants