paketo-buildpacks / libjvm

A library and helper applications that form the basis for building the different Paketo-style JVM-providing buildpacks
Apache License 2.0
19 stars 20 forks source link

Provide Memory Calculator parameters at runtime #425

Closed michael-arndt-gcx closed 1 week ago

michael-arndt-gcx commented 1 week ago

The different parameters of the Memory Calculator, like the thread count, should be available at runtime.

Describe the Enhancement

All parameters, at least LoadedClassCount and ThreadCount are (optionally) made available at runtime.

Possible Solution

Each parameter has a corresponding environment variable, e.g. MEMORY_CALCULATOR_THREAD_COUNT

Motivation

We have multiple cases of out of memory exceptions now, usually due to more loaded classes than anticipated by the Memory Calculator, and we'd like to create alerts for each of the parameters, so we can avoid that. Some of the values the Memory Calculator uses are not available at runtime nor can be derived. Monitoring each of the parameters makes the alert rules clearer, and in case a threshold has been hit, the resulting alert will be clearer.

michael-arndt-gcx commented 1 week ago

After sleeping over it, I realized that BPL_JVM_THREAD_COUNT, BPI_JVM_CLASS_COUNT as well as JAVA_TOOL_OPTIONS are available as environment variables at runtime.

dmikusa commented 1 week ago

If that works, then fantastic, otherwise feel free to reach back out. I'm not opposed to exposing more information. I think I'd want to get some more context about the information you want to gather and how you're wanting to gathering it (mostly before app starts or as app is running and if it's in the JVM process or external).

Thanks

michael-arndt-gcx commented 1 week ago

Thanks for your answer! We're using it with Spring Boot and micrometer, effectively becoming prometheus metrics. I think the ideal solution depends on the stack here. In our case the metric must be repeated, because the prometheus alerts work on a time window – if there was no metric reported for a too long time, the alert would trigger, so reporting only at startup is not enough. We've added the metric by means of a custom Spring Boot autoconfiguration, but I've asked if they'd like this added generally, as I believe we're not the only once who wish to have these alerts.

But again, if your stack is not Spring Boot + Micrometer + Prometheus + Prometheus Alerts, the best way will probably be very different, so I don't think it can be solved further at a Buildpack level, at least not a general-purpose JVM Buildpack.

https://github.com/spring-projects/spring-boot/issues/42458