Bug 698320 - Dampening on consecutive count does not work for equals comparision
Dampening on consecutive count does not work for equals comparision
Product: RHQ Project
Classification: Other
Component: Alerts (Show other bugs)
Unspecified Unspecified
medium Severity unspecified (vote)
: ---
: ---
Assigned To: Heiko W. Rupp
Mike Foley
Depends On:
  Show dependency treegraph
Reported: 2011-04-20 11:55 EDT by Heiko W. Rupp
Modified: 2013-11-01 17:28 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-09-02 03:20:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Screenshot of the alert history. (82.43 KB, image/png)
2011-04-20 11:59 EDT, Heiko W. Rupp
no flags Details
Plugin that generates the pattern mentioned in the case (6.26 KB, application/java-archive)
2011-04-20 12:02 EDT, Heiko W. Rupp
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 51814 None None None Never

  None (edit)
Description Heiko W. Rupp 2011-04-20 11:55:15 EDT
Have e.g. a metric sender that is sending 

1,0,0,0,0,0,1,0,0,0,... (that is 1, five zeros, 1 , five zeros, ... )

and put an alert on condition "value == 0" for three consecutive times.

You will see that this actually fires at index 4 (the third zero in above series, starting to count at 1 ) and at index 8, which is the first 0 after the 2nd 1.

This is wrong, as the second '1' breaks the sequence of 3 consecutive 0s.

Now set up a 2nd alert, where the condition is slightly altered to say "value < 0.1". Now the alert correctly fires at index 4 and 10 - each time when three zeroes have been detected.

The difference between == and < is in org.rhq.enterprise.server.alert.engine.model.AlertConditionOperator :


Where Type.STATELESS prohibits sending a "start counting" message in org.rhq.enterprise.server.alert.engine.internal.AbstractConditionCache#processCacheElements
Comment 1 Charles Crouch 2011-04-20 11:58:30 EDT
Ok so we have a workaround for the current release. But this should be fixed in master
Comment 2 Heiko W. Rupp 2011-04-20 11:59:58 EDT
Created attachment 493531 [details]
Screenshot of the alert history.

Screenshot of fired alerts.

the 1 are sent at 
XX Wed Apr 20 17:28:06 CEST 2011 -- 1
XX Wed Apr 20 17:34:06 CEST 2011 -- 1
XX Wed Apr 20 17:40:06 CEST 2011 -- 1
XX Wed Apr 20 17:46:06 CEST 2011 -- 1
XX Wed Apr 20 17:52:06 CEST 2011 -- 1
XX Wed Apr 20 17:58:06 CEST 2011 -- 1

metrics are sent each minute , so the alert has to trigger 3 minutes after the 1 is sent. This happens for the lt ('<') case correctly.
Comment 3 Heiko W. Rupp 2011-04-20 12:02:21 EDT
Created attachment 493532 [details]
Plugin that generates the pattern mentioned in the case
Comment 4 Heiko W. Rupp 2011-04-27 09:26:39 EDT
Changed '=' to stateful in 1bba9e4a61e82160afc7924e167f3da56187cabb
Comment 5 Heiko W. Rupp 2011-04-28 04:41:54 EDT
Note that you can use the new pattern-plugin to generate sequences of 1s and 0s 
of arbitrary lengths to test this.
Comment 6 Mike Foley 2011-06-21 15:45:57 EDT
verified using the attached 'pattern' plug-in.  set an alert, as described, with dampening.  the alert fired, and then was correctly dampened.
Comment 7 Heiko W. Rupp 2013-09-02 03:20:01 EDT
Bulk closing of issues that were VERIFIED, had no target release and where the status changed more than a year ago.

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