Introduction

On my previous post – Some Icinga Core basics – Part Three – I discussed a little about monitoring remote Linux servers in more depth – specifically using NRPE.  In this post I’m going to cover host dependencies and using icons and images with Icinga Core.

NOTE: while a lot of this is stated as Raspberry Pi specific it’s really just general Icinga configuration on a Debian based system (e.g. Ubuntu).

Host Dependencies

Icinga is able to tell the difference between a remote host being down or just unreachable.  When Icinga reports a host as being down it is reporting directly on that host whereas when it reports unreachable it is making an assumption based on that host’s parents being down.  Let’s look at an example:

icinga_relationships1

  • If Switch B were to report down then Host A and Host B would report unreachable.
  • If Router A were to report down then Router B, Switch C and Host C would report unreachable.

This is achieved by using parent/child relationships in Icinga.  Again looking at the above example:

  • Switch A has the parent Icinga Monitoring Host
  • Host A and Host B have the parent Switch B which in turn has the parent Switch A.
  • Host C has the parent Switch C which has the parent Router B which has the parent Router A which has the parent Switch A

This simple parent/child relationship hierarchy shows how Icinga can report the accurate status of a remote device.

Configuration

My previous post – Some Icinga Core basics – Part Two – describes host objects and the associated file(s).  The relationships described above are configured using the parents directive in the host object configuration.  I’ll take the second bullet point above and show the basic host directives in this instance:

define host{
        host_name       IcingaMonitoringHost
        }

 define host{
        host_name       SwitchA
        parents         IcingaMonitoringHost
        }

 define host{
        host_name       SwitchB
        parents         SwitchA
        }

 define host{
        host_name       HostA
        parents         SwitchB
        }

 define host{
        host_name       HostB
        parents         SwitchB
        }

NOTE: The first entry IcingaMonitoringHost doesn’t have a parent as it’s the top level.

When you’ve configured these relationships you can see a visual representation from the Icinga Core home page by browsing to Status | Staus Map.  Here’s a very small real world example:

icinga_relationships2

You can see the billion host is the parent for the manage host and the cisco01 host, with the cisco01 host being the parent for the storcenterix2 host.

Working with Images and Icons

The example Status Map above demonstrates you can use your own images as icons for Hosts if the stock options don’t cover your needs.  In addition the Host views on Icinga Core can also be told to use an icon.  As previously mentioned there are stock icons that get used when a match is detected for the running Operating System.  The Raspberry Pi for example typically displays a Debian icon on the Status Map and Host Detail screens.

The default location to place your logos on Icinga Core is /usr/share/icinga/htdocs/images/logos.   In this folder you’ll also find all the stock icons under a variety of sub directories.  Alternatively you could create your own sub directory here and reference the files with folder/filename.xxx.

Creating Images and Icons

The rules for image creation (from the Icinga documentation and testing) are:

  • Try to find images with transparent backgrounds and keep this for best looking icons.
  • The icon_image (used on the Host detail screens) is best sized at 40×40 (scaling happens on this image but if you’re having problems stick with 16×16).
    This file format should be PNG (or another format that retains the transparent background)
  • The statusmap_image (used on the Status Map screen) is best sized at 40×40 and type GD2.

A typical example of an image that can be used for the Host views and Status Map would be to create a 40×40 PNG.  You can then upload this and convert it to GD2 format giving you the  the icon_image and statusmap_image.

As mentioned above the statusmap_image is recommended to be in the GD2 format especially for large status maps that would require significant CPU time to generate.

First of all you need to upload your file(s) to /usr/share/icinga/htdocs/images/logos (or a subdirectory of this) based on the rules above where possible.  Next, check if you have the png2gd2 binary (that allows conversion from PNG to GD2):

$ dpkg -s libgd-tools

If it’s installed you’ll see:

Package: libgd-tools
Status: install ok installed

If the png2gd2 binary (i.e. the libgd-tools package) does not exist install it with the following command:

$ sudo apt-get install libgd-tools

To convert your file(s) into the GD2format use the following (example is using a file called file.png):

$ cd /usr/share/icinga/htdocs/images/logos

$ pngtogd2 file.png file.gd2 0 1

Configuring Images and Icons

Once you have the files in place it’s time to use two more Host directives – icon_image and statusmap_image (both mentioned above)

Edit your host object configuration file and add one or both of the above directives along with your file name (including sub directory if required)

Here’s an example:

define host{
        use                     generic-host            ; Name of host template to use
        host_name               storcenterix2
        alias                   Iomega StorCenter ix2-200
        address                 192.168.0.30
        parents                 cisco01
        icon_image              storcenter-ix2-small.png
        statusmap_image         storcenter-ix2-small.gd2
        }

You can see the two icon related directives specified above for the StoreCenter ix2 host.

Wrap up

I hope this post has been a logical follow on from my previous three posts on getting Icinga up and running.  The host dependencies (parent/child relationships) are a key feature that you’ll use in more complex environments.

Some Icinga Core basics – Part One

Some Icinga Core basics – Part Two

Some Icinga Core basics – Part Three

Some Icinga Core basics – Part Five

References

As always the Icinga documentation is excellent and expands on everything I’ve brought together above.  It’s my first port of call when learning the product features and configuration.

Determining Status and Reachability of Network Hosts

Object Definitions

Some Icinga Core basics – Part Four – Relationships and Icons
Tweet about this on TwitterShare on Google+0Share on Facebook0Email this to someone
Tagged on:                 

5 thoughts on “Some Icinga Core basics – Part Four – Relationships and Icons

Leave a Reply

Your email address will not be published. Required fields are marked *