Knowledge Base

Alerting on multiple targets / best practices.

Question

I'm using PingPlotter Pro to monitor multiple targets. Is there any way to make configuring alerts on each target easier?

Solution

One of the main things we find that many people do with alerts is to create a separate alert for each target being monitored. There is a better way. PingPlotter (and MultiPing) alerts can be reused across multiple targets, so you can configure a single alert, and connect it to a bunch of targets, as long as they all have the same alerting needs.

Let's say you want to monitor all your endpoints and notify when any of them have more than 50% packet loss over the last 10 samples.

Making an alert that isn't target-specific.

Create a new alert with the following settings:

  • Alert Name: 50% of packets lost
  • Samples to examine: 10
  • Method (Pro only): Latency and Packet Loss
  • Alert when 5 or more samples are over 1000ms

OK, that's the conditions, what about the events / actions? Many people would like an email when the alert starts to fire, and then another when the incident is over. For this, set the following events (we're assuming that you have email set up correctly in Edit -> Options, Email):

Event 1 - this will send an email when the network goes down

  • Event Type: Send an email
  • Notify: when alert conditions start (enters alert state)
  • Send e-mail to: (your email address, or multiple addresses separated by commas)
  • Important! Subject: $dest down!
  • Maximum e-mail frequency in minutes: 0
  • How many minutes to wait before sending: 0

It's really important to set the proper email subject, because using $dest will mean that you can reuse the same alert on any of your targets, and the subject of the email will change to indicate which target is having problems.

Now, set up event 2 the same way, but set it to Notify: when alert conditions end. Set the subject to '$dest back up!'. Here's a screenshot:

Connecting the alert to targets.

OK, so that's the alert. It's still not connected to any targets yet, though, so we'll need to do that.

To connect an alert to a target, trace to the target, then right-click on the final destination hop and select the 'Watch this host (alerts)...' menu. In the popup there, you'll see a list of Available alerts (these are not watching this target), and an area for Selected alerts (these *are* watching this target). Double-click on your '50% Packet Loss' alert to move it to the 'Selected alerts' side. Close this dialog by selecting 'OK'.

The target/hop you just worked with now has [square brackets] around the hop number, which indicates that it is being watched by alerts.

Repeat these steps for each target you'd like this alert to watch. Verify the [brackets]. Do some testing (disconnect the network cable, or similar).

This makes things easier to troubleshoot and maintain because you don't need to go in and modify 15 or 20 separate alerts. It also makes things more reliable because you don't have to worry about an alert being misconfigured.

Getting meaningful target names

OK, so now the alerts are working, but maybe your alert subjects aren't displaying quite right. Maybe you're seeing 'asjj3.dne.mynet.com down!' or '13.2.5.9 down!' instead of a meaningful name. You need to change the target name - and there's a couple of techniques for this cover in our knowledge base article on changing a target name.

Optimization (if you're getting too many messages!)

This notification method may notify you too much. If that's the case, rather than adjusting the email frequency in the event, try adjusting the 'Samples to examine' for the alert higher. This will look at a bigger window of packets. If you don't increase the 'Alert when' setting, but you do increase the 'Samples to examine', then the alert will be more persistent before it turns off, which means that you'll get fewer emails.

Another thing you may want to do is a 'progression', where you're notified once if a network fails a bit (say 5 of 10 packets fail), but then you get another email if it continues to fail for a longer period of time (say 150 of 150 packets). You can create two separate alerts with these conditions, then you get warned of minor failure and major failure separately - and the minor failure would always notify first.

Other best practices

Only set up alerts on a final destination, unless you're sure that the intermediate router that you're alerting on will never be swapped out of the route. If a router that you're alerting on isn't participating in the route, then you won't get any notifications, even if it was participating in the route at one point. Final destination alerts are always fired, even if they stop responding or the route changes dramatically. Intermediate hops are not.

If you always want to alert an all targets within a submask, try adding a mask by going into the alert configuration, hitting 'Show Targets', and adding a mask there. The easiest mask is 'ALL', which will automatically add this alert to all final destinations you trace to, but you can also do a submask (like 192.168.1.255, which will get the entire 192.168.1.1 - 192.168.1.255 range). Keep in mind that doing masks means that an adhoc trace to a target may add alerts, which may not be appropriate for that target (a quick test to a customer site, for example, may not be appropriate to alert your entire IT team about problems).


Article Rating (7 Votes)

Rate this article


Article Info

Article Number: 81 | Last Updated: December 12, 2014

This article has been viewed 7072 times since July 6, 2009

Filed Under: Alerts

Attachments

There are no attachments for this article.