host_port objects - Enhancement Request

Jason Frisvold frisvolj at lafayette.edu
Fri Oct 29 17:21:18 CEST 2010


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/28/2010 04:14 PM, Andreas Ericsson wrote:
> Never heard of such a group. Considering I'm a core developer you'd have
> thought I would know, but I suppose not. Ah well. Anyways; if you want to
> pay for new features, go wild :)

Generic name I guess.  I couldn't find an actual name for whatever
department within Nagios Enterprises would do the work.  Maybe it's the
core developers?  I'm not completely familiar with how the company is
put together..

>> Disadvantages
>> * Parent/child relationships are difficult, if not impossible, to define
> 
> I disagree. The switch is still the parent of whatever hosts are sitting
> beyond it, from Nagios' point of view. If one port stops forwarding
> traffic but the switch is still up (and thus probably reachable from the
> admin interface), the actions a network admin would take are vastly
> different. I agree that it would be nice to be able to surpress
> notifications for the hosts connected through this particular port, but
> that would be easier to solve by making it possible to have services as
> parents (like a parent_service, perhaps).

Right.  I understand that the switch, as a whole, would be the parent of
a server, but we were looking for a way to have the port be the parent
so we can have finer control over alerting.

parent_service is actually a pretty good idea, I hadn't thought of that.

>> * Ports with associated addresses are more difficult to define
> 
> I don't quite follow you here. If you mean that the interface name is
> hard to remember (or type), then you can just rename the interface in
> the switch itself. Name it kungfupanda for all anyone cares. It's a
> piece of hardware, so it won't be offended no matter what you name it.
> 
> Other than that, finding it hard to remember is just another reason
> why you would want it sent to you in a notification so you can quickly
> find which interface it is when you're trying to fix the problem.

It's not really a naming issue.  If we look at a router instead of a
switch, then ports on the router can potentially have addresses
associated with them.  If we're using services to define ports, then how
do I tell the service to use a specific address for the port instead of
the host address.  The situation gets a bit more confused when you have
a router doing both layer 2 and 3 and ports may or may not have addresses.

>> * Parent/child relationships work as expected
> 
> They work no differently than they did before. Or am I missing
> something?

Ports can now be parents of individual hosts rather than the entire switch.

>> Disadvantages
>> * Every port on every switch has to be defined
> 
> False. Only the ones you need to monitor somewhere have to be
> defined.

Sure.  The assumption here is that I want to monitor most or all of the
ports.

>> * Port host_name entries are often fake
> 
> Why? If there is a port you don't want to monitor, just remove the
> service definition, or set it to "register 0"

Because the host_name has to be unique.  So if I have a switch with 5
ports, ethernet0 through ethernet4, I need to have a host_name for the
switch itself, switch.lafayette.edu, and then host_names for each port,
switch-ethernet0.lafayette.edu, etc.  However, these are switch ports
and are layer 2 only, so there are no addresses associated with them.  I
can make the host_names of the ports CNAMEs to the switch host_name, but
I don't see the point.

>> * Port address entries are often duplicated
> 
> This I don't understand. Can you elaborate?

This falls in with the previous remark about host_names.  Each host
entry requires an address.  The only address that makes sense here is
the address of the switch itself.  So, we have that address multiple
times in the configuration, once for the switch, and once for each port.

> Sorry, but this is just plain dumb. You're trading one set of
> advantages and disadvantages for something else. How about something
> like this instead?
> 
> define host {
>    use             some-template
>    host_name       some-host
> 
>    service_params {
>       traffic_ports       G1(30%,70%)!CHARLIE(60%,70%)!G3,G4
>    }
> }
> 
> define service {
>    use                  some-service-template
>    lalala               yadayada
>    service_description  Traffic port %?
>    foreach_param        traffic_ports?60%,80%
>    check_command        check_traffic!%?!%1!%2
> }
> 
> define checkcommand { 
>    command_name            check_traffic
>    command_line            $USER1$/check_traffic --iface=$ARG1$ --warn=$ARG2$ --crit=$ARG3$
> }
> 
> This would then result in the host getting 4 services, named
> G1, CHARLIE, G3 and G4, where G3 and G4 have 60% and 80% as
> their $ARG2$ and $ARG3$, respectively, and G1 and CHARLIE
> have 30%/70% and 60%/70% as their $ARG2$/$ARG3$, respectively.
> 
> One service-definition and everything is controlled from the hosts.
> For extra bonuses, make the service_params variables accept a +,
> preferrably as a keyword suffix rather than as a value prefix, to
> add more stuff to the list. If that was the case, the above
> service_params block could be written as such:
> 
>    service_params {
>       traffic_ports        G1(30%,70%)
>       traffic_ports+       CHARLIE(60%,70%)
>       traffic_ports+       G3,G4
>    }
> 
> to produce the same result. This should prevent extremely long
> lines from turning up in the config files. Note the distinction
> between putting the +-sign as a keyword suffix rather than a value
> prefix though. Since the values are more or less free-form, adding
> prefixes and suffixes to them restricts use and makes it a lot
> harder to parse with various tools.

And this is exactly why I submitted this to the list before I submitted
it to Nagios Enterprises.  I'm looking for feedback.

I like how this condenses in the configuration and definitely looks like
it would work well.  However, how would you go about making a port a
parent of a host?  That's really the crux of what I'm looking for.

> But since you're paying, you get to choose, I suppose. If the
> professional services support group turn out to be too expensive
> I might be willing to implement something like this. Let me know
> in that case and we'll see what can be done.

Do you work for Nagios Enterprises, or are you an OSS developer?

- -- 
- ---------------------------
Jason Frisvold
Network Engineer
frisvolj at lafayette.edu
- ---------------------------
"What I cannot create, I do not understand"
   - Richard Feynman
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkzK5m4ACgkQO80o6DJ8Uvn98wCgjHlyOwrJvuEHiIzVgPQzjQJ1
SqUAn22KAzAHzj68u8Y1ClJnAdAF7x3V
=+HYd
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
_______________________________________________
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