What are the main reasons for notification problems? I want to debug a notifications problem. I do not get any notifications. How do I check my configuration?
Why don't I get notifications from PRTG? What are the Top 5 reasons for notification problems?
1 Reply
This article applies to PRTG Network Monitor 7.x and later versions
Top 5 Reasons for Notification Problems
Although we have tried to make it as easy as possible, configuring notifications in PRTG Network Monitor can be quite complex due to the many parameters a user can change. Here are some aspects you should check if you do not get the notifications from PRTG that you would expect.
Check the manual
In general, there are three steps to take in the PRTG web interface in order to use notifications with PRTG:
- In the "System Setup", check the "Notification Delivery Settings".
- In the "Account Settings", create/edit notifications for later use.
- In an object's settings, create triggers that invoke your notifications.
Please check the manual section Notifications for detailed information.
Top 1: Misconfigured Notification Settings
Log into PRTG's web interface, choose Setup | Notifications from the main menu and click on the Test link of each notification you have trouble with. Do you get all messages? Check your mailbox, pager, mobile phone etc. if all the messages that you have expected actually have arrived.
If they do not, please check the configuration of the affected notifications.
Top 2: SMTP Server Issues
In order to send out emails, PRTG Network Monitor requires a so-called SMTP relay server which accepts emails from PRTG and forwards them to the appropriate mailbox. The IP address or host name of this server and all other SMTP Delivery settings are set in the Notification Delivery Settings (select Setup | System Setup from the main menu).
A common problem are SMTP servers that deny relaying for the server running PRTG. You must synchronize your mail server settings with the settings you have made in PRTG.
When debugging keep an eye on the messages in the System Log (select Logs->System Events->Notifications from main menu). When trying to send an email, PRTG logs whether sending was successful or not.
Also, keep in mind that e.g. while you reboot the server that runs the SMTP server you can not get any mail notifications!
Top 3: Misconfigured Dependencies
Using "dependencies" you can pause the monitoring of sensors or the sending of notifications based on the status of another sensor to avoid false alarms and incorrect recording of downtimes (see manual section Dependencies Concept for more details).
For example, if you monitor servers over a leased line then it makes no sense to send monitoring requests to the servers if the leased line is down since PRTG cannot even reach the servers. The idea is to monitor the availability of the leased line and then pause monitoring of these servers if the leased line is not available at all.
It is important that you double check your dependency settings. Dependencies are edited on each object's settings page (for example on the settings page of a group or sensor). Also remember that dependencies can be inherited from objects higher in the hierarchy (see manual section Inheritance of Settings for more details).
Top 4: Misconfigured Schedules
Using so-called "schedules" you can enable and disable monitoring (for groups, servers, sensors) or the delivery of notifications based on the time of day and/or the day of the week. This can be used, for example, to pause monitoring during the night or to avoid receiving notifications on the weekend.
You can choose a schedules for each object (e.g. a sensor or a group) on it's settings page. To configure schedules, select Setup | Schedules from the main menu.
Top 5: Overlooked Latencies
An often overlooked feature is the latency setting. To avoid receiving too many notifications for only very short failures or delays you can set so-called latencies for every notification trigger. When latencies are set (a value in seconds) a notification is only sent if the failure state takes longer than the latency.
Latencies delay the delivery of a notification. If the sensors comes back up before the latency expires no notification will be sent. PRTG's default values are 60 seconds for latency and 300 seconds for escalation latency. Latencies are configured per notification trigger in the notification trigger settings (select Notifications tab in an object's settings).
Additional Note
We also have seen few cases where Security Software did block the SMTP-Connection of the PRTG Core Service to a mail/SMTP-Relay-Server and it was necessary to add an exception in the Security Software for the "PRTG Server.exe" to enable email-delivery.
Created on Feb 15, 2010 4:52:32 PM by
Daniel Zobel [Paessler Support]
(19,863)
●3
●3
Last change on Dec 20, 2011 7:17:00 PM by
Torsten Lindner [Paessler Support]
(14,360)
●3
●1
Please log in or register to enter your reply.
Add comment