Re: Netsaint statuses

Dear Sir,

I am writing to thank you for your letter and say,

On Tue, Nov 05, 2002 at 12:55:01PM +0100, Frank Schafer wrote:
> Hi there,
> 
> on my way learning NetSaint, I hit the following problem:
> I've looked at some of the scripts in the netsaint-plugins.
> Some of them are exiting with $STATUS_OK, $STATUS_WARNING etc. Some
> other do an ``echo OK'', ``echo WARNING'' etc. I've seen too, that some
> do simply ``exit 0'', ``exit 1'' and so on.

Yep. All of these work .. provided that, as you say, the shell
variables/Perl variables or whatever they are are defined to have the
values recommended for the various service statii.

Heres an example extract from check_log.sh

. $PROGPATH/utils.sh

 .. snip ..

# Make sure the correct number of command line
# arguments have been supplied

if [ $# -lt 1 ]; then
        print_usage
        exit 2
fi

 .. snip ..

while test -n "$1"; do
        case "$1" in
                --help)
                        print_help
                        exit $STATE_OK
                        ;;
                -h)
                        print_help
                        exit $STATE_OK
                        ;;

So here is a respectable standard plugin using _both_ numeric and
symbolic service states !

> The least of this should be the right way, due to the plugin development
> guidelines.
> Where the hick do the shell variables like $STATUS_OK and so on come
> from?

In general they are defined by the plugin developers and combined with
the plugin in various language dependent ways.

The check above 'sources' (the line '. $PROGPATH/utils.sh') a file
called utils.sh that has these definitions.

#! /bin/sh

STATE_DEPENDENT=-2
STATE_UNKNOWN=-1
STATE_OK=0
STATE_WARNING=1
STATE_CRITICAL=2

Perl plugins 'use' a module called utils.pm that exports a 'hash' named
%ERROR; a perl plugin can then exit $ERROR{'OK'} or exit
$ERROR{'CRITICAL'}.

Why use symbolic names ?

Most developers prefer them because they make program maintenance
easier.

For example suppose that someone made a mistake in the exit code for
STATE_UNKNOWN. If the plugins all used exit -1; each plugin would have
to edited to replace '-1' by the new value.

If symbolic codes were used, none of the plugins are touched. All that
needs changing is the single definition of STATE_UNKNOWN in 'utils.sh'
(and the same change for other languages but again in only one place and
that place is not the plugin thereby eliminating the risk of any
mistakes/typos when editing).


> Does netsaint itself change the environment

No.

> and (if so) how can
> these plugins run from the command line (as the documentation says)?

All the plugins run ok from the command line or they are not plugins at
all.

Here's an example with a Perl plugin called check_cit

tsitc> perl/check_citrix/check_cit -C metaframe -P Desktop
Ok. Citrix master browser "10.0.100.23" reported that the published
application "Desktop" is available.
tsitc> echo $?
0

tsitc> perl/check_citrix/check_cit -C metaframe -P DesktopBUGLE
Failed. "DesktopBUGLE" not found in list of published applications
"Desktop,NewDesktop,StableTop" from master browser "10.0.100.23".
tsitc> echo $?
2
tsitc> 

All netsaint does to run a service is do the equivalent of running the
command in back ticks (eg `date`): the back ticks return the exit code
(that Netsaint interprets as the health of the service) and whatever the
plugin output to STDOUT.

This output is saved by Netsaint (in status.log and in memory) and used
in notifications (if necessary) and for display by the CGIs.

In a nutshell Netsaint schedules checks and then arranges them to be run
in _exactly_ the same way (but through OS calls) as running them from
the command line.

> From the guidelines too I took, that I always should print something.
> Where does these printings go to?
>

See above.

About the plugin-guidelines: there are two independent audiences of
these guidelines that are roughly 'people that want to create a Netsaint
check of their service' and 'people that want to write Netsaint plugins
for including in the standard set of plugins'.

The requirements of the first group are a _subset_ of the requirements
of the second set (the second group of people may want things like

- make test to return a meaningful test of the plugin
- that configure.in is patched so that the plugin builds and work with
./configure

).

Plugin developers may also mandate style, standards and so on. The
plugin must do all the things that a plugin must do but there must be a
whole bunch of extra stuff to make sure that it builds and runs ok in
alien environments.

If you or me on the other hand simply want to check our LocalGizMO
appliance all we need do is something like

#!/usr/bin/perl -w

use strict ;
use utils qw(%ERRORS ...) ;

my $ok = 0  ;

# ... check the appliance setting $ok. appliance is either working or
not.

if ( $ok ) {
  print "Appliance OK\n" ;
  exit $ERRORS{'OK'} ;
} else {
  print "Appliance not working too well\n" ;
  exit $ERRORS{'CRITICAL'} ;
}



> Thanks for every explanation
> Frank
> 
>

Yours sincerely.

-- 
------------------------------------------------------------------------
Stanley Hopcroft
------------------------------------------------------------------------

'...No man is an island, entire of itself; every man is a piece of the
continent, a part of the main. If a clod be washed away by the sea,
Europe is the less, as well as if a promontory were, as well as if a
manor of thy friend's or of thine own were. Any man's death diminishes
me, because I am involved in mankind; and therefore never send to know
for whom the bell tolls; it tolls for thee...'

from Meditation 17, J Donne.


-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en