diff -ur nagios-2.5.pre_escalationlevels/base/notifications.c nagios-2.5/base/notifications.c --- nagios-2.5.pre_escalationlevels/base/notifications.c 2006-04-07 23:24:13.000000000 +0100 +++ nagios-2.5/base/notifications.c 2006-09-11 21:17:51.328418915 +0100 @@ -491,11 +491,25 @@ /* check viability of sending out a service notification to a specific contact (contact-specific filters) */ int check_contact_service_notification_viability(contact *cntct, service *svc, int type){ + int notification_number; #ifdef DEBUG0 printf("check_contact_service_notification_viability() start\n"); #endif + /* if this is a recovery, really we check for who got notified about a previous problem */ + if(svc->current_state==STATE_OK) + notification_number=svc->current_notification_number-1; + else + notification_number=svc->current_notification_number; + + if(notification_number < cntct->notification_level) { +#ifdef DEBUG4 + printf("\tThis contact's notification_level is greater than the current notification number\n"); +#endif + return ERROR; + } + /* see if the contact can be notified at this time */ if(check_time_against_period(time(NULL),cntct->service_notification_period)==ERROR){ #ifdef DEBUG4 @@ -1240,11 +1254,25 @@ /* checks the viability of notifying a specific contact about a host */ int check_contact_host_notification_viability(contact *cntct, host *hst, int type){ + int notification_number; #ifdef DEBUG0 printf("check_contact_host_notification_viability() start\n"); #endif + /* if this is a recovery, really we check for who got notified about a previous problem */ + if(hst->current_state==HOST_UP) + notification_number=hst->current_notification_number-1; + else + notification_number=hst->current_notification_number; + + if(notification_number < cntct->notification_level) { +#ifdef DEBUG4 + printf("\tThis contact's notification_level is greater than the current notification number\n"); +#endif + return ERROR; + } + /* see if the contact can be notified at this time */ if(check_time_against_period(time(NULL),cntct->host_notification_period)==ERROR){ #ifdef DEBUG4 diff -ur nagios-2.5.pre_escalationlevels/common/objects.c nagios-2.5/common/objects.c --- nagios-2.5.pre_escalationlevels/common/objects.c 2006-09-11 12:52:10.000000000 +0100 +++ nagios-2.5/common/objects.c 2006-09-11 17:46:42.465474286 +0100 @@ -2091,7 +2091,7 @@ /* add a new contact to the list in memory */ -contact *add_contact(char *name,char *alias, char *email, char *pager, char **addresses, char *svc_notification_period, char *host_notification_period,int notify_service_ok,int notify_service_critical,int notify_service_warning, int notify_service_unknown, int notify_service_flapping, int notify_host_up, int notify_host_down, int notify_host_unreachable, int notify_host_flapping, int can_submit_commands){ +contact *add_contact(char *name,char *alias, char *email, char *pager, char **addresses, char *svc_notification_period, char *host_notification_period,int notify_service_ok,int notify_service_critical,int notify_service_warning, int notify_service_unknown, int notify_service_flapping, int notify_host_up, int notify_host_down, int notify_host_unreachable, int notify_host_flapping, int can_submit_commands, int notification_level){ contact *temp_contact; contact *new_contact; int x; @@ -2368,6 +2368,7 @@ new_contact->notify_on_host_unreachable=(notify_host_unreachable>0)?TRUE:FALSE; new_contact->notify_on_host_flapping=(notify_host_flapping>0)?TRUE:FALSE; new_contact->can_submit_commands=(can_submit_commands>0)?TRUE:FALSE; + new_contact->notification_level=notification_level; new_contact->next=NULL; new_contact->nexthash=NULL; diff -ur nagios-2.5.pre_escalationlevels/html/docs/xodtemplate.html nagios-2.5/html/docs/xodtemplate.html --- nagios-2.5.pre_escalationlevels/html/docs/xodtemplate.html 2006-09-11 12:52:10.000000000 +0100 +++ nagios-2.5/html/docs/xodtemplate.html 2006-09-11 21:21:39.429911809 +0100 @@ -800,6 +800,7 @@
@@ -82,7 +78,7 @@
-The first filter for host or service notifications is a check to see if the host or service is in a period of scheduled downtime. It it is in a scheduled downtime, no one gets notified. If it isn't in a period of downtime, it gets passed on to the next filter. As a side note, notifications for services are suppressed if the host they're associated with is in a period of scheduled downtime. +The first filter for host or service notifications is a check to see if the host or service is in a period of scheduled downtime. If it is in a scheduled downtime, no one gets notified. If it isn't in a period of downtime, it gets passed on to the next filter. As a side note, notifications for services are suppressed if the host they're associated with is in a period of scheduled downtime.
@@ -112,19 +108,20 @@ The first filter that must be passed for each contact are the notification options. Each contact definition contains options that determine whether or not service notifications can be sent out for warning states, critical states, and recoveries. Each contact definition also contains options that determine whether or not host notifications can be sent out when the host goes down, becomes unreachable, or recovers. If the host or service notification does not pass these options, the contact will not be notified. If it does pass these options, the notification gets passed to the next filter... Note: Notifications about host or service recoveries are only sent out if a notification was sent out for the original problem. It doesn't make sense to get a recovery notification for something you never knew was a problem...
++The second filter that must be passed is the contact's <notification_level> option. Each time a notification is sent out for a service in a problem state, the notification number is incremented by 1 - this is reset to 1 when the service recovers. If a contact's <notification_level> is not greater or equal to the notification number, the contact will not be notified. This is a simple form of escalation. See here for more advanced escalation options. +
The last filter that must be passed for each contact is the time period test. Each contact definition has a <notification_period> option that specifies which time period contains valid notification times for the contact. If the time that the notification is being made does not fall within a valid time range in the specified time period, the contact will not be notified. If it falls within a valid time range, the contact gets notified!
- -What Aren't Any Notification Methods Incorporated Directly Into Nagios?
-I've gotten several questions about why notification methods (paging, etc.) are not directly incorporated into the Nagios code. The answer is simple - it just doesn't make much sense. The "core" of Nagios 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 similiar 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. +I've gotten several questions about why notification methods (paging, etc.) are not directly incorporated into the Nagios code. The answer is simple - it just doesn't make much sense. The "core" of Nagios 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 similiar 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? It's 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.
@@ -152,7 +149,6 @@ There are many ways you could configure Nagios 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. @@ -172,18 +167,16 @@ If you're interested in sending an alphanumeric notification to your pager or cellphone via email, you may be find the following information useful. Here are a few links to various messaging service providers' websites that contain information on how to send alphanumeric messages to pagers and phones...
--
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 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. @@ -201,10 +193,7 @@ Lastly, there in an area in the contrib downloads section on the Nagios homepage for notification scripts that have been contributed by users. You might find these scripts useful, as they take care of a lot of the dirty work needed to send out alphanumeric notifications...
--
-