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

[Ethan Galstad]

On 7 Jun 2003 at 10:55, Subhendu Ghosh wrote:

> 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.
> 

I added a bunch of new macros in the 2.0 code.  I might be off, but I 
believe I already added a LASTSERVICESTATE (and LASTHOSTSTATE) macro. 
 I'll have to check though...



Ethan Galstad,
Nagios Developer
---
Email: nagios at nagios.org
Website: http://www.nagios.org



-------------------------------------------------------
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.