-
Notifications
You must be signed in to change notification settings - Fork 867
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 runtime.jvm.gc.count metric #2616
Conversation
|
.../library/src/main/java/io/opentelemetry/instrumentation/runtimemetrics/GarbageCollector.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hey @felixbarny, good to see you here!
anyone have any objections to renaming these:
- runtime.jvm.gc.collection -> runtime.jvm.gc.time
- runtime.jvm.gc.collection.count -> runtime.jvm.gc.count
we haven't declared stability of metric names, so it's ok for us to rename existing metrics, and I think these are both shorter and clearer
I can do this in a follow-up PR also.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree with @trask's names :) There are many GC'd languages, getting runtime.*.gc.*
into the spec would probably be nice
The OTel agent already reports the collection time per GC.
The collection count can be useful to compare the count and the duration to see if there are a lot of short GCs or few long GCs, for example.
Please let me know whether you think adding the collection count would also be interesting for OTel.
Background: I'm working for Elastic and we're trying to convert the OTel semantic convention attributes to the Elastic Common Schema so that users can use the OTel agent with the Elastic Stack and the Elastic APM UI. As a part of that effort, we also want to convert the metrics (see elastic/apm-server#4919). We have a screen in our UI displays JVM runtime metrics. One of the charts uses not only the collection time but also the collection count per GC.