Our tech support team is happy to help you with any questions you might have. Contact us on our online support forum at https://support.nagios.com/forum/
Nagios XI is the easy-to-use, enterprise version of Nagios that features:
Download a free 30-day trial of Nagios XI or give the online demo a spin.
Inquire today and let our Quickstart team help you get started with Nagios XI
There have been a lot of questions as to exactly how notifications work. This will attempt to explain exactly when and how host and service notifications are sent out, as well as who receives them.
Notification escalations are explained here.
The decision to send out notifications is made in the service check and host check logic. The calculations for whether a notification is to be sent are only triggered when processing a host or service check corresponding to that notification; they are not triggered simply because the has passed since a previous notification was sent. Host and service notifications occur in the following instances:
Note: If the host is in a hard or soft non-OK state, notifications for services on this host won't be sent out.
Each host and service definition has a contact_groups> option that specifies what contact groups receive notifications for that particular host or service. Contact groups can contain one or more individual contacts.
When Nagios Core sends out a host or service notification, it will notify each contact that is a member of any contact groups specified in the contactgroups> option of the service definition. Nagios Core realizes that a contact may be a member of more than one contact group, so it removes duplicate contact notifications before it does anything.
Just because there is a need to send out a host or service notification doesn't mean that any contacts are going to get notified. There are several filters that potential notifications must pass before they are deemed worthy enough to be sent out. Even then, specific contacts may not be notified if their notification filters do not allow for the notification to be sent to them. Let's go into the filters that have to be passed in more detail.
You can have Nagios Core notify you of problems and recoveries pretty much anyway you want: pager, cellphone, email, instant message, audio alert, electric shocker, etc. How notifications are sent depend on the notification commands that are defined in your object definition files.
Note: If you install Nagios Core according to the quickstart guide, it should be configured to send email notifications. You can see the email notification commands that are used by viewing the contents of the following file: /usr/local/nagios/etc/objects/commands.cfg.
Specific notification methods (paging, etc.) are not directly incorporated into the Nagios Core code as it just doesn't make much sense. The "core" of Nagios Core is not designed to be an all-in-one application. If service checks were embedded in Nagios Core it would be very difficult for users to add new check methods, modify existing checks, etc. Notifications work in a similar manner. There are a thousand different ways to do notifications and there are already a lot of packages out there that handle the dirty work, so why re-invent the wheel and limit yourself to a bike tire? Its much easier to let an external entity (i.e. a simple script or a full-blown messaging system) do the messy stuff. Some messaging packages that can handle notifications for pagers and cellphones are listed below in the resource section.
When crafting your notification commands, you need to take into account what type of notification is occurring. The $NOTIFICATIONTYPE$ macro contains a string that identifies exactly that. The table below lists the possible values for the macro and their respective descriptions:
| Value | Description |
|---|---|
| PROBLEM | A service or host has just entered (or is still in) a problem state. If this is a service notification, it means the service is either in a WARNING, UNKNOWN or CRITICAL state. If this is a host notification, it means the host is in a DOWN or UNREACHABLE state. |
| RECOVERY | A service or host recovery has occurred. If this is a service notification, it means the service has just returned to an OK state. If it is a host notification, it means the host has just returned to an UP state. |
| ACKNOWLEDGEMENT | This notification is an acknowledgement notification for a host or service problem. Acknowledgement notifications are initiated via the web interface by contacts for the particular host or service. |
| FLAPPINGSTART | The host or service has just started flapping. |
| FLAPPINGSTOP | The host or service has just stopped flapping. |
| FLAPPINGDISABLED | The host or service has just stopped flapping because flap detection was disabled.. |
| DOWNTIMESTART | The host or service has just entered a period of scheduled downtime. Future notifications will be supressed. |
| DOWNTIMESTOP | The host or service has just exited from a period of scheduled downtime. Notifications about problems can now resume. |
| DOWNTIMECANCELLED | The period of scheduled downtime for the host or service was just cancelled. Notifications about problems can now resume. |
There are many ways you could configure Nagios Core to send notifications out. Its up to you to decide which method(s) you want to use. Once you do that you'll have to install any necessary software and configure notification commands in your config files before you can use them. Here are just a few possible notification methods:
Basically anything you can do from a command line can be tailored for use as a notification command.
If you're looking for an alternative to using email for sending messages to your pager or cellphone, check out these packages. They could be used in conjuction with Nagios Core to send out a notification via a modem when a problem arises. That way you don't have to rely on email to send notifications out (remember, email may *not* work if there are network problems). I haven't actually tried these packages myself, but others have reported success using them.
If you want to try out a non-traditional method of notification, you might want to mess around with audio alerts. If you want to have audio alerts played on the monitoring server (with synthesized speech), check out Festival. If you'd rather leave the monitoring box alone and have audio alerts played on another box, check out the Network Audio System (NAS) and rplay projects.
