Whether this is a bug is up to interpretation, for me it is a bug in the design/behavior of the [Non] Heap Used alert setup.

When setting up these definitions the user is presented with the current Max Heap (taken as an avg of the Max Heap metric data points stored for the most recent 6 hrs, I think). He is then asked for Hi/Lo water marks as percentages of the current Max Heap, defaulting to 80/20.

When saved this is turned into a single alert definition, using a single RangeCondition, but the %s are only used to calculate hard values against the current max. The heap max can change but the values do not. This is easily seen if you visit the settings at a later time, you may very well see the pre-filled percentages are no longer 80/20 (for example, if the user took the defaults), but whatever %s the hard values produce against the current heap max avg.

To me this is confusing and likely not what people actually want. I suggest that we replace the current single-rangeCondition trigger with a two-compareCondition ANY trigger.

HK-Alerts actually has a thing called a CompareCondition where you can actually say: HeapUsed > 80% MaxHeap, it can compare the most recent value of one metric as a % of another metric. So the condition is relative to the current values of each metric, not fixed like it is now.

In other words, replace:

Alert If
CurrentHeapUsed outside [fixedLo,fixedHi]

With:

Alert If Either:
CurrentHeapUsed > fixedHiPercent of CurrentHeapMax
CurrentHeapUsed < fixedLoPercent of CurrentHeapMax

Or, just get rid of the "lo" scenario, does low mem really merit a predefined alert?

In the proposed scenario a user does not even need to know or care about the current max heap because the values are all relative.

Because a change would impact end-user behavior I think it needs review by UX or PM. The decision impacts current dev work, so a relatively fast response as to whether to leave as is, or change, would be appreciated.