add namespace to jvm metric attributes

[zeitlinger]

Successor of open-telemetry/opentelemetry-specification#3464 (review)

Fixes #61

[trask]

From JVM runtime metrics stability WG, I think we had agreed on these attribute names if the outcome of #51 is to namespace metric attributes

[jack-berg]

I posted a comment expressing a preference for a difference strategy, but like this as well if folks are aligned that gc. / memory. / thread. / buffer. are generic enough concepts to not place in a JVM namespace.

[joaopgrassi]

I posted a #61 (comment) expressing a preference for a difference strategy, but like this as well if folks are aligned that gc. / memory. / thread. / buffer. are generic enough concepts to not place in a JVM namespace.

I also have some concerns with the broad gc, memory, thread prefixes. If later we want to document attributes for other GCs then they will collide with these. If they are broad enough, then it probably makes more sense to move them to a separate file, like done for http in http-common.yaml. You can see there the prefix is just http for the attribute_group.

[zeitlinger]

@joaopgrassi fixed the obvious things

[zeitlinger]

@joaopgrassi we decided to qualify all metrics with "jvm." except for thread.daemon - everything should be addressed now

[jsuereth]

Primarily, the schema file should NOT be in the schemas directory, we only create that one when cutting a release.

However, additionally to this attribute rename, we should be renaming the JVM metric namespace as a whole to be jvm.* based on a lot of discussions.

Particularly - We want namespacing to be "reasonably unique" and minimal. process.runtime just doesn't make any sense for the JVM. The JVM is not bound to one process, depending on which architecture it's run on.

[jsuereth]

While I still think we should entertain changing the metrics runtime.process.jvm. => jvm., I think this makes good incremental progress. Still need to address Tigran's comments on the schema file.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: zeitlinger / name: Gregor Zeitlinger (b4aa9c0)
• ✅ login: trask / name: Trask Stalnaker (2149c65, 805d4a8, 88b6cbb, e42581f, 4537ec0)

[trask]

Blocking until the confusion about using top-level namespaces is clarified.

@tigrannajaryan are you ok with unblocking this PR and moving the discussion to #227? or would you like to get resolution on #227 before merging this?

[trask]

/easycla

It's been a while since I reviewed this, given I think things changed, I will look at it again

[joaopgrassi]

Depending which one merges first (#241) one of them will have to adapt either the metric names or the attribute names in the changelog/schema file

[trask]

Depending which one merges first (#241) one of them will have to adapt either the metric names or the attribute names in the changelog/schema file

#241 got merged first, I have resolved conflicts in this PR

[trask]

However, for the attribute names we suggest jvm.* as the namespace. Why this and why not process.runtime.jvm.*? From what I understand it is because jvm.* is shorter. But is it unique enough to ensure there are no clashes? If it is then why not use it also for metric names, e.g. jvm.memory.usage?

@tigrannajaryan we have shortened the metric names also now from process.runtime.jvm.* to jvm.* (#241)

if this resolves your concern, can you unblock? thx