> On Wed, 16 Oct 2002, Ethan Galstad wrote:
>
> > On 16 Oct 2002 at 10:28, Subhendu Ghosh wrote:
> >
[snip]
> >
> > >
> > > Adaptive monitoring:
> > > Also if adaptive monitoring get used - some way to write out the running
> > > config would be useful. Otherwise a restart would loose the any changes
> > > made. Of course the argument could be made that one must modify the
> > > configs as well.
> >
> > Yep, the format of the retention file (and status log, for that
> > matter) will be updated to contain current and normal settings for
> > anything that can be changed on-the-fly.
> >
>
> Well if you allow hosts and services to be added on-the-fly then we might
> obviate the need for config files for some situations!
>
> but small steps first
>
Actually, I don't plan on allowing people to add new object
definitions on-the-fly.
Rather, I'll allow some properties ofhost/service definitions to be modified during runtime. Mutable
properties that top my TODO list include:
SERVICES:
- service check command
- normal check interval
- retry check interval
- max check attempts
- event handler command
HOSTS:
- host check command
- max check attempts
- event handler command
Any check or event handler command that is referenced during a
runtime change would have to have been defined when Nagios started
up, or the change request will be ignored. Not the ultimate in
flexibility, but it probably deters some potential security problems.
Allowing these properties to be changed during runtime could allow
for some very nice tricks indeed. Lower priority items that may or
may not get implemented would include:
- check timeperiod
- notification timeperiod
- notification options
Anyway, that's more along the lines of what I was thinking...
Ethan Galstad,
Nagios Developer
---
Email: nagios@nagios.org
Website: http://www.nagios.org
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: nagios@nagios.org