Hello,

We have been using Pingplotter for years and reciently installed Pingplotter Pro to centralize monitoring and email alerts when the destinations go offline.

Problem.
We are having an issue with the alerting sending far to many emails. With our current settings we are receiving emails at very short intervals of 5 minutes or more. We really only want them to be every 3 hours.

Question.
How can we change the settings to receive alerts every 180 minutes?

Current Configuration.
Our current trace interval is 2.5 seconds and our alerting configuration examines 100 samples and alerts when 2 or more samples are over 150ms. We are really wanting to monitor for packet loss but this also helps us with extreme latency. We then have the maximum email frequency set at 180 minutes and it waits 1 minute before sending an alert.

Goal.
The desination we are monitoring is experiencing intermittant packet loss and we want to be notified within a couple minutes when the packet loss is over 2% but only receive one email every three hours. Even if the destination goes offline then back on line several times, or stays offline the entire three hours.

The goal is for pingplotter to send an email which then creates a ticket in our helpdesk software. That ticket will then alert our help desk staff of the issue and a tech will then monitor pingplotter and periodically view the web interface over the next three hours and do further troubleshooting if necessary.

P.S. Shouldn't "Maximum e-mail frequency in minutes" really be "Minimum e-mail frequency in minutes"? I say this because the popup dialog says "Dont send e-mail more often than this". Maximum inferrs the alerts will be sent sooner than the specified time but then the popup says the opposite.

Hi, Matt.

How often are you getting emails? With Maximum email frequency set at 180 minutes, you should only be getting emails once every 180 minutes.

The 180 minutes rule only applies to that specific alert instance, though, so if you have the same alert tied to multiple targets, you may be getting alerted multiple times because each target handles the alert separately. In version 3.20, this would happen whenever you tied an alert to an intermediate hop that participated in multiple destinations. With 3.30, though, you can do it globally (like 3.20) or locally (although this requires the use of a workspace).

You can also do this from a different angle. If you set your "samples to examine" to something close to 3 hours worth (in your case, this would be 4320 samples @ 24 per minute), then you can keep the alert firing for 3 hours. If you get a period of packet loss, it will keep the alert firing for as long as those packets are "in scope" of the 4320 samples. Once 3 hours has past, then the packets that fired the alert will go out of scope, and as long as no other bad packets had happened along the way, the alert would go back to "everything is OK" again. Increasing the samples to examine can be effective in managing alerts that regularly go on/off/on/off/on/off, and you don't want to be alerted to the short-term flaps, but just once you get bad conditions, then good conditions.

We cover some of these techniques here:

http://www.nessoft.com/kb/81

Let me know where this leaves you. We've got some other tricks in the bag, but this handles most cases.

- Pete

Pete,
Thanks for replying so quickly.

We were getting emails like every five minutes. The circuit we were monitoring was bouncing up, down, up, down every couple minutes. The issue on the circuit has been resolved so it hasnt happened for quite a while.

I will try setting the samples to examine to 4320 and let you know how it works. Should I also set "Maximum e-mail frequency in minutes" to 1 and "How many minutes to wait before sending" to 1 also?

One more question when setting samples to examine to 4320 does it mean it looks at last 4320 samples from the most current sample when evaluating the alert?

If you're alerting when alert conditions begin / end, then (for this test) you're going to be controlling alert frequency by increasing samples to examine. I'd probably set this to 0 minutes, and also set the minutes to wait to 0 minutes as well. Then, set the "Samples to examine" to a number that's big enough to control over-alerting from up/down "flapping".

If you set the samples to examine to 4320, it does mean that you're looking at the most recent 4320 samples when evaluating the alert. An outage will stay "in scope" of these 4320 samples until you've collected 4320 good samples, so the alert won't go back to "everything is ok" condition for quite some time. This controls the flapping.

Let us know how it goes.