Distributed Nagios and scheduling service check from the central server

[Marc Powell]

Please try to avoid top-posting.

sucks.
posting
top
why
is
This

> -----Original Message-----
> From: nagios-users-admin at lists.sourceforge.net [mailto:nagios-users-
> admin at lists.sourceforge.net] On Behalf Of Dustin Kamper
> Sent: Thursday, July 14, 2005 3:40 PM
> To: nagios-users at lists.sourceforge.net
> Subject: RE: [Nagios-users] Distributed Nagios and scheduling service
> check from the central server
> 

> All of the checks on the distributed servers can be executed by the
> central server with no issues.  So I just used a 'concatonated'
version

> From what I can figure out, freshness checks base the 'freshness' of
the
> the results on the normal_check_interval setting.  Since
> normal_check_interval controls the timming of the active checks, you
> must turn active checks off so you don't have the central server
> checking what the distributed servers are already checking.  When
active
> service checks are turned off, the 'Re-schedule the next check of this
> service' link is not available from the web page.

The documentation is unambiguous, no need to figure anything out --

http://nagios.sourceforge.net/docs/1_0/xodtemplate.html#service

freshness_threshold: 	This directive is used to specify the freshness
threshold (in seconds) for this service. If you set this directive to a
value of 0, Nagios will determine a freshness threshold to use
automatically.

And

http://nagios.sourceforge.net/docs/1_0/freshness.html

"Assuming you're using the template-based object configuration file(s),
you need to configure service definitions as follows.

    * The check_freshness option in the service definition should be set
to 1. This enables "freshness" checking for the service.
    * The freshness_threshold option in the service definition should be
set to a value (in seconds) which reflects how "fresh" the results for
the service should be.
    * The check_command option in the service definition should reflect
valid command that should be used to actively check the service when it
is detected as being "stale". 

How The Freshness Threshold Works

Nagios periodically checks the "freshness" of the results for all
services that have freshness checking enabled. The freshness_threshold
option in each service definition is used to determine how "fresh" the
results for each service should be. For example, if you set the
freshness_threshold option to 60 for one of your services, Nagios will
consider that service to be "stale" if its results are older than 60
seconds (1 minute). If you do not specify a value for the
freshness_threshold option (or you set it to zero), Nagios will
automatically calculate a "freshness" threshold to use by looking at
either the normal_check_interval or retry_check_interval options
(depending on what type of state the service is currently in)."


> 
> I would like 1 source of Nagios for monitoring all of my servers but
> would like to spread the load of all the service checks to many
> distributed servers.  It would be a pain to have to go to one of the
> distributed servers just to run one re-scheduled service check on
> demand.
> 
> Now I'm not sure that a distributed solution is going to work for my
> monitoring needs.  Any pointers would be appreciated.

Active_checks_enabled 1
Passive_checks_enabled 1
check_period none
check_freshness 1
freshness_threshold 300 ; bad if 5 minutes old
check_command some_valid_check_command

Since you can execute all of your checks from the central server with no
problems, this should be a workable solution for you (it's been for us
for 4 years with 4 collectors and 2900+ passive service checks but to
each his own). If you _really, really_ wanted to execute the checks from
the remote host, write a script to ssh to the appropriate nagios machine
and drop a SCHEDULE_SVC_CHECK external command into the pipe.
check_by_ssh might be a good wrapper/start. Make that script the
check_command for the services on your central machine. That way,
freshness checks will be executed from the remote machine as well as
forced checks.

--
Marc


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&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