New Question: NSClient Test

[Marc Powell]

On Mar 14, 2009, at 8:22 AM, Mark Weaver wrote:

> Ok... now my noobie is stickin out again. what and where is the NSCA  
> on
> the linux box? I haven't heard of that one.

There are two kinds of checks that nagios understands: active and  
passive.

An active check is one that nagios itself initiates. Nagios schedules  
a plugin to run, executes it and collects the results.

A passive check is one where nagios does _not_ schedule a plugin to  
run, nor does it execute it. Some external entity executes a plugin  
and sends the results to nagios through nagios' external command file  
(a pipe that allows nagios to receive information from external/third  
party programs). The external entity executing the plugin can be  
another nagios instance running on a different machine (distributed  
monitoring), nsclient(++) running on windows (I have no experience  
there), crond - local or remote running a custom script, etc.

NSCA (available on the Downloads page), is a set of external programs  
to properly format external passive check results into something  
nagios understands and pass them to nagios. It's comprised of a  
daemon, nsca, running on the nagios server and a client running on a  
remote system that sends the results to the nsca daemon. The package  
includes a client for unix-like machines named send_nsca. NSclient(++)  
also implements a send_nsca client. The client machine is the  
originator of the check and it's results. NSCA implements it's own  
protocol for communication between the client and the nsca deamon.

NRPE (available on the Downloads page) is a set of programs that allow  
nagios to run active checks on remote machines to check things that  
are not normally available over the network (think disk, cpu, memory  
utilization). It consists of a plugin that nagios actively executes  
(check_nrpe) and a daemon running on a client (nrpe). Nagios actively  
calls the check_nrpe plugin which asks the NRPE daemon to execute a  
specific check configured on the remote host and return it's results  
to nagios. NRPE implements it's own protocol for communication between  
the client and the nrpe daemon.

check_nt is a nagios plugin that is also scheduled as an active check  
and connects to a remote nsclient(++) daemon to execute a specific  
check and return the results to nagios. I believe that check_nt/ 
nsclient implement yet another protocol for that communication.

NSclient(++) can be configured for either role. It can be a target of  
an active check by nagios using either the NRPE or check_nt protocols,  
or it can submit passive checks to nagios using the NSCA protocol. I  
would say it is usually the target for one of the active check types  
most commonly, unless it is behind a restrictive firewall or the  
system to be monitored is on a dynamic IP. In the latter case, it's  
often easier to have the monitored system contact nagios with a  
passive check instead of the other way around.

check_by_ssh is another plugin to execute checks on remote unix-like  
machines. It's commonly configured as an active check and simply uses  
the ssh protocol to run a plugin installed on another machine. The  
results are then returned to nagios.

Hope I didn't confuse you further... As to why NSCA isn't distributed  
as part of nagios, most people don't need it. I'd say the majority of  
installations use active checks only.

--
Marc


------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
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