5 Easy Steps to Monitor Multi-Homed Hosts Using Opsview
Over the last couple of years we have seen an increase in port-density on server-hardware and currently the quad-nic (4 port network interface card) seems to be the standard. These cards allow for some great features like bonding (on *nix) or...
Opsview Development Team
Over the last couple of years we have seen an increase in port-density on server-hardware and currently the quad-nic (4 port network interface card) seems to be the standard. These cards allow for some great features like bonding (on *nix) or nic-teaming (on Windows) where multiple interfaces are bundled together or setup as fail-overs. It also allows you to nicely split your networks into multiple segments like management and production with each network connected over dedicated NICs as shown below...
However, this does pose the question which network should we use to monitor our hosts?
As always we need to consider the users point of view so we need to monitor the services used by our customers using the production network (web-interfaces, SQL etc).
But we also need to monitor our management services (like ssh, NRPE etc).
Therefore, our objective is to come up with network monitoring model to determine which service-checks will run over our production network and which will run over the management network.
Ensure you have the following:
1 x Opsview Master (or Slave) connected to both (or more) networks.
Create a monitoring model in which you divide your host into smaller chunks.
These chunks (or building blocks) represent the various parts of the system (e.g. hardware, network, operating system, applications and application interfaces).
Each chunk can then be assigned to either the management network or the production network.
Below is an example on how you can use these chunks to assign them to a network segment.
In this model we have defined that hardware, network, OS and applications (processes) are monitored through the management network (in general any check we use check_nrpe for).
Any check we run to confirm a service is reachable and usable (WWW, SQL etc) will be run over the production network (so we can confirm our customers can reach our services).
Update the host to reflect the various addresses it has.
Using the Opsview WebUI go to the Configuration > Hosts and select Action > Create new host.
In the Other Hostnames/IP’s field we can add our other IP’s of FQDN’s (as shown also adding the primary IP is good practice) in a comma-separated list for each IP you wish to assign to this host.
Save the host (later on we will assign host-templates and service checks).
Confirm from the commandline that you can reach your host using the addresses listed in the “Other Hostnames/IPs” by running one check for a management service and one for a production service.
Set up the service checks.
Now to use the defined “Other Hostnames/IPs” we need to change some of our service-checks.
The easiest way is to clone a check you already use and give it a new name (e.g. SSH to SSH Management).
As you see from the arguments line, the check will run against the macro know as $HOSTADDRESS$ which is the equivalent of the “Primary Hostname/IP”.
To use the “Other Hostnames/IPs” we have to change this to the macro that represents the IP or Hostname we want.
Opsview will automatically place all entries for the “Other Hostnames/IPs” in the macro $ADDRESS1$, $ADDRESS2$ and so on.
In this case we want to use our Primary-IP which we also registered as the first “Other address” so it is stored in $ADDRESS1$. This allows us to change our check to have the following arguments:
Using the described method you can now create service-checks and based on your model assign them to the correct $ADDRESS$ value.
Create new host-templates for the checks we created in Step 4 and assign them to your multi-homed host.
The “Other Hostnames/IPs” is a very powerful feature in Opsview and there are many things you can do with this functionality (for instance creating inter-host dependencies).
But in case your Opsview slave is not allowed to access the production network due to firewall policies or security restrictions, not all is lost. If you have an Opsview slave in the production network (and one in the management network) you can apply split-monitoring which will be discussed in a later blog-post.
About the Author
Alan Wijntje is responsible for maintaining and improving all forms of monitoring at Ziggo, one of the leading Managed Service Providers in the Netherlands. An Opsview expert and open source enthusiast, Alan enjoys finding, designing and implementing new and innovative ways of monitoring complex systems and applications.