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: [email protected]
Website: http://www.nagios.org
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]