Clarification on Edgetrigger Alerts

[dekenberg]

I would like some clarification on the edgetrigger behavior for Alerts.

I implemented a loss alert with the trigger pattern ==0%, ==0%, ==0% and edgetrigger was set to yes. The expected behavior is that there would be 1 email alert which raised the alert - and then 1 email when the alert was cleared.

The behavior being seen is emails being sent every polling cycle stating that the alert was raised.

I dove into Smokeping.pm and added some syslog to debug and found something that I can't explain the rationale. Currently on Line 2020-2024 $tree->{'prevmatch'.$s}{$_} is either set to 0 or is incremented by 1. This increment can make prevmatch any positive value, while match can only be 0 or 1. It breaks the edgetrigger functionality due to the condition on line 1882 if ($edgetrigger and $prevmatch != $match) and causes this block to resolve to true when it should actually be false. I would like some clarification on if this is intended or if this is an oversight from #52

[karatha]

Dear Team,
Can you offer a quick solution for this edgetrigger issue?
My postbox flooded by alerts mail.

[oetiker]

unfortunately, edge trigger was not in the original design ... it may not work correctly under all circumstances ... I would suggest using two patterns:

>0%, ==0%, ==0%
==0%, ==0%, >%0

[dekenberg]

@karatha from my initial testing I found that reverting the if else blocks from #52 seems to restore the functionality - but I am still working on testing a wider range of alerts

[karatha]

I appreciate your helpfulness. It seem i solved my issue based on oetiker suggestion. I was excited because i have just upgrade from debian 8 to 10 and after the stormy night my postbox flooded due to I'm monitoring ~ 80 sites with smokeping.
Thanks for your effort to developed this nice and reliable monitoring tool.

[meleschi]

I am also seeing this issue with edgetrigger. I have moved to two separate alerts like Oetiker suggested above and the email flood has abated...

For reference, I changed my alerts to this (please ignore their names, they haven't been updated in the config):

+someloss
type = loss
priority = 2
edgetrigger = yes
pattern = ==0%,==0%,>80%
comment = Detected >80% loss

+lossdetect
type = loss
priority = 1
edgetrigger = yes
pattern = >80%,==0%,==0%
comment = Recover from >80% loss

As @karatha stated above, thank you @oetiker for making this tool. It's proved immensely helpful and makes my job much easier when it comes to understanding the state of my systems and network.

[dfrli]

There is also a Debian bug report about this issue:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934170
It also contains the simple fix to make the prevmatch condition boolean by replacing
if ($edgetrigger and $prevmatch != $match)
with
if ($edgetrigger and ($prevmatch == 0 ? 0 : 1) != $match)
which makes the whole edgetrigger functionality working again as expected.
I hope @oetiker can correct this in the source code.

[oetiker]

thanks!