shared ip on the same host

Paul L. Allen pla at softflare.com
Wed Jan 14 19:34:07 CET 2004


Chuck writes: 


> Is there a way of consolidating this? I dont think a multiple address
> listing under one host would work even if it were allowed simply 
> because there is no way to tell the individual tests which address to
> use for which test. 
> 
> or did i miss something important here?

I don't think you missed anything, but I could be wrong - there's a lot
of documentation and it's possible I missed something. 

The way I dealt with it was do define a new check command which used 

 -H $ARG1$ 

instead of 

 -H $HOSTNAME$ 

Then my service check can be something like check_dns2!123.231.123.231.
The downside is that a host alive check will ping whatever interface
you defined as being the host address, not necessarily the one with
a failing service, so you won't know if (say) the DNS server is down or
the interface it answers on is dead.  But at least you know something
is wrong.  Then you can show all your services on the same host even
if some of them have different IP addresses on that host. 

However, using alternative check commands like that seems to expose a
shortcoming in nagios templating (or my lack of understanding).  It
appears that the OOP templates do not have over-riding.  So imagine
you want to define a template service for checking CPU load with
the description "CPU Load" and a suitable check command.  It works
fine for your remote servers but you also want to check the CPU load of
the machine running nagios - the check command for the remote servers
goes through NRPE or check_by_ssh whereas for the local machine it's
just a straight check_load.  I've found only two ways of doing this,
each with disadvantages. 

 1) Define two service templates with different service descriptions
 such as "CPU Load" and "Local CPU Load" with the appropriate check
 commands in each.  It appears that Nagios refuses to let you re-use
 the same description in a template, even if the service name is
 different.  So you end up with cosmetic differences in the display
 even though what you're monitoring in each case is the same but by
 slightly different methods (one direct, the other through NRPE or
 check_by_ssh).  I can understand some people wanting this difference
 visible to remind them that one check is direct and the other isn't,
 but I don't. 

 2) Define a single service template but don't put the check command
 in it.  Instead you have to put the check command in each actual
 service definition so that one host can have a different check command.
 With over-riding, you could have the check command in the template
 and over-ride it for one or two hosts.  This means there are no
 cosmetic differences but there is a lot of duplication of check commands
 (a pain if one day you decide you need to alter the parameters you
 pass them because instead of altering a check command in a template
 definition you have to alter many, many instances. 

On the subject of over-riding, if it is ever added, I'd like to be able to
over-ride parameters without having to repeat the check command because
I have some lengthy check commands involving check_by_ssh.  I also
have firewalls which are lightly loaded and public servers which are
heavily loaded.  I'd really like to be able to cater for the common case
and over-ride the parameters sometimes without having to give the whole
check command and parameters. 

And if anyone wants to flame me for missing something obvious in the docs
that means I can already do this, go right ahead - as long as you point
me to the place in the docs where it tells me how to do it... 

-- 
Paul Allen
Softflare Support 




-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
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





More information about the Users mailing list