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

Implement GC duration metric #653

Merged
merged 5 commits into from
Jan 3, 2023
Merged

Conversation

roberttoyonaga
Copy link
Contributor

@roberttoyonaga roberttoyonaga commented Dec 15, 2022

Description:

This PR adds changes that implement the metric process.runtime.jvm.gc.duration.

This was a part of a larger PR here: #644.

jfr-streaming/src/main/java/io/opentelemetry/contrib/jfr/metrics/internal/Constants.java has been kept the same as it was in the larger PR because it's used in all of the smaller constituent PRs. This will hopefully also avoid some conflicts as the PRs are sequentially merged. As a result, there are some constants that are defined, but not used in this PR.

Testing:

Tests were added but they don't have great coverage. In the future we need to devise a reliable way to test each GC. Currently, I'm not sure of a way to change GCs at runtime in order to test them all. I'm also uncertain of how to reliably force young gen GC and old gen GC. As a result, the test added in this PR basically just invokes "some" GC and ensures that the resulting metric has data that is expected.

@@ -50,6 +55,7 @@ static HandlerRegistry createDefault(MeterProvider meterProvider) {
var seen = new HashSet<String>();
for (var bean : ManagementFactory.getGarbageCollectorMXBeans()) {
var name = bean.getName();
garbageCollectors.add(name);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's pretty tricky to tell which handlers get added in response to which garbage collectors. How about just a switch statement with cases for each known garbage collector bean name, where each case explicitly registers its required handlers?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that's a good idea. Implemented suggestion.

@@ -72,7 +86,8 @@ static HandlerRegistry createDefault(MeterProvider meterProvider) {
new ContainerConfigurationHandler(),
new LongLockHandler(grouper),
new ThreadCountHandler(),
new ClassesLoadedHandler());
new ClassesLoadedHandler(),
new OldGarbageCollectionHandler(garbageCollectors));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These could be added in the switch statement as well. Instead of passing the set of garbageCollectors you could pass the name of the garbage collector as a constructor argument.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a good idea. It also allows us to get rid of the set caching all the GC types. Done!

Copy link
Member

@jack-berg jack-berg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One last simplification

roberttoyonaga and others added 2 commits December 22, 2022 16:04
…cs/internal/GarbageCollection/OldGarbageCollectionHandler.java

Co-authored-by: jack-berg <34418638+jack-berg@users.noreply.github.com>
…cs/internal/GarbageCollection/YoungGarbageCollectionHandler.java

Co-authored-by: jack-berg <34418638+jack-berg@users.noreply.github.com>
@trask trask merged commit bfea44a into open-telemetry:main Jan 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants