Notification level Was: COMPLETE: RFE(x2): Service Info/Notify Method On Level
Brandon Knitter
knitterb at blandsite.org
Sat Jun 7 07:50:56 CEST 2003
> > Are there any plans to put the notification level closer to the service
> rather
> > than just on the contact? Combining this with notification type (page,
> email)
> > on the service would make it so that I can clearly fine tune the
> notification
> > types for an individual service. Of course, if it's not defined on a
> service
> > (making it an optional field) then it could just fall back to the
> contact's
> > preference (service's configuration take's precedense).
> >
> > Just throwing out ideas!
> >
>
> The best way of course would be to pass some $ARG#$ to the notification
> script from the service definition
> (e.g. pointer to 4th contact definition)
Hmmm, intersting hack. But again, that means that I would have to execute the
script only for it to not actually notify. Wouldn't it make more sense to have
Nagios never fork to execute the script in the first place?
Another issue is that if the notification type is RECOVERY, should you notify?
How do you know if it's a RECOVERY from a WARNING or a CRITICAL and whether you
should really alert?
For example, let's say that I have a service which is in WARNING and I want it
to only alert to email, while a CRITICAL should alert to pager. I can easily
do that, but when it goes back to OK state on a recovery, should I alert on
pager or email (in this example email makes sense)? I could see perhaps
maintaining some sort of state outside of Nagios, but that really seems
counterproductive to what Nagios was designed to handle implicitly itself. The
macros $SERVICESTATE$ and $NOTIFICATIONTYPE$ seem to be missing something like
$LASTSERVICESTATE$. I'd need to check the service struct to see if that's even
possible or tracked currently.
The best hack at avoiding a real solution yet, though. Why is everyone okay
with avoiding fixing the problem at the source (Nagios internals) where it
really belongs?
--
-bk
-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
More information about the Developers
mailing list