managing latency-induced host down alerts

[Marc Powell]

> -----Original Message-----
> From: nagios-users-bounces at lists.sourceforge.net [mailto:nagios-users-
> bounces at lists.sourceforge.net] On Behalf Of Michael W. Lucas
> Sent: Wednesday, September 12, 2007 9:46 AM
> To: nagios-users at lists.sourceforge.net
> Subject: [Nagios-users] managing latency-induced host down alerts
> 
> Hi,
> 
> I'm using Nagios 2.9 on FreeBSD, on a wide area network that has
> remote networks scattered across the USA and Mexico.
> 
> We have a problem where latency on some remote circuits rises due to
> congestion.  This means that various service checks time out, as they
> take more than 10 seconds to complete.  (Yes, this is a real problem,
> and we're addressing it.  I'm using smokeping to track latency at
> these sites now, analyzing traffic, etc.)


> I'd like to separate the latency problem from a site down problem.  I
> can think of a couple ways to do this:
> 
> 1) increase the 10-second maximum timeout for a service check to
> complete.  Can this be done in Nagios?

Yes, and is the route I would take since it's the simplest. All standard
plugins support a timeout parameter, usually -t. You can run ./plugin
--help to verify if it's supported. Just add an appropriate timeout for
the test you're trying to complete in the command{} definition. You'll
also need to increase the master service_check_timeout parameter in
nagios.cfg. That's a fallback timeout in case the plugin doesn't
terminate itself properly. I have my plugin timeouts generally set at 45
seconds and the master at 60.

--
Marc

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
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