Add GC duration histogram

[zeitlinger]

Supercedes #1738

introduces a Prometheus histogram metric jvm_gc_duration_seconds to record JVM garbage collection pause durations. existing metrics provide limited visibility into long GC pauses, making it difficult to detect latency spikes. this change leverages the already registered GC notifications (as used in JvmMemoryPoolAllocationMetrics) to capture pause durations without additional instrumentation.

the histogram uses 0.01, 0.1, 1, 10 buckets and includes labels for gc name, action, and cause, enabling detailed monitoring of both short and long GC pauses. this addresses the lack of visibility highlighted in community discussions such as this one. buckets are also defined according to the opentelemetry semantic conventions spec

Example result:

# HELP jvm_gc_duration_seconds JVM GC pause duration histogram.
# TYPE jvm_gc_duration_seconds histogram
jvm_gc_duration_seconds_bucket{action="end of minor GC",cause="G1 Evacuation Pause",gc="G1 Young Generation",le="0.01"} 806
jvm_gc_duration_seconds_bucket{action="end of minor GC",cause="G1 Evacuation Pause",gc="G1 Young Generation",le="0.1"} 806
jvm_gc_duration_seconds_bucket{action="end of minor GC",cause="G1 Evacuation Pause",gc="G1 Young Generation",le="1.0"} 806
jvm_gc_duration_seconds_bucket{action="end of minor GC",cause="G1 Evacuation Pause",gc="G1 Young Generation",le="10.0"} 806
jvm_gc_duration_seconds_bucket{action="end of minor GC",cause="G1 Evacuation Pause",gc="G1 Young Generation",le="+Inf"} 806
jvm_gc_duration_seconds_count{action="end of minor GC",cause="G1 Evacuation Pause",gc="G1 Young Generation"} 806
jvm_gc_duration_seconds_sum{action="end of minor GC",cause="G1 Evacuation Pause",gc="G1 Young Generation"} 0.7360000000000005

[jaydeluca]

should we be consistent with the way the other metric is defined?

Suggested change

	private static final String JVM_GC_DURATION = "jvm.gc.duration";
	private static final String JVM_GC_DURATION = "jvm_gc_duration";

[jaydeluca]

try/catch here to avoid crashing the JVM is the notification listener throws something

Suggested change

	if (!GarbageCollectionNotificationInfo.GARBAGE_COLLECTION_NOTIFICATION.equals(
	notification.getType())) {
	return;
	}
	GarbageCollectionNotificationInfo info =
	GarbageCollectionNotificationInfo.from(
	(CompositeData) notification.getUserData());
	observe(gcDurationHistogram, info);
	try {
	if (!GarbageCollectionNotificationInfo.GARBAGE_COLLECTION_NOTIFICATION.equals(
	notification.getType())) {
	return;
	}
	GarbageCollectionNotificationInfo info =
	GarbageCollectionNotificationInfo.from(
	(CompositeData) notification.getUserData());
	observe(gcDurationHistogram, info);
	} catch (Exception e) {
	logger.warning(
	"Exception while processing garbage collection notification: " + e.getMessage());
	}

[jaydeluca]

jvm.gc.cause is still experimental, should we hold off on that one until it stabilizes?

[jaydeluca]

taking a look at the OTel implementation, they also track the listeners and do a cleanup, not sure if it makes sense for us to implement something like that, by making JvmMetrics an AutoClosable. Looks like it ends up requiring a lot of changes, not sure if its worth it

Another thing they do is check to see if the class exists first , which I think would be good to do here too

[jaydeluca]

Suggested change

	public void testNonOtelMetricsAbsentWhenUseOtelEnabled() {
	void testNonOtelMetricsAbsentWhenUseOtelEnabled() {

[jaydeluca]

Suggested change

	public void testGCDurationHistogramLabels() throws Exception {
	void testGCDurationHistogramLabels() throws Exception {