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

[Brandon Knitter]

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