Antwort: nagios not running host check_command

Mathias Sundman mathias at nilings.se
Mon Nov 28 15:46:08 CET 2005


On Mon, 28 Nov 2005, srunschke at abit.de wrote:

> nagios-users-admin at lists.sourceforge.net schrieb am 28.11.2005 14:06:26:
>
>> I have about 20 servers, for which I have no specific services to 
>> monitor, but which I am interested in their host status, ie the 
>> check_command in the host entry in the hosts.cfg file is set to 
>> check-host-alive.
>>
>> However, it appears that the host check_command is never executed, and
>> availability for the host is always Undetermined - Insufficient Data 1d
>> 0h 0m
>> 0s 100.000%
>>
>> Also the status in Host Status detail is always pending, though there 
>> are no other checks configured for this host.
>>
>> If I explicitly add a check-host-alive for the host in a service 
>> configuration, then the host appears as up in the Host Status Details 
>> list, but obviously I would expect it to appears as UP due to the 
>> check_command
>>
>> Any ideas on whether this is the expected behaviour for the 
>> check_command directive?
>
> It is the expected behaviour.
> Nagios is a network monitoring tool, not a host-only monitoring tool.
> It actually expects that a host must have a kind of service running
> to be useful - which is more or less true in 99.99% of the cases ;)
> Therefor nagios works like this:
>
> 1. do the defined service-checks on all defined hosts
> 2. IF and only IF one of those checks fail, then issue a check_host_alive
> to see if it's a problem with the service or if the host is down
>
> It is safe to assume that a host is alive if its services are responding.
> Checking the host for being alive again is redundant unless one of its
> services fail.
>
> So you need to set up some kind of services for each host to have them
> appear as "UP". Though there _is_ a configuration option to enforce
> check_host_alive checks, but alas I cannot remember it. Your best friend
> is the documentation in this matter. (or just look through the configfile
> and check for this particular option)

You can use check_interval in the host definition to force regular host 
checks, however the documention says clearly that you should avoid this as 
much as possible.

I'm a little curious to why though. Just as the OP I have a lot of hosts 
that has to real services, so I only monitor it though a simple ping. 
Currently I have it setup redundant with a check_ping service and a 
check_host_alive host check, but I think it would be cleaner to only have 
regulary scheduled host checks instead.

My check_host_alive host command is running:

check_fping -H $HOSTADDRESS$ -w 5000,100% -c 5000,100% -n 1

while my check_ping service command is running

check_fping -H $HOSTADDRESS$ -w $ARG1$ -c $ARG2$ -n 5

so only one ping packet will be sent for each host check (if the host 
responds) so the host check should even be faster than my service 
checks are with my current config. Is it still true that I would get a 
performance penalty by removing my service checks for these hosts and 
enabling a regularly scheduled host check instead? If so, why?

Or is this statement about it beeing a performace penalty only true when 
you have other service checks scheduled that is normally executed much 
faster than the old default host check that would have waited for several 
pings before returning and thous causing a significant delay?

PS: I'm running Nagios 2.0b5

//Mathias


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null





More information about the Users mailing list