On Wed, 24 May 2006, Ton Voon wrote:
>
> On 24 May 2006, at 10:59, Joerg Linge wrote:
>
>> Am Mittwoch 24 Mai 2006 11:37 schrieb Bruce Campbell:
>>>> We considered using a "cache" value for a host status - I think the idea
>>>> has merit and would reduce a large number of host checks, especially if
>>> See the "Workaround for 'Host DOWN' false-positives" thread for another
>>> way of doing it (slurp in the entire status.dat file if you've got a small
> This doesn't seem to be the same thing that this thread is about (reducing
> the amount of invocations of the host check because of non-OK statuses from
> active or passive checks).
It is very similar. Either you can invoke a 'magic' host check script
which checks the status of a particular service (either via status.dat or
seperate cache file), or you can have the host configured only for passive
checks and check_freshness, and submit the results via a service check.
Or, your host check command can do caching itself, which I suspect that
you were implying previously.
> While the solutions above do the job of updating the host status, you lose
> the "specialness" about host checks (invoked on-demand, reachability logic,
> etc).
There is nothing special about host checks that cannot be done with
properly set up service dependencies. However, the host checks are a much
easier way of setting up these dependencies.
> Going back to the original problem, would a retry_check_interval for host
> checks help with this particular case?
I don't believe so. Nagios will still execute the host_check command each
time a service on that host has a non-OK state. Since you can have a dead
host which still responds to ping, this is a lot of executions of the
host_check command when you have a lot of services on said host.
--
Bruce Campbell
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]