Multiple interfaces

[PGuth at corp.terralycos.com]

You *could* do this by defining each interface as a service under a single 
host.  For the check_command for each service you would have something 
like check_ping_by_ip!<interface IP>.  That would give you the cleaner 
host presentation.  But you still define one thing for each interface. And 
you'd have to define check_ping_by_ip, of course.  If you actually need to 
monitor multiple services for *each* interface it's going to be pretty big 
and unwieldy.

I don't understand what you mean by "modifying the plugins"....you want to 
be able to give check_http (for instance) a list of IP addresses to check? 
 Like you want to have a single host with a service called SERVICE and the 
check_command for that service looks something like "check_service IP1 IP2 
IP3 IP4"?  How does this make things easier to understand?  It's still 
going to just show up in the Nagios GUI as a single service that's either 
up or down, no matter which interface doesn't work, right?  So you've lost 
some diagnostic ability (someone needs to go look to see which interface 
is down).  And you still need to put the 4 IP addresses into the config 
file by hand, although it may make the config itself smaller.

It seems to me like you can either have simple and clean configurations 
with a cluttered presentation, or a simple and clean presentation with a 
cluttered configuration.  I'm running into a similar problem with my 
Nagios setup at the moment....the "OO"-ness of the config system is neat, 
but doesn't have quite as many degrees of freedom as I'd like.  I've 
basically given up on the "status summary" type pages being useful and 
figure the "tactical overview" will be the main screen used, from there 
you can drill directly down to the problem areas.





Phil Dibowitz <phil at usc.edu>
Sent by: nagios-users-admin at lists.sourceforge.net
07/30/2004 03:49 PM
 
        To:     nagios-users at lists.sourceforge.net
        cc: 
        Subject:        Re: [Nagios-users] Multiple interfaces


On Fri, Jul 30, 2004 at 03:32:18PM -0700, PGuth at corp.terralycos.com wrote:
> I guess it depends on what you're trying to do.  If you just want to 
make 
> sure you're hitting the interface that's closest to the nagios server, 
> then why not simply use *that* interface as the one defined in the host 
> object?  And ignore the rest?
> 
> If you actually need to monitor each interface (or services on each 
> interface) separately I don't see how to avoid the work of defining 
> multiple "things" even if you could find a way to do it without multiple 

> host definitions.  You can make the multiple definitions easier with 
> hostgroups/templating etc so that you only define a service once, assign 
a 
> hostgroup to it, and put all your hosts (and their interfaces) in that 
> hostgroup.

OK, let me be a bit more clear...

I want all interfaces monitored with each server. However, having to 
define 10
or 15 services upwards of 5 times for each host gets very unmanagable. It
makes the services.cfg file harder to read, and makes it more likely for
people to make mistakes in it.

Furthermore, it makes the webpage overviews less easy to look at at a 
glance.
Instead of one:

Host Service
     Service
     Service

to look at, the NOC now has to look at 5 or 8 or 10. The whole point of 
moving
to nagios is to make things less confusing for the NOC so that us admins 
get
less 3am calls ;)

Sorry, I should have make that more clear.

Now having said that, if I have to have 5 host definitions and make a host
group out of it, then so be it, I will -- but that just seems unclean to 
me.
I'll probably make someone here modify the plugins... though we're
understaffed here, so I'd rather not.


-- 
Phil Dibowitz
Systems Architect and Administrator
Enterprise Infrastructure / ISD / USC
UCC 174 - 213-821-5427


-------------- next part --------------
A non-text attachment was scrubbed...
Name: attdsk76.dat
Type: application/octet-stream
Size: 196 bytes
Desc: not available
URL: <https://www.monitoring-lists.org/archive/users/attachments/20040730/ff5f0aa3/attachment.obj>