Alert Setup

What is an alert?

Alerts basically monitor the conditions of a specific IP address, and then do something when those conditions exceed a specific range. The things you can do with an alert are:

For example, let's say you need to know when a destination you're monitoring stops responding. You can attach an alert within PingPlotter to that IP address so that you receive an email alert if the last 10 of 10 sample requests are lost.

Another possible alert condition to check for is if the average for the last 10 samples is > 500 (or any other number). You can send an email alert, maybe play a .WAV file (if you're usually within hearing distance) or both. Also, if you're trying to show your ISP there's a problem, you might log the data to a file so you have records of every time it happened over a time period.

Setting up an alert.

PingPlotter v5 introduces a new guided alert setup process. To start setting up a new alert, either select a target from a summary screen, or open a trace window for a target, and click on the "Alerts" tab - which can be found on the right hand side of the application.

Once the alert sidebar is opened, we land on a screen that will tell us any alert info that may be present for the target we've chosen. From here, we're also be able to create a new alert that will be stored in our alert library - so that we can use it on any of our targets.

Setting up a New Alert

For this example, we'll be setting up an alert that will play a buzzer sound anytime our target experiences latency higher that 250 milliseconds for 10% (or more) of a 10 minute timeframe. First, we'll select the "Play a Sound" option from the "Create a New Alert section, which will prompt us to enter our alert conditions.

There are two different options for setting up alert conditions:

  • Latency and Packet Loss Over Time - (the option we're using in this example)
  • Latency and Packet Loss Over a Sample Count (which allows us to look at a certain number of samples, and trigger an alert when a set amount of samples exceed our desired latency)

Once we've set our conditions, click on "Next," and in step 2 we can configure what sound file we'd like to play, and when we'd like it to play.

There are four different notification preferences:

If we'd like our sound to play when alert conditions start, and then have a different sound play when the conditions end, this is totally possible (and encouraged!). We'll go ahead and select "When alert conditions start" for the first part of this alert, and then choose the sound file we'd like to play and click "Next."

From the alert summary screen, we'll get an overview of what our alert is configured to do. To set up another sound that will play when alert conditions end, click on the "Add Action" button.


From this screen, we can select another action type and set the notification preference we'd like ("When alert conditions end"). Once everything on the alert summary screen looks to be in order - we can give our alert a name and click on the "Finish" button.

Once we've finished setting up our alert, we'll land back on the original alert screen, which will now show our new alert under the "Alerts for this Target" section. If we want to change anything about the alert (pick a different sound file, adjust the alert conditions, etc), we can click on the edit button. We can also remove the alert from a target by clicking on the delete button. Clicking on the delete button in the "Your Alert Library" section will completely remove the alert from the program (as well as from any targets it happens to be associated with).

If we've got another target that we'd like to apply our alert to, simply open a trace window for that target. The alert will be in the alert library, and clicking the green add button will move it into the "Alerts for this target" section.

Alerting on packet loss.

A common condition to want to alert on is packet loss.  The fields you need to manipulate are in the Alert setup screen is the "Alert conditions" portion.

Example: Let's say you want to notify when packet loss equals or exceeds 40%.

To do this, set "Samples to Examine" to 10, and Alert when "4" or more samples are over 9999ms. A lost packet always exceeds any number you enter in the threshold area, so if you want to consider only explicitly lost packets, set this to 9999. If you want to consider any really high latency packets as well, set this to something lower (maybe 1000 or 1500).

This only examines the last 10 packets, but let's say you want to examine a higher period - and notify on a lower packet loss percentage.

Set Samples to examine to 10000 (or some other high number). Alert when "500" or more samples are over 2500ms. This will alert when you hit 5% packet loss over a period of a few hours (depending on what trace interval you use).

A note about "average" response times.

Average response times are a problem.  The real problem with mean averages is when a server stops responding - what is the average of the last 10 samples if the last 10 were timeouts?  Because of the problem with this we always do "when X or more samples is > Y" (this is a median average).  You can still get your alert to work like an average - by saying "when 5 or 10 samples exceeds 300 ms" (this would be like a mean average over 300ms, but would also fire when there were lost packets).