host_port objects - Enhancement Request
Andreas Ericsson
ae at op5.se
Thu Oct 28 22:14:12 CEST 2010
On 10/28/2010 05:16 PM, Jason Frisvold wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Greetings,
>
Hi there.
> We are planning on submitting an enhancement request to Nagios with the
> intention of having their professional services group code this for us.
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 :)
> We are interested in having our changes made available to the community
> as well, so we wanted to get feedback from the community before we
> submit the proposal. Any and all feedback is welcome.
>
Good idea. My reply is below. I've thought of some of those problems myself.
>
> Nagios Enhancement Proposal
>
> Overview
>
> Currently, there are two primary ways to add individual physical ports
> for a port-based device. Each method has both advantages and
> disadvantages, but neither fully satisfies the needs of Lafayette and,
> likely, other institutions.
>
> Service-based Ports
>
> The first method is to treat ports as a service of a host and add them
> as service entries. The following configuration snippet demonstrates this :
>
> define host {
> use cisco-switch-standard
> host_name switch.lafayette.edu
> address 192.168.0.100
> hostgroups cisco-switch-standard
> parents router.lafayette.edu
> }
>
> define service {
> use service-standard
> hosts switch.lafayette.edu
> servicegroups cisco-switch-standard
> service_description Switch Port Gi1/0/1
> check_command check_snmp_traffic!-N Gi1/0/1!-C $USER2$
> }
>
> In short, this configuration defines a host and then a service for that
> host which is, essentially, an snmp check that monitors the traffic on a
> specific port.
>
> Advantages
> * Cleanly links a port to a switch
> * Somewhat easy to add/remove specific hosts that need that port monitored
>
Agreed.
> 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).
> * Making service changes for a single port requires creating a unique
> new service
> * Service descriptions can get a bit long when they need to have a
> meaningful description associated with them
Agreed on those two (sort of).
> * 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.
>
> Host-based Ports
>
> Another method to accomplish this is to create a “fake” host entry for
> each port and then assign services to those ports for monitoring. The
> following configuration snippet demonstrates this :
>
> define host {
> use cisco-switch-standard
> host_name switch.lafayette.edu
> address 192.168.0.100
> hostgroups cisco-switch-standard
> parents router.lafayette.edu
> }
>
> define host {
> use cisco-switch-standard
> host_name switch-g1-0-1.lafayette.edu
> address 192.168.0.100
> hostgroups cisco-switch-standard
> _PORT Gi1/0/1
> parents switch.lafayette.edu
> }
>
> define service {
> use service-standard
> hosts switch.lafayette.edu
> servicegroups cisco-switch-standard
> service_description Port Traffic
> check_command check_snmp_traffic!-N $_HOSTPORT$!-C $USER2$
> }
>
> This configuration defines two hosts, a switch and a port on that
> switch, and then a service linked to the port.
>
> Advantages
> * Parent/child relationships work as expected
They work no differently than they did before. Or am I missing
something?
> * A single service entry can be used for many port entries
> * Very easy to deal with address-assigned ports such as router interfaces
>
True.
> Disadvantages
> * Every port on every switch has to be defined
False. Only the ones you need to monitor somewhere have to be
defined.
> * 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"
> * Port address entries are often duplicated
>
This I don't understand. Can you elaborate?
>
> Proposed Solution
>
> host-port object
>
> define host {
> use cisco-switch-standard
> host_name switch.lafayette.edu
> address 192.168.0.100
> hostgroups cisco-switch-standard
> parents router.lafayette.edu
> }
>
> define host_port {
> use cisco-switch-standard
> host switch.lafayette.edu
> port_name Gi1/0/1
> }
>
> define service {
> use service-standard
> host switch.lafayette.edu
> port_based true
> servicegroups cisco-switch-standard
> service_description Port Traffic
> check_command check_snmp_traffic!-N $PORTNAME$!-C $USER2$
> }
>
> In this proposed configuration, a host is defined, as normal. A new
> object, the host_port object, is defined with port-based information.
> The host_port object imports information such as address and host_name
> from the host but can override this information if needed. For
> instance, a router interface may have an ip address and hostname.
> Finally, a new tag, port_name, identifies the port name to use. When
> displaying the host_port in the GUI, or identifying it in email/SMS, the
> port_name should be appended to the host_name. A similar syntax could
> be used for parent/child relationships as well.
>
> The service definition uses a new tag, port_based, to identify that this
> service is for the ports of a host, not for the host itself. This
> service should be applied to all ports. port_name can be used in a
> manner similar to host or hostgroups to restrict the service to specific
> ports.
>
> Advantages
> * Clearly links ports to hosts
> * Parent/child relationships can be clearly defined
> * A single service entry can be used for many port entries
> * Very easy to deal with address-assigned ports such as router interfaces
>
> Disadvantages
> * Every port has to be defined
> * Concatenated host/port names can get a bit long
>
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.
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.
--
Andreas Ericsson andreas.ericsson at op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
------------------------------------------------------------------------------
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