PingPlotter Tutorial and Product Manual

Contents | Previous | Next

Options - Alerts

What is an alert? Alerts monitor the conditions of a specific IP address, and then do something when those conditions exceed a specific range. The five alert event types you can define 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 that you have a record of every time the problem occurred. One PingPlotter user was having hardware problems with his cable modem. He setup an alert that launched an executable, that then communicated with a device attached to his computer and then that device reset his cable modem based on alert conditions defined within the alert.

Alert setup can at first seem confusing, but really it only involves these three steps:

Setting the Alert Name.
Setting up the Condition that will trigger the alert.
Specifying the Event(s), or what you want PingPlotter to do when your alert(s) are triggered.

Alerts are defined in the Alert Setup screen under the Edit/Alert Setup menu. Once there, you'll see an image similar to the one below. (Note: if you haven't setup an alert before, you won't see any alerts listed in the list area on the far left of the screen shot). This screen is pretty busy, but also pretty self-explanatory. From the screen capture below, you can see that we have (labeled on the image with corresponding numbers in this list):

The Alert Name. In this example we're using "Destination is Over 100ms".
The list of alerts you currently have defined. You can see from the image that we have two defined.
The Conditions for the alert. In other words, what has to happen for this alert to fire.
The Show Targets button that allows us to see how many targets/hops this alert is assigned to, as well as the IP address or DNS name for that hop or hops.
The Notification/Trigger Events for this alert. An unlimited number of events can be tied to an alert, but most likely you won't use more than four or five. Please see the Event Notifications/Trigger Notifications section for all of the trigger notifications available.
Each Event/Trigger Notification will allow you to "do something", based on the overall type of alert you're defining. For example, with a Tray Icon Alert you define the message the pop-up will contain, a Send an Email Alert needs to know where to send the email and with what frequency to send, a Play a Sound Alert needs to know what to play, etc. You enter that information here under the trigger event.
The Edit Body button will take you into the email Alert Email Body Editor, where you can fine tune the alert message body for optimal viewing on a cellphone, pager or other type of handheld device. The Test button will only be visible if you're defining a Send an Email Alert. By clicking this button, you can verify that your email settings are correct, and what your alert email will look like.
To define a new alert you click on the New button. To delete an alert, highlight that alert in the list above these buttons and click on the Delete button. When you're done defining the alert click the OK button. Cancel exits this screen without saving anything.

So referring to the image above, you can see we have an an alert with a Condition defined where when the last 10 samples are greater than 100ms, we want PingPlotter to email us. We've called this alert "Destination is Over 100ms ". If you were watching for a timeout, you'd enter 9999 instead of 100. Do note that 9999 is not a magic number. A lost packet is always greater than any number entered, so you can use 1000, or 20000 here and a dropped packet will exceed either of those numbers.

Setting up an Alert:
First of all, if you're going to setup a "Send an email" event, and you haven't done so already, you need to setup your email configuration in the "Edit/Email Setup" screen. See the bottom of this page, or the email Setup section of this tutorial on how to do this.

Ok, assuming you have your email setup done:
Type in the alert name. In this case it's "Web Server #1 is Down".

Remember your Conditions (or when the alert will fire) for this alert are where when the last 10 samples are greater than 100ms. Enter 10 in the "Traces to Examine" box, because you want PingPlotter to only use the last 10 samples it's done when deciding when to fire the alert. You could easily change this to 5, so you're looking at five samples in a row, or even increase this number further. There's a lot of flexibility here. You will then want to enter 10 in the "Alert when:" box, and 100 in the "or more samples are over" box.

Next you'll setup the Event(s), or what you want to happen when the alert fires. Remember that PingPlotter allows you to specify five different types of events, each of which are explained in detail in their own sections. They are (note these are clickable links) launch an executable, log to a file, play a sound, send an email and tray icon change. You're going to "Send an email" (this is in the Event 1 area) as your event. Notice that as soon as you change the "Event type" to "Send an email", that "Event 2" will appear, with (.. no additional notification ..). You can have as many events as you like, and to delete an event just change it's type to (.. no additional notification ..). As soon as you pick an event type, a set of Notify options relating to that event type will come up. Note: We go into detail about the Notify properties in the alert events - conditions for triggering section.

Tying an alert to an IP
Once you've got your alert setup, you need to tell it which IPs to monitor for those conditions. To do this, trace to a destination just like you normally would. Once the path has listed, pick the router/destination from the trace graph that you want to monitor and right-click on the hop number. From the popup, select Watch this host (Alerts).... You'll get a dialog that shows the DNS name, if there is one, and the IP address you selected in the Title Bar of the window, plus a list of available and selected alerts. Move the alert(s) you want applied to this IP address into the Selected Alert(s) list by using the < and > buttons, and then click the OK button. Monitoring will start immediately.

If you want to monitor a destination that isn't responding for some reason, just right-click on the lower time-graph for that host to get the popup menu.

When a hop is being monitored for an alert, the hop number will have brackets around it (i.e.: [10]).

You can stop monitoring by right-clicking on the hop number, selecting "Watch this host (Alerts)...", and then removing any alerts from the selected list.

A great feature new to Version 2.60 is that of PingPlotter putting a red exclamation point (!) next to a hop that has had an alert fire. This is particularly handy when you have an alert that doesn't give you visual or audio cues normally when it fires, like a Send an Email Alert. Now you can see it on the main PingPlotter screen before the alert email gets to your inbox.

Email Setup

If you want to set up an email alert, you'll have to configure your email setup in this screen first (if you haven't already) by going into Email Setup from the Edit menu. This is a simple process where you enter your SMTP server (i.e. outgoing email server name) and email address. This is important so PingPlotter knows how to send messages. You can also specify whether you want PingPlotter to attach a savefile when an email alert is sent, and also whether you want to include the samples that triggered the alert in the email message that is sent. If your SMTP server requires it, you can enter the login credentials here also.

Here is what the setup screen would look like if you wanted to include the alert samples and attach a PingPlotter save file, using SMTP server foo.myserver.com, with a return email address of badstuff@pingplotter.com. Additionally, notice the Use SMTP Authentication? is checked and a username and password have been entered.

The Email Body Editor is a new feature introduced for PingPlotter v2.60, and that's (as of this writing) being tested in PingPlotter v2.59 Beta. What the Email Body Editor allows you to do is fine tune the body of the alert email to whatever makes sense for your particular receiving device.

For example, if you have alert emails going to your cellphone's inbox, you may only want to have the Target Name, First instance of Failure and Last Instance of Failure in the email. If you have anymore text than that, it will be too long, your cellphone will truncate it and the text is pretty much useless to you. We recognized the fact that a lot of people are using RIM devices, pagers or cellphones to receive alert email, and so now we have an editor to help you out.

You can customize the email body text to your liking in the left pane's editor, highlighting attributes on the left and clicking the Insert Selected Item button to enter that attribute into the body text to the left. This ability to highlight and insert the alert specific attributes is a great way to avoid typographical errors, and is highly recommended. When you're done with your changes, just click the Save button to save your new alert email body. If you get to the point where you want to start over again with the original email, just click the Revert to default email button and then start your changes anew. If you change your mind about editing the email body at all, just click the Cancel button to go back to the Alert Editor.

A note about "average" response times
Before version 2.30, PingPlotter used to support alerting on average response times. The real problem with 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, version 2.30 changed the alerts so you always have to do "when X or more samples is > Y". You can still get good alerts that work similar to how averages worked by saying "when 5 or 10 samples exceeds 300 ms" (this would be like an average over 300ms, but would also fire when there were lost packets).