Notification level Was: COMPLETE: RFE(x2): Service Info/Notify Method On Level

[Subhendu Ghosh]

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.