Below is a post that I made to the nagios-users list over a week ago. I
thought about it, and figured that nagios-devel would be the better place
for it.
Summary: I'm thinking of some global config variable named
"force_hard_state_change_notification". It would be a supplement for people
that have "notification_interval=0" to suppress periodic notifications when
the hard state is the same not-OK state until recovery, but DO want to know
about other hard state changes while not-OK (ie: a transition from WARNING
to CRITICAL).
--- post follows ---
Whoops. Looks like my assessment was not 100% accurate.
When a service goes from WARNING to CRITICAL it _is_ a hard state change.
The problem is that I have notification_interval=0 - which means since it's
already sent single notification for a non-OK state (the WARNING) it will
not send another notification for ANY OTHER non-OK state (the CRITICAL).
What might be the "feature addition" that would make this work for me would
be some option to enable some additional logic so that even if the
notification_interval=0, Nagios should ignore the time interval and attempt
to send a immediate notification (assuming all the other checks like
downtime, flapping, etc. pass) whenever there's hard state change.
I'd like to work on adding this feature (I've spent a lot of time reading
the source at this point) but I don't want to add logic where it doesn't
belong. There's a lot of checks going on with
"check_service_notification_viability" in notifications.c, but there's
nothing about how to determine a hard state change. That's done in checks.c
as part of "reap_service_checks". The "semi-psuedo code" for my suggested
change to "check_service_notification_viability" would be:
/* dont notify contacts about this service problem again if the notification
interval is set to 0
* unless forcing notification due to a hard state change */
if(svc->current_state!=STATE_OK && svc->no_more_notifications==TRUE){
if(force_hard_state_change_notification == FALSE ||
(svc->current_state!=svc->last_state &&
svc->current_attempt>=svc->max_attempts)) {
#ifdef DEBUG4
printf("\tWe shouldn't re-notify contacts about this service
problem!\n");
#endif
return ERROR;
}
#ifdef DEBUG4
else {
printf("\tNotifications about hard state changes were
forced!\n"0;
}
#endif
}
--
"Computer science is as much about computers as
astronomy is about telescopes" -- Edsger Dijkstra
---------------------------------------------------------
Anthony Tonns, UNIX Administrator - [email protected]
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Friday, October 24, 2003 12:22 PM
> To: [email protected]
> Subject: RE: [Nagios-users] Different paging for different levels
>
>
> Matter of factly, your situation doesn't even work properly.
>
> ie:
> If a service goes from OK to WARNING this is a hard state
> change, and it
> will notify via email.
> If it then goes from WARNING to CRITICAL this is NOT a hard
> state change and
> it will NOT notify via pager.
>
> I have not found a solution for this problem. However, I
> would really like
> to be able to handle sending notification via pager when a
> service enters a
> CRITICAL state without adding an ocsp_command.
>
> --
> "Computer science is as much about computers as
> astronomy is about telescopes" -- Edsger Dijkstra
> ---------------------------------------------------------
> Anthony Tonns, UNIX Administrator - [email protected]
>
>
> > -----Original Message-----
> > From: Chris Gill [mailto:[email protected]]
> > Sent: Thursday, October 23, 2003 11:32 AM
> > To: '[email protected]'
> > Subject: [Nagios-users] Different paging for different levels
> >
> >
> > Hi all,
> > We've moved to Nagios here over the last few months,
> > and things have
> > been going swimingly. There's one question, though, that's
> > cropped up that I
> > can't seem to figure out. Is there a way to send different
> > types of alerts
> > based on severity. IE: send warning alerts by e-mail, and
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]