Periodically Log JVM Memory and GC Usage

[alexanderkiel]

Closes: #3522

[codecov]

Codecov Report

❌ Patch coverage is 98.21429% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 95.93%. Comparing base (f6d9752) to head (56db06d).

Files with missing lines	Patch %	Lines
...trics-logger/src/blaze/jvm_metrics_logger/impl.clj	97.29%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3523      +/-   ##
==========================================
- Coverage   95.94%   95.93%   -0.01%     
==========================================
  Files         405      407       +2     
  Lines       25282    25338      +56     
  Branches      658      657       -1     
==========================================
+ Hits        24257    24309      +52     
  Misses        489      489              
- Partials      536      540       +4     

Files with missing lines	Coverage Δ
...vm-metrics-logger/src/blaze/jvm_metrics_logger.clj	100.00% <100.00%> (ø)
...trics-logger/src/blaze/jvm_metrics_logger/impl.clj	97.29% <97.29%> (ø)

... and 2 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[trobanga]

The log-metrics-test only asserts the return value is nil, and the scheduled-*-task-test tests assert (is true) after a sleep. None of these verify that:

• The correct log level (INFO vs WARN) was used
• Logging actually occurred
• The rate-limiting logic throttles info logs to default-interval

Since this feature is specifically about logging at the right level under the right conditions, capturing log output (e.g., via a Timbre appender or with-redefs) would make these tests much more meaningful.

[alexanderkiel]

done

[trobanga]

Nit: last-info-log is initialized to 0, relying on (- (System/nanoTime) 0) being large enough to trigger the first log. System/nanoTime has no guaranteed epoch — its contract only says differences between two calls are meaningful. Initializing to (- (System/nanoTime) default-nanos) would make the "log immediately on first tick" intent explicit and correct by contract.

[alexanderkiel]

done via a combination of interval and warn-factor

[trobanga]

Nit: ManagementFactory/getMemoryMXBean is called twice here (returns the same singleton). Binding it once would be slightly cleaner:

(let [mbean    (ManagementFactory/getMemoryMXBean)
      heap     ^MemoryUsage (.getHeapMemoryUsage mbean)
      non-heap ^MemoryUsage (.getNonHeapMemoryUsage mbean)

[alexanderkiel]

done

[trobanga]

Nit: The coercer here is pos-int? which accepts any positive integer, but the spec constrains to 1–99. Setting JVM_METRICS_LOGGER_WARN_THRESHOLD=100 would pass coercion but fail with a spec error at startup. Not blocking (the spec catches it), but the resulting error message won't be as friendly as a dedicated bounds check.

[alexanderkiel]

done