parameters for service checks from outside nagios

Carroll, Jim P [Contractor] jcarro10 at sprintspectrum.com
Fri Jan 3 23:54:50 CET 2003


It doesn't sound like you're familiar with rsync.  It's quite thrifty with bandwidth.

>From the man page:

[quote]
rsync is a program that behaves in much the same way that rcp does, but has many more options and uses the rsync remote-update protocol to greatly speed up file transfers when the destination file already exists.

The rsync remote-update protocol allows rsync to transfer just the differences between two sets of files across the network link, using an efficient checksum-search algorithm described in the technical report that accompanies this package.
[end quote]

So, let's say you have an 800KB datfile, and every day the vendor adds another 5KB to the end of the file.  Only that difference will get transferred, not the entire file.  Even if the vendor added 50KB per day, you're still under the proposed 100KB that you speculate Nagios will cost you (even taking the rsync remote-update protocol overhead into consideration).

Food for thought.

jc

> -----Original Message-----
> From: Lennard Bakker [mailto:bakkerl at lamp.xs4all.nl]
> Sent: Friday, January 03, 2003 4:43 PM
> To: Carroll, Jim P [Contractor]
> Cc: nagios-users at lists.sourceforge.net
> Subject: RE: [Nagios-users] parameters for service checks from outside
> nagios
> 
> 
> On Fri, 2003-01-03 at 22:47, Carroll, Jim P [Contractor] wrote:
> > I'm going to go on a bit of a tangent here.  Maybe what you're
> > interested in doing is to have the datfiles consistent and 
> up-to-date,
> > and not test whether they are or not.  Sure, the test would be
> > valuable, but it might be redundant.  Allow me to illustrate....
> > 
> > Set up an rsync server internally.  (It doesn't have to be anywhere;
> > in fact, if you can keep it on a separate server, all the better.) 
> > Always put the latest/greatest datfile on your rsync server.  Run a
> > cronjob as frequently as you'd like (once a day, once an hour,
> > whatever) on your rsync server to grab the latest datfile from the
> > Internet.  Also set up cronjobs on each of your hosts (where the
> > datfile needs to be kept up-to-date) to use the rsync 
> protocol to grab
> > this very same datfile from your rsync server and install locally.
> 
> Above will do if you have enough bandwidth. But (there is 
> always a but),
> some hosts i want to check have a bandwidth limit of 33k6. 
> For these hosts i don't want a daily update (or more). For these hosts
> there is a weekly cronjob now.
> But virus-dat files can be get updates more than once a week (normal
> once a week). 
> 
> A nagios check (lets say 4 times a day), would only cost 100kb (?) of
> data communication. But with this check i could see of the datfile on
> one of these host is uptodate. If the check would go on ERROR 
> (2 or more
> version behind), a manual update of these hosts is wanted (the
> organization policy is uptodate, but 1 version behind wouldn't kill me
> :)
> 
> The bandwidth problem is why i want the check.
> 
> 
> > jc
> > 
> > 
> > > -----Original Message-----
> > > From: Lennard Bakker [mailto:bakkerl at lamp.xs4all.nl]
> > > Sent: Thursday, January 02, 2003 6:18 PM
> > > To: Carroll, Jim P [Contractor]; 
> nagios-users at lists.sourceforge.net
> > > Subject: RE: [Nagios-users] parameters for service checks from
> > outside
> > > nagios
> > > 
> > > 
> > > nagios-users at lists.sourceforge.netOn Thu, 2003-01-02 at 
> > > 17:45, Carroll,
> > > Jim P [Contractor] wrote:
> > > > I'm not entirely sure how you're retrieving the datfiles, 
> > > but it might make
> > > > sense to run a plugin locally on the remote systems in 
> > > question.  This
> > > > plugin would scrub the datfile (eg, with grep); the result 
> > > of this plugin
> > > > would be returned to Nagios.
> > > The version is retreived by grepping, cutting, some awk and some
> > other
> > > tools on the output of the virusscanner version info. This is not
> > the
> > > problem.
> > > 
> > > The problem is how to let the plugin know what the current
> > (uptodate)
> > > version is. I want to result the plugin OK if uptodate, 
> WARNING on 1
> > > versions behind, ERROR on all other results.
> > > 
> > > The plugin is capable of getting the current used version, 
> > > now i have to
> > > let it compare to the latest version. This information can be 
> > > fetched of
> > > the internet, but if all hosts gets the information on every 
> > > check, this
> > > would consumps a lot of bandwidth.
> > > The information of the latest version is also known on the 
> > > nagios host.
> > > So if the information (versionnumber) can be given to the remote
> > host,
> > > the plugin can also get his result (without fetching extra
> > information
> > > of the internet).
> > > 
> > > > Of course, I'm making some wild assumptions about your 
> > > environment, such as
> > > > the system that hosts your datfiles is a *nix host.  If 
> > > it's Windows, I'm
> > > > not entirely certain how you'd do it.  Still, you could 
> > > install OpenSSH and
> > > > Perl on your Windows servers to facilitate this sleight of hand.
> > > It is all Linux based. All windows checks are fase 2 for me.. ;-)
> > > 
> > > > In case I haven't been clear, you would be best off to 
> > > write your own plugin
> > > > to do this.
> > > The current check is a own written shell-script plugin. But 
> > > this plugin
> > > fetches the info from the internet. 
> > > 
> > > I did try some thing..
> > > method 1: check_nrpe!check_datfile
> > > This gets the latest information from the internet.
> > > 
> > > method 2: check_by_ssh!"/bin/nagios/libexec/check_datfile2 4240"
> > > With this method, the latest version is given to the remote host,
> > and
> > > not from the internet (here 4240). But this is now static in the
> > > configuration file. I can't get this information variable 
> > > (readed from a
> > > file or something, before it is passed to a remote host).
> > > 
> > > 
> > > The only solution i can see now, is to call a local plugin on the
> > > nagios-host. This shell scripts than uses nagios plugins 
> > > (check_by_ssh,
> > > or check_nrpe) to get some result from a remote host, and 
> > > calculate the
> > > result.
> > > This solution is not wanted due to resoures on the nagios-server.
> > > 
> > > With greets,
> > > 
> > > Lennard Bakker
> > > 
> > > > 
> > > > jc
> > > > 
> > > > > -----Original Message-----
> > > > > From: Lennard Bakker [mailto:bakkerl at lamp.xs4all.nl]
> > > > > Sent: Tuesday, December 31, 2002 4:26 PM
> > > > > To: nagios-users at lists.sourceforge.net
> > > > > Subject: [Nagios-users] parameters for service checks from
> > outside
> > > > > nagios
> > > > > 
> > > > > 
> > > > > 
> > > > > Is it possible to import variable date to use with a 
> > > service check?
> > > > > 
> > > > > My problem:
> > > > > I want to let nagios to check anti virus datfiles on remote 
> > > > > systems. Now
> > > > > i do this dat each remote system fetch the latest version 
> > > info (800k)
> > > > > and verifies the version info, to the installed version 
> > > (no update is
> > > > > done). The plugin reports OK if datfile is uptodate, 
> > > warning when 1
> > > > > version behind and ERROR if more than 1 version behind 
> > > (or installed
> > > > > version is newer then the official downloadable).
> > > > > 
> > > > > The problem is that every client fetches the 800k just 
> > > for verify the
> > > > > version number (4 bytes number).
> > > > > 
> > > > > I have the lastest version info on the nagios host system 
> > > (in a file,
> > > > > just 4 bytes in size). Is it possible to add this info 
> > > from a file to
> > > > > the service check, so that the version number is given to te 
> > > > > remote host
> > > > > (by nrpe or chack_by_ssh). The remote host doesn't have 
> > > to access a
> > > > > remote host (internet) for the current information.
> > > > > 
> > > > > Lennard
> > > > > 
> > > 
> > 
> 


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf




More information about the Users mailing list