Notification level Was: COMPLETE: RFE(x2): Service Info/Notify Method On Level
Subhendu Ghosh
sghosh at sghosh.org
Sat Jun 7 16:55:06 CEST 2003
On Fri, 6 Jun 2003, Brandon Knitter wrote:
> > > 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?
>
Nagios internals is largely a scheduler. Thats what provides
the flexibility of plugins. By adding built-in functionality, it will
limit the scope of future possibilities.
If LASTSERVICESTATE is needed - lets add that in as a macro.
--
-sg
-------------------------------------------------------
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