Jay,
Thanks, I think this explains the problem I was having, user error. ;-)
I reread the dampening section and it all looks obvious now. I tried this out and it does
what I want when I set it properly.
Thanks for the help.
Steve
On Mar 28, 2012, at 6:25 AM, Jay Shaughnessy wrote:
> I tried creating an alert on a platform resource, the free memory metric, absolute
threshold > 0, with a dampening of 1 every 10 minutes (see attached images). In the
image you can see that it fired 3 times in 3 minutes (collection interval of 1 minute).
This is similar to the situation I have with a different resource and metric.
Unfortunately the images didn't come through for me, but you may be seeing the
expected behavior. It's not actually "1 *every* 10 minutes", it's
"once every X=1 times the condition set is true within a time period of Y=10
minutes".
That means you get an alert if the condition set matches 1 time within a 10 minute
period. If you report every minute you get a chance of up to 10 evaluations. So X can
validly be set in a range of [1..10]. Since you set X=1, only 1 evaluation has to match
before you get an alert. So, you get 10 alerts. If you want to ensure that you only get
1 alert in 10 minutes then you'd need to set X=10, and the condition set would have to
match 10 times before an alert would be sent. But this is equivalent to the simpler
"consecutive times" dampening.
At least this is how I understand it. I could be wrong.
As far as I know there is no dampening mechanism for limiting the number of alerts sent
based solely on time. We do have recovery alert defs, which means you could fire an
alert, then have that alert def disabled until its recovery alert def fires. But again, I
don't think there exists today a way for a recovery alert def to fire based solely on
the disabled-time of its to-be-recovered alert def.
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel