(For more resources related to this topic, see here.)

There are two main approaches to working with network structure in Nagios Core:

• Host parent definitions allow an administrator to define a hierarchy of connectivity to monitored hosts from the “point of view” of the Nagios Core server. An example might be a server with the monitored address in another subnet linked to the Nagios Core server by a router. If the router enters a DOWN state, it triggers Nagios Core’s host reachability logic to automatically determine which hosts become inaccessible, and flags these as UNREACHABLE rather than DOWN, allowing refined notification behavior.

• Host and service dependencies allow the formalization of relationships between hosts or services, usually for the purposes of suppressing unnecessary notifications. An example might be a service that tests a login to a mail service, that itself requires a database service to work properly. If Nagios Core finds that the database service and the login service are both down, a service dependency allows the suppressing of the notification about the login service; the administrator would therefore only be notified about the database service being down, which is more likely to be the actual problem.

There is some overlap of functionality here, but the general pattern is that host parent definitions describe the structure of your network from the vantage point of your monitoring server, and host and service dependencies describe the way it functions, independent of the monitoring server. We will define both parent definitions and dependencies in this article, with the primary goal of filtering and improving the notifications that Nagios Core sends in response to failed checks, which can assist greatly in diagnosing problems.

We’ll also look at another, more subtle benefit of establishing host parent definitions in making the network map of the Nagios Core web interface useful, and once a basic hierarchy is set up, we’ll show how to customize the map’s appearance (including defining icons for hosts), to make it generally useful as a network weather map.

Creating a network host hierarchy

In this recipe, we’ll learn how to establish a parent-child relationship for two hosts in a very simple network, in order to take advantage of Nagios Core’s reachability logic. Changing this configuration is very simple; it involves adding only one directive, and optionally changing some notification options.

Getting ready

You will need to be running a Nagios Core 3.0 or newer server, and have at least two hosts, one of which is only reachable via the other. The host that allows communications with the other is the parent host. You should be reasonably confident that a loss of connectivity to the parent host necessarily implies that the child host becomes unreachable from the monitoring server.

Access to the web interface of Nagios Core would also be useful, as making this change will change the appearance of the network map, discussed in the Using the network map recipe in this article.

Our example will use a Nagios Core monitoring server, olympus.naginet, monitoring three hosts:

• calpe.naginet, a router

• janus.naginet, another router

• corsica.naginet, a web server

The hosts are connected as shown in the following diagram:

Note that the Nagios Core server olympus.naginet is only able to communicate with the corsica.naginet web server if the router calpe.naginet is working correctly. If calpe. naginet were to enter a DOWN state, we would see corsica.naginet enter a DOWN state too:

This is a little misleading, as we don’t actually know whether corsica.naginet is down. It might be, but with the router in between the hosts not working correctly, Nagios Core has no way of knowing. A more informative and accurate status for the host would be UNREACHABLE; this is what the configuration we’re about to add will arrange.

How to do it…

We can configure a parent-child relationship for our two hosts as follows

1. Change to the objects configuration directory for Nagios Core. The default path is /usr/local/nagios/etc/objects. If you’ve put the definition for your host in a different file, then move to its directory instead.

   # cd /usr/local/nagios/etc/objects

2. Edit the file containing the definition for the child host. In our example, the child host is corsica.naginet, the web server. The host definition might look something similar to the following code snippet:

   define host {
   use linux-server
   host_name corsica.naginet
   alias corsica
   address 10.128.0.71
   }

3. Add a new parents directive to the host’s definition, and give it the same value as the host_name directive of the host on which it is dependent for connectivity. In our example, that host is calpe.naginet.

   define host {
   use linux-server
   host_name corsica.naginet
   alias corsica
   address 10.128.0.71
   parents calpe.naginet
   }

4. Validate the configuration and restart the Nagios Core server:

   # /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
   # /etc/init.d/nagios restart

With this done, if the parent host enters a DOWN state and the child host can’t be contacted, then the child host will enter an UNREACHABLE state rather than also being flagged as DOWN:

The child host’s contacts will also receive UNREACHABLE notification s instead of DOWN notifications for the child host, provided the u flag is included in notification_options for the host, and host_notification_options for the contacts.

How it works…

This is a simple application of Nagios Core’s reachability logic. When the check to calpe. naginet fails for the first time, Nagios Core notes that it is a parent host for one child host, corsica.naginet. If during checks for the child host it finds it cannot communicate with it, it flags an UNREACHABLE state instead of the DOWN state, firing a different notification event.

The primary advantages to this are twofold:

• The DOWN notification is only sent for the nearest problem parent host. All other hosts beyond that host fire UNREACHABLE notifications. This means that Nagios Core’s reachability logic automatically determines the point of failure from its perspective, which can be very handy in diagnosing which host is actually experiencing a problem.

• If the host is a parent to a large number of other hosts, the configuration can be arranged not to send urgent notifications for UNREACHABLE hosts. There may not be much point sending a hundred pager or e-mail messages to an administrator when a very central router goes down; they know there are problems with the downstream hosts, so all we would be doing is distracting them with useless information.

With a little planning and some knowledge of the network, all we need to do is add a few parents directives to host definitions to build a simple network structure, and Nagios Core will behave much more intelligently as a result. This is one of the easiest ways to refine the notification behavior of Nagios Core; it can’t be recommended enough!

There’s more…

Note that a child host can itself be a parent to other hosts in turn, allowing a nesting network structure. Perhaps in another situation, we might find that the corsica.naginet server is two routers away from the monitoring server:

In this case, not only is corsica.naginet the child host of calpe.naginet, but calpe. naginet is itself the child host of janus.naginet. We could specify this relationship in exactly the same way:

define host {
use linux-router
host_name calpe.naginet
alias calpe
address 10.128.0.129
parents janus.naginet
}

It’s also possible to set multiple parents for a host, if there are two possible paths to the same machine:

define host {
use linux-server
host_name corsica.naginet
alias corsica
address 10.128.0.71
parents calpe.naginet,janus.naginet
}

With this configuration, corsica.naginet would only be deemed UNREACHABLE if both of its parent hosts were down. This kind of configuration is useful to account for redundant paths in a network; use cases could include spanning tree technologies, or dynamic routing failover

After you’ve set up a good basic structure for your network using the parents directive, definitely check out the Using the network map recipe in this article to get some automatic visual feedback about your network’s structure as generated from your new configuration.

See also

• The Using the network map and Establishing a host dependency recipes in this article

Using the network map

In this recipe, we’ll examine our network hierarchy in the network map (or status map) in the Nagios Core web interface. The network map takes the form of a generated graphic showing the hierarchy of hosts and their current states. You can learn how to establish such a hierarchy in the recipe Creating a network host hierarchy in this article. The network map allows filtering to show specific hosts, and clicking on hosts to navigate through larger networks.

Getting ready

You will need to be running a Nagios Core 3.0 or newer server, and have access to its web interface. You will also need permission to view the states of hosts, preferably all hosts. You can arrange this by adding your username in the authorized_for_all_hosts directive, normally in /usr/local/nagios/etc/cgi.cfg; for example, for the user tom, we might configure the directive to read as follows:

authorized_for_all_hosts=nagiosadmin,tom

By default, the nagiosadmin user should have all the necessary permissions to view the complete map.

The network map is not particularly useful without at least a few hosts configured and arranged in a hierarchy, so if you have not set any parents directives for your hosts, then you may wish to read the Creating a network host hierarchy recipe in this article first, and arrange your monitored hosts as it explains.

How to do it…

We can inspect the network map for our newly configured host hierarchy like so:

1. Log in to the Nagios Core web interface.

2. Click on the Map item in the menu on the left:

   

   You should be presented with a generated graphic showing all the hosts in your network that your user has permissions to view:

   

3. Hover over any host with the mouse to see a panel breaking down the host’s current state:

   

4. By default, the network map is centered around the Nagios Process icon. Try clicking on one of your hosts to recenter the map; in this example, it’s recentered on calpe.naginet:

   

How it works…

The network map is automatically generated from your host configuration. By default, it arranges the hosts in sectors, radiating outward from the central Nagios Process icon, using lines to show dependencies, and adjusting background colors to green for UP states, and red for DOWN or UNREACHABLE states.

This map is generated via the GD2 library, written by Thomas Boutell. It takes the form of a linked image map. This means that you can simply right-click the image to save it while the network is in a particular state for later reference, and also that individual nodes can be clicked to recenter the map around the nominated host. This is particularly useful for networks with a large number of hosts and very many levels of parent/child host relationships.

There’s more…

Note that the form in the panel in the top-right allows customizing the appearance of the map directly:

• Layout Method: This allows you to select the algorithm used to arrange and draw the hosts. It’s worth trying each of these to see which you prefer for your particular network layout.

• Scaling factor: Change the value here to reduce or increase the size of the map image; values between 0.0 and 1.0 will reduce the image’s size, and values above 1.0 will increase it.

• Drawing Layers: If your hosts are organized into hostgroups, you can filter the map to only display hosts belonging to particular groups.

• Layer mode: If you selected any host groups in the Drawing Layers option, this allows you to select whether you want to include hosts in those groups in the map, or exclude them from it.

• Suppress popups: If you find the yellow information popups that appear when hovering over hosts annoying, then you can turn them off by selecting this checkbox.

After selecting or changing any one of these options, you will need to click on Update to apply them.

The appearance of the status map can be configured well beyond this by changing directives in the Nagios Core configuration file, and adding some directives to your hosts; take a look at the recipes under the See also section of this recipe for some examples of how this is done.

See also

• The Customizing appearance of the network map , Choosing icons for hosts, Specifying coordinates for a host on the network map, and Using the network map as an overlay recipes in this article

Choosing icons for hosts

In this recipe, we’ll learn how to select graphics for hosts, to appear in various parts of the Nagios Core web interface. This is done by adding directives to a host to specify the paths to appropriate images to represent it.

Adding these definitions has no effect on Nagios Core’s monitoring behavior; they are mostly cosmetic changes, although it’s useful to see at a glance whether a particular node is a server or a workstation, particularly on the network map.

Getting ready

You will need to be running a Nagios Core 3.0 or newer server, and have access to its web interface. You must also be able to edit the configuration files for the server.

It’s a good idea to check that you actually have the required images installed. The default set of icons is included in /usr/local/nagios/share/images/logos. Don’t confuse this with its parent directory, images, which contains images used as part of the Nagios Core web interface itself.

In the logos directory, you should find a number of images in various formats. In this example, we’re interested in the router and rack-server icons:

$ ls /usr/local/nagios/share/images/logos/{router,rack-server}.*
/usr/local/nagios/share/images/logos/rack-server.gd2
/usr/local/nagios/share/images/logos/rack-server.gif
/usr/local/nagios/share/images/logos/router.gd2
/usr/local/nagios/share/images/logos/router.gif

To get the full benefit of the icons, you’ll likely want to be familiar with using the network map, and have access to view it with the appropriate hosts in your own Nagios Core instance. The network map is introduced in the Using the network map recipe in this article.

How to do it…

We can define images to be used in displaying our host as follows:

1. Change to the objects configuration directory for Nagios Core. The default path is /usr/local/nagios/etc/objects. If you’ve put the definition for your host in a different file, then move to its directory instead.

   # cd /usr/local/nagios/etc/objects

2. Add three new directives to each of the hosts to which you want to apply the icons. In this example, the rack-server icon is assigned to corsica.naginet, and the router icon to both calpe.naginet and corsica.naginet:

   define host {
   use linux-server
   host_name corsica.naginet
   alias corsica
   address 10.128.0.71
   icon_image rack-server.gif
   icon_image_alt Rack Server
   statusmap_image rack-server.gd2
   }
   define host {
   use linux-router
   host_name janus.naginet
   alias janus
   address 10.128.0.128
   icon_image router.gif
   icon_image_alt Router
   statusmap_image router.gd2
   }
   define host {
   use linux-router
   host_name calpe.naginet
   alias calpe
   address 10.128.0.129
   icon_image router.gif
   icon_image_alt Router
   statusmap_image router.gd2
   }

3. Validate the configuration and restart the Nagios Core server:

   # /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
   # /etc/init.d/nagios restart

With this done, a visit to the status map should display the appropriate hosts with icons rather than question marks:

The Hosts list should also include a scaled-down version of the image:

How it works…

When a host list, service list, or network status map is generated, it checks for the presence of icon_image or statusmap_image values for each host object, reads the appropriate image if defined, and includes that as part of its processing. The network status map defaults to displaying only a question mark in the absence of a value for the statusmap_image directive.

Note that for the statusmap_image directive, we chose the .gd2 version of the icon rather than the .gif version. This is for performance reasons; the status map is generated with the GD2 library, which deals more efficiently with its native .gd2 format.

The icon_image_alt directive defines the value for the alt attribute when the image is displaying in an <img> HTML tag. Most web browsers will show the contents of this tag after briefly hovering over the icon.

Nagios Core 3.0 allows you to put these directives in a separate hostextinfo object, but this object type is officially deprecated as of Nagios Core 4.0, so it’s recommended to avoid it.

There’s more

If you have a number of hosts that need to share the same image, it’s a good practice to inherit from a common host template with the appropriate directives set. For our example, we might define a template as follows:

define host {
name router-icon
icon_image router.gif
icon_image_alt Router
statusmap_image router.gd2
register 0
}

We could then apply the image settings directly to both our routers simply by inheriting from that template, by adding it to the use directive:

define host {
use linux-router,router-icon
host_name janus.naginet
alias janus
address 10.128.0.128
}
define host {
use linux-router,router-icon
host_name calpe.naginet
alias calpe
address 10.128.0.129
}

If you don’t like the included icon set, there are many icon sets available online on the Nagios Exchange site at http://exchange.nagios.org/. If you want, you could even make your own, out of pictures of your physical hardware, saved in standard PNG or GD2 format.

See also

The Using the network map and Specifying coordinates for a host on the network map recipes in this article