> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:nagios-users- > [EMAIL PROTECTED] On Behalf Of Josh Konkol > Sent: Tuesday, June 06, 2006 1:37 PM > To: nagios-users@lists.sourceforge.net > Subject: Re: [Nagios-users] Host check doesn't wait in-between checks. > > Kyle Tucker <kylet <at> panix.com> writes: > > > > > > > > > What is the point of setting a Host max_check_attempts if > Nagios isn't going to > > > wait in between checking? > > > > I too wish I had more time between host checks and you've prompted me > > to try something in my check_alive script. Would this snippet do the > > trick? > > > > TIMEGAP=10 # number of seconds before host checks > > > > if [ $HOSTSTATE$ = "DOWN" -a $HOSTSTATETYPE$ = "SOFT" ] > > then > > sleep $TIMEGAP > > fi > > > > exit 2 > > > > I would have used ... > > > > if [ $HOSTSTATE$ = "DOWN" -a $HOSTATTEMPT$ -lt > $MAXHOSTATTEMPT$ ] > > then > > sleep $TIMEGAP > > fi > > > > ... but oddly there seems to be no $MAXHOSTATTEMPT$ macro. > > > > > OK so the simple solution would be to change my check-host-command > to include a sleep 10 at the end. i.e.: > > $USER1$/check_ping -H $HOSTADDRESS$ -w 3000.0,80% -c 5000.0,100% > -p 3 && sleep 10 > > You think that would work?
Probably but be aware that if you have a significant outage you may be introducing possibly unacceptable delays in your monitoring data freshness. Using your example of 3 pings, 10 second sleep and 3 max host checks, if you have 10 hosts go down at the same time you have introduced 6.5 minutes of delay for that round of service checks ((3+10) * 3 * 10 = 390s). It may be possible to eliminate some/all of that through the use of the parents directive depending on your network infrastructure. From personal experience you want your monitoring data to be as up-to-date as possible when you're fixing an issue. -- Marc _______________________________________________ Nagios-users mailing list Nagios-users@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
