Bug 1105892 - Metric base unit in alert definition is incorrect resulting in bad absolute metric threshold evaluation
Summary: Metric base unit in alert definition is incorrect resulting in bad absolute m...
Alias: None
Product: JBoss Operations Network
Classification: JBoss
Component: Monitoring - Alerts, UI
Version: JON 3.2
Hardware: Unspecified
OS: Unspecified
Target Milestone: DR01
: JON 3.3.0
Assignee: Jay Shaughnessy
QA Contact: Armine Hovsepyan
Depends On:
TreeView+ depends on / blocked
Reported: 2014-06-08 18:57 UTC by Larry O'Leary
Modified: 2015-09-03 00:02 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-12-11 14:00:16 UTC
Type: Bug

Attachments (Terms of Use)
Alert definition (207.77 KB, image/png)
2014-08-08 13:30 UTC, Jan Bednarik
no flags Details

Description Larry O'Leary 2014-06-08 18:57:00 UTC
Description of problem:
When setting an alert definition condition to use a metric's absolute value threshold, the base unit displayed is not the base unit used. This results in bad alert definition conditions being used/applied to a resource.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.  Install and start JBoss ON 3.2 system.
2.  Import RHQ Server resource into inventory.
3.  From the _alerts definitions_ page of the *RHQ Server* resource, create the *High Request Time* alert definition:

    *   *Name*: `High Request Time`
    *   *Condition Type*: *Maximum request time*
    *   *Metric*: *Actual Free Memory*
    *   *Comparator*: *> (Greater Than)*
    *   *Metric Value*: `20`
        **note that *Base Units* indicates *s* for seconds**

Actual results:
Alert condition states: Metric Value Threshold [Maximum request time < 20.0 ms]

Expected results:
Alert condition states: Metric Value Threshold [Maximum request time < 20.0 s]
**OR** Metric Value Threshold [Maximum request time < 20000.0 ms]

Additional info:
Not sure if this is simply a UI issue or a problem with the alert definition page/process. None the less, the issue means that my alert definition condition, at creation time, leads me to believe my threshold is 20 seconds while in reality the alert condition evaluation is 20 milliseconds.

Comment 1 Jay Shaughnessy 2014-07-02 13:58:23 UTC
I have a feeling this is a UI issue in the Add Condition Box.  Looking into it.  For what it's worth, the metric in question is defined as unit=milliseconds, so the actual condition seems correct.

Comment 2 Jay Shaughnessy 2014-07-03 01:41:13 UTC
A tricky UI issue, not an issue with the underlying conditions unless the UI bug caused a mistake in the condition definition.  Introduced I think with the work on Bug 959587.

master commit f07cf57907921190eb792bf24b410f5c9a0babab
Author: Jay Shaughnessy <jshaughn@redhat.com>
Date:   Wed Jul 2 21:38:08 2014 -0400

- fix issue where MeasurementUnits object was used where its String form was
- fix issues with keeping the units paired correctly with the selected
  metric, and ensure the first list entry is always the default.
- simplified the widget initialization (although this was not a primary issue)

Comment 3 Simeon Pinder 2014-07-31 15:52:22 UTC
Moving to ON_QA as available to test with brew build of DR01: https://brewweb.devel.redhat.com//buildinfo?buildID=373993

Comment 4 Jan Bednarik 2014-08-08 13:29:53 UTC
moving to VERIFIED

After Creating the alert "High Request Time" for RHQ Server with condition "Metric Value Threshold", metric "Maximum request time", comparator ">" and metric value "20000 ms", the server shows correct value "20.0 s" if the condition is inspected in web UI (see attached screenshot).

Comment 5 Jan Bednarik 2014-08-08 13:30:15 UTC
Created attachment 925169 [details]
Alert definition

Note You need to log in before you can comment on or make changes to this bug.