Subject: RE: compiling nsca-2.1 under Solaris8

[Fred Im]

ok... i'll describe how i set up each of the pieces here (yes, i use both) to
give some basis to how it looks to me...

at the company i work for, we were faced with a dilemma; purchase another year
of licensing for a monitoring product, or find something comparable and free...

so someone mentioned netsaint, and we picked up nagios.  nagios in itself is
quite a nice product; it has a lot of hooks and useful pieces, and then there
are other addons that provide other useful bits.

the nicest part of nagios vs. netsaint are the templates, depending on your
host set, you can make short work of a lot of configuring... but i'll relate
that to nsca in a bit...

currently, i'm monitoring 50+ hosts and running 500+ service monitors.  all of
this is a combination of nagios, nrpe, and nsca.

nagios handles the backend stuff, that's the notifications, time periods and a
majority of the service "gets" via mostly nrpe calls.  we already had a
monitoring infrastructure in place, so all of our nrpe traffic is behind the
monitored equipment (in a monitoring network, per se)  nrpe does not run under
a privileged port, and does not require root access.  nrpe does all of it's
work as a special user i created for monitoring purposes.  on all of the
systems, this user doesn't even have a password (it only runs the nrpe daemon).
using nrpe, i can get data directly from each of the servers, cpu/mem/disk
usage, and some custom scripts for running apps, directly from the main nagios
server.

we have pockets of servers that are not in our datacenter.  these pockets of
servers (at most 3 or 4 machines) have a "local" monitoring server (something
pretty small).  so on the local monitoring servers, i had to reinstall nagios,
copy most of my templates over, and then install nsca.  the nagios is
configured to not send any notifications, and to report all of its data (using
the submit_check_result which in turn calls send_nsca) back to the main nagios
engine.  the main nagios server then handles the alerting.  the nsca data has
to travel over the internet.

nagios runs pretty well, but here are some things that could use some
improvement:  the main nagios server and the pocket nagios server have to have
their configs matched, when the passive checks come in, if there isn't a
matching service listed in the main nagios server, then it throws it away. 
adding custom monitors (for nrpe) goes into the main nagios server config files
AND the nrpe.cfg file on the individual server.  this (nrpe.cfg) is primarily
where the local customizations for threshholds go.  it would be nicer if i
could centralize all of the configs in one place, but it does work...

so, in answer to your questions...  you can't always have the client contact
the server.  in this case, and pretty much for any monitoring system, you want
the monitoring server to fetch results.  granted, nagios does have some nice
hooks with the freshness checking and all...

well, to install the software, nsca + plugins or nrpe + plugins, you gotta log
into the machine and install the software... both don't require a privileged
port; i suppose if you wanted to cron the nsca and plugins... but then, why use
nagios if you're planning to cron anyways?  when you get down to it, there ar
egoing to be some differences between the clients (which stinks), i think nrpe
makes a smoother integration of parts than nsca.

in terms of scalability... i can't say that i've seen a big difference in usage
for passive vs. active checks.  nagios comparably uses cpu time vs. the other
monitoring package we used... maybe someone else has better numbers on this?

in terms of crypto for nrpe.  while you CAN run any command with nrpe and
return it as a check, you have to specifically list the allowed commands and
allowed hosts from which to connect from.  in terms of someone sniffing and
reading your monitored results... um... if you saw "DISK ok [34% used]" in a
packet, what would you do with it?  i suppose you could trick the master server
into accepting bad data... but what would that do? send an extra alert?  i
would advise this... take care in the commands you allow to run... 

fred

> Jackson Sie wrote:
> > Just do search and replace in the nsca source tree for 
> 'u_int32_t' and
> > replace with 'uint32_t'.  That should do the trick.  We had 
> run into a
> > similar problem as well when we were still thinking of using nsca...
> 
> Nope, errors still exist.
> 
> But you bring up a good question:  Why *not* NSCA?
> 
> One thing that's been hammered into me on 
> www.infrastructures.org:  Have the clients contact the 
> central server, not the other way around.
> 
> In the case of NSCA, I own Nagios and root on the monitoring 
> server.  It doesn't matter if someone merely grants me 
> non-root access on their host; I can (once I get NSCA to 
> compile :P ) just install NSCA and the plugins, and off I go.
> 
> In the case of NRPE, I'm guessing one needs root privs...?  I 
> can't say that I've taken a look at this tarball, so don't 
> know if it requires a privileged port.  (I realize that a 
> privileged port isn't required for NSCA.)  I'm also wondering 
> about things like:  scalability on the monitoring server, and 
> (lack of) crypto/authentication on the client.
> 
> Thoughts?
> 


__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390