Bug 999109 - "Get Live Value" for metrics needs to note that the value is used for alert condition evaluation and can impact dampening
"Get Live Value" for metrics needs to note that the value is used for alert c...
Status: CLOSED CURRENTRELEASE
Product: JBoss Operations Network
Classification: JBoss
Component: Documentation (Show other bugs)
JON 3.1.2
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Deon Ballard
Mike Foley
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-20 14:28 EDT by Larry O'Leary
Modified: 2014-10-23 08:26 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-05-09 23:41:59 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Larry O'Leary 2013-08-20 14:28:35 EDT
Part of the work done in https://bugzilla.redhat.com/show_bug.cgi?id=988881 was to use the value(s) returned from "Get Live Value" button on the metrics page as if it was returned as part of metric collection and therefore use it for evaluating alerts.

Because each click of the "Get Live Value" button for a metric will add an additional collection to the metric collection schedule interval, this can impact metric alerts that use dampening with rules such as:

    Consecutive
    Last N Evaluations

In those cases, if you have configured a dampening rule based on the number of collections and are expecting the number of collections to occur in a specific amount of time based on the collection frequency as configured by the metric collection schedule, using "Get Live Values" may alter that timing. For example:

If you collect the Free Memory metric every 1 minute and configure an alert definition to trigger an alert when Free Memory is below 1GB for 5 consecutive collections, the expectation may be that an alert will only fire if Free Memory is less then 1GB for 5 or more minutes. However, if a user of the system selects the Free Memory metric and clicks the "Get Live Value", this will count toward the 5 consecutive occurrences. Meaning that 5 consecutive occurrences could now happen in as little as 4 minutes. If "Get Live Values" is clicked again, it is possible that the alert will be triggered in as little as 3 minutes. 

We should probably make mention of this in the release notes as this is a change from prior versions and also note it in the relevant sections talking about retrieving live metrics such as in 4.3. Viewing Live Values[1] and 2.1. Monitoring and Types of Data[2] (not sure it is actually necessary in [2] though as this seems to be a generic topic regarding what types of data exist).


[1]: https://access.redhat.com/site/documentation/en-US/JBoss_Operations_Network/3.1/html/Admin_Setting_up_Monitoring_Alerts_and_Operations/monitoring-and-events.html#live-data
[2]: https://access.redhat.com/site/documentation/en-US/JBoss_Operations_Network/3.1/html/Admin_Setting_up_Monitoring_Alerts_and_Operations/summary.html#about-monitoring
Comment 1 Deon Ballard 2013-11-22 15:45:12 EST
On reading this, I don't think there are any changes to make to [2] -- that is a more general section on types of data, but not specifically on retrieving data. And "get live values" is more of an active step about retrieving data.

As for [1], I didn't make the specified changes, I removed it entirely. Bug 1024999 describes it, but the 'live values' button was removed from the UI, and, instead, the live values are retrieved at the refresh interval of the UI as long as the resource page is open. So, that's a difference.

As part of changes for Bug 1024999, I will mention that refreshing the value can affect dampening, and also in the release notes.
Comment 2 Deon Ballard 2014-05-09 23:41:59 EDT
Mass closure of bugs modified in 2013. All of these are in the currently-published docs.

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