search

micrometer-metrics / micrometer

An application observability facade for the most popular observability tools. Think SLF4J, but for observability.
https://micrometer.io
Apache License 2.0
4.44k stars 979 forks source link

Add a metric for tracking heap size after last gc event #5311

Open lenin-jaganathan opened 1 month ago

lenin-jaganathan commented 1 month ago

Please describe the feature request. In most cases for performance optimizations related to memory, it is necessary to understand the GC behavior and the memory allocation/reclamation behaviors. It is in this aspect, that analyzing the various heap region sizes after GC seems to be a very useful metric. The information can be obtained from MemoryPoolMXBean#getCollectionUsage on supported JVM's.

Related metrics in this space, but having the exact snapshot data post-GC helps in applying transformations/aggregations in the backend along with the memory pool names.

shakuzen commented 1 month ago

We also already provide jvm.gc.live.data.size in JvmGcMetrics with the description "Size of long-lived heap memory pool after reclamation". Is that not what you're looking for?

We've abstracted the memory pool name away so the same metric can be used with different GCs.

lenin-jaganathan commented 1 month ago

It doesn't factor in the changes in survivor space. Also, I see most of the time it is not reporting values. longLivedAfter < longLivedBefore returns false and the metric seems to return zero.

Both seem to go away when we use the OperatingSystemMxBean. All the pre-computations are done away with and we can apply the aggregations at the back-end/UI with raw data.