Create an alert condition whose condition type is "measurement baseline threshold". Notice in the condition table, the string form is this: "Metric Value Baseline [Free Memory < 10.0% of null] I don't know if I'm alerting on average, min or max of the baseline. I think it should be these, depending on the avg/min/max baseline being alerted on: "Metric Value Baseline [Free Memory < 10.0% of average baseline]" "Metric Value Baseline [Free Memory < 10.0% of minimum baseline]" "Metric Value Baseline [Free Memory < 10.0% of maximum baseline]" I do not know if this is going to cause actual errors when determining if an alert is triggered. Right now I suspect this is only a UI issue, which is why its only at medium severity. If this affects the actual alert trigger, it should be increased to high severity/priority.
sorry - ignore that last assignment to jshaugn, wrong BZ
this appears to be worse than just a ui issue. I got baseline alerts to work, but only if I used the "minimum" threshold. Using maximum baseline threshold didn't trigger alerts. Looking in the rhq_alert_condition table, it appears there is nothing getting stored that indicates if something is to use min/avg/max threashold. The column OPTION_STATUS seems to be the more logical place to put such information, but its null (which might be why the UI shows "null" in the condition string). I also assume "null" defaults to "minimum" threshold, since that works. Here's what the row in the DB looks like when setting up a condition "measurement baseline threshold when Free Memory is less than 95% maximum baseline": ID=10017 TYPE=BASELINE MEASUREMENT_DEFINITION_ID=10031 NAME=Free Memory COMPARATOR=< THRESHOLD=0.95 OPTION_STATUS=<null> ALERT_DEFINITION_ID=10012 TRIGGER_ID=<null> Note there is nothing to tell us to use the maximum baseline, versus minimum or average.
from AlertCondition.java: /** * The option string is optional and its semantics differ based on the category of this condition: * AVAILABILITY: the {@link AvailabilityType} to trigger off of (DOWN or UP) * THRESHOLD: for calltime metric conditions, one of "MIN, "MAX", "AVG" - all others are n/a * BASELINE: one of "min", "max" or "mean" - indicates what the threshold is compared to (min/max/avg baseline value) * CHANGE: for calltime metric conditions, one of "MIN, "MAX", "AVG" - all others are n/a * TRAIT: n/a * CONTROL: the {@link OperationRequestStatus} name (SUCCESS, FAILURE, etc). * EVENT: the regular expression of the message to match (which may be empty string if not specified) * * @return additional information about the condition */ public String getOption() { return this.option; } public void setOption(String option) { this.option = option; } from NewConditionEditor.java: case BASELINE: { ... newCondition.setOption(null); ... Why we are setting it to null I have no idea - probably just an oversight.
the fix: @@ -305,3 +305,3 @@ public class NewConditionEditor extends LocatableDynamicForm { newCondition.setComparator(getValueAsString(BASELINE_COMPARATOR_ITEMNAME)); - newCondition.setOption(null); + newCondition.setOption(getValueAsString(BASELINE_SELECTION_ITEMNAME)); newCondition.setMeasurementDefinition(measDef); git commit to master: 3e47bb8 To test, test baseline alerts work for all three types of baseline thresholds - min, max and avg.
Verified on build#149 (Version: 4.1.0-SNAPSHOT Build Number: 04f721e) Created alerts for the condition - Measurement baseline threshold and verified that it works for all three types of baseline thresholds- Minimum, Average and Maximum. Marking as verified.
Bulk closing of issues that were VERIFIED, had no target release and where the status changed more than a year ago.