Add Gauges for memory usage after GC

[shakuzen]

See https://opentelemetry.io/docs/specs/semconv/runtime/jvm-metrics/#metric-jvmmemoryused_after_last_gc.

Register gauges in JvmMemoryMetrics and add MeterConvention for it.

Sample scrape output in Prometheus format with the default convention:

# HELP jvm_memory_used_after_last_gc_bytes Measure of memory used, as measured after the most recent garbage collection event on this pool.
# TYPE jvm_memory_used_after_last_gc_bytes gauge
jvm_memory_used_after_last_gc_bytes{area="heap",id="G1 Eden Space"} 0.0
jvm_memory_used_after_last_gc_bytes{area="heap",id="G1 Old Gen"} 1.7567952E7
jvm_memory_used_after_last_gc_bytes{area="heap",id="G1 Survivor Space"} 6643856.0

With the OpenTelemetry convention configured:

# HELP jvm_memory_used_after_last_gc_bytes Measure of memory used, as measured after the most recent garbage collection event on this pool.
# TYPE jvm_memory_used_after_last_gc_bytes gauge
jvm_memory_used_after_last_gc_bytes{jvm_memory_pool_name="G1 Eden Space",jvm_memory_type="heap"} 0.0
jvm_memory_used_after_last_gc_bytes{jvm_memory_pool_name="G1 Old Gen",jvm_memory_type="heap"} 1.6742336E7
jvm_memory_used_after_last_gc_bytes{jvm_memory_pool_name="G1 Survivor Space",jvm_memory_type="heap"} 5308896.0

[shakuzen]

I figured it is worth running these tests with different GC configurations to ensure there are no surprises.

[shakuzen]

Updated to use @GcTest which is equivalent.

[shakuzen]

I did have a version of this code that registered pools even if this returns null, but they always have the value NaN which didn't seem worthwhile registering.

[shakuzen]

I don't know if it would be better to make this a top level type - it can be a bit annoying to reference it as JvmMemoryMeterConventions.JvmMemoryUsedAfterLastGcConvention, but maybe it also logically groups what would be the individual convention types (if we had them for the other conventions here, that is).

[jonatan-ivanov]

Grouping makes sense to me. Not sure how well-known it is but if people annoyed by using JvmMemoryMeterConventions.JvmMemoryUsedAfterLastGcConvention, they can static import it:

import static io.micrometer.core.instrument.binder.jvm.convention.JvmMemoryMeterConventions.JvmMemoryUsedAfterLastGcConvention;

and use only JvmMemoryUsedAfterLastGcConvention like it would be a top-level type.

[shakuzen]

While other methods here have return type MeterConvention<MemoryPoolMXBean>, that was probably a mistake that I tried to not repeat here. In a framework's configuration model, it would be reasonable for there to be a way for a user to provide a custom convention for a specific convention, and that's made harder by using generic types that do not uniquely identify a single convention.

[jonatan-ivanov]

Should we create an issue for 2.x?

[shakuzen]

The default implementation is not useful, but it was needed since we can't add a new non-default method to the JvmMemoryMeterConventions interface without breaking types that extend/implement it.

[shakuzen]

It's perhaps worth mentioning that there is a similarly named existing gauge for the calculated value of post-GC heap usage percentage:

# HELP jvm_memory_usage_after_gc The percentage of long-lived heap pool used after the last GC event, in the range [0..1]
# TYPE jvm_memory_usage_after_gc gauge
jvm_memory_usage_after_gc{area="heap",pool="long-lived"} 0.0019396338611841202

Maybe it makes sense to deprecate that in lieu of this newly added metric.

[jonatan-ivanov]

Maybe it makes sense to deprecate that in lieu of this newly added metric.

I think so, I'm also thinking to disable it by default in the future and make it possible to the users to re-enable it.

[shakuzen]

I opened #7311 for introducing a proper deprecation concept. Until then, let's start with just mentioning the deprecation in the description of the deprecated meter.

[shakuzen]

I've moved this to 1.18 and made it a draft PR. I want to figure out what we plan to do going forward with the meter conventions (current draft #7369) before adding this. I suppose we could add it first without a convention to avoid tackling that issue, but also no one asked for this, so it doesn't seem high priority either.