Introduction

On my previous post – Some Icinga Core basics – Part One – I discussed the default paths of the Icinga installation, the default configuration files in the /etc/icinga/objects folder and a little about custom configuration files.  In this post I’ll cover an overview of plugins and the ones installed with Icinga.  In addition we’ll look at some configuration files and add a simple host.

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).

Plugins

Icinga itself does not monitor anything or contain any method of doing so. Instead it relies on external programs (typically executables or scripts) to perform any checks on hosts or services.  A plugin will perform some action and output in a standard defined way that Icinga can understand and interpret.  As always the excellent Icinga documentation provides a comprehensive section on plugins here.

The Icinga package on Raspbian (and Debian, Ubuntu) is a metapackage so it installs other packages and dependencies.  Within this list of packages is the nagios-plugins metapackage that includes the nagios-plugins-basic and nagios-plugin-standard packages.  These packages install a big chunk of plugins to get started.

These plugins can be found in /usr/lib/nagios/plugins/ and the associated configuration files (containing related commands) can be found in /etc/nagios-plugins/config.

Example Plugin – SSH

Let’s take a quick look at a plugin – check_ssh – and some related commands.  As described above, the plugin itself is /usr/lib/nagios/plugins/check_ssh.  Run this with –help and you’ll see the sort of input it requires.  

foo@raspberrypi ~ $ /usr/lib/nagios/plugins/check_ssh –help

At the absolute minimum it needs a host.  Let’s run it against itself (localhost):

foo@raspberrypi ~ $ /usr/lib/nagios/plugins/check_ssh localhost

SSH OK – OpenSSH_6.0p1 Debian-4 (protocol 2.0) | time=0.108092s;;;0.000000;10.000000

This plugin has successfully connected to the local SSH server.  There is also additional data in the output.

The configuration file for this plugin is /etc/nagios-plugins/config/ssh.cfg and contains various commands for use when defining a service.  The basic check_ssh command just requires a hostname to be provided (the $HOSTNAME$ macro – IP address taken from the host definition being monitored).  Whereas one of the latter commands allows a port to be specified as well – using the $ARG1$ macro (this will be explained later).

You may recall from your own localhost installation that Icinga is already monitoring the SSH server on localhost – as shown below.

basic-icinga-localhost

Refer back to Part One where I introduced the default config files.  The SSH example is a little more convoluted because it introduces hostgroups.  Let’s look at hostgroups_icinga.cfg and services_icinga.cfg:

/etc/icinga/objects/hostgroups_icinga.cfg

# A list of your ssh-accessible servers
define hostgroup {
        hostgroup_name  ssh-servers
                alias           SSH servers
                members         localhost
        }

A hostgroup has been defined with the name ssh-servers with the member localhost.

/etc/icinga/objects/services_icinga.cfg

# check that ssh services are running
define service {
        hostgroup_name                  ssh-servers
        service_description             SSH
        check_command                   check_ssh
        use                             generic-service
        notification_interval           0 ; set > 0 if you want to be renotified
}

A service has been defined that applies to all members of the hostgroup ssh-servers.  The check command for this is just check_ssh.  We saw earlier that the $HOSTNAME$ parameter is required but this is automatically available to the plugin.

These two files together mean the SSH service appears under localhost in Icinga.

Open up /etc/icinga/objects/localhost_icinga.cfg.  This file contains other default services for localhost but these are stated in this file and apply only to localhost (as specified by the host_name directive).  Notice other check commands are passing additional parameters – each split by an exclamation mark.  These come into the plugin (in the order the’re given) as $ARG1$, $ARG2$ etc.

New Host

OK, let’s add a new host with some basic monitoring we can do right away – Is it alive? Is the SSH server listening?  For this example I’m going to add an Ubuntu virtual machine called VMUB01 with an IP address 192.168.0.20.

foo@raspberrypi ~ $ sudo nano /etc/icinga/objects/vmub01.cfg

Add the following (adjust as necessary):

define host{
	use                     generic-host            ; Name of host template to 	use
	host_name               vmub01
	alias                   VMUB01 - Ubuntu Virtual Machine
	address                 192.168.0.20
}

The host object can of course have many more directives, but in this case we are going to inherit the rest of these from the generic-host host template.  If you want to have a look through this template open the file /etc/icinga/objects/generic-host_icinga.cfg (mentioned in part one – default files).

Save the file and exit.  Open the hostgroups file:

foo@raspberrypi ~ $ sudo nano /etc/icinga/objects/hostgroups_icinga.cfg

Add vmub01 to the members directive (using a comma to separate the two)

members localhost,vmub01

Save the file and exit.  Restart the Icinga service.

foo@raspberrypi ~ $ sudo service icinga restart

Browse to your Icinga page (http://ip_address/icinga), select Host Detail and you should see your new host either green and UP or PENDING.

icinga-vmub01-up

Click the small document icon beside the host name (labelled Service Details).  You should see the SSH service here – this will likely be PENDING but will show you when it will run the check under the Status Information heading.

icinga-vmub01-ssh-pending

When complete it should also be green and UP.

icinga-vmub01-ssh-up

We’ve now added a host and are monitoring its status (up/down) and whether the SSH server is listening or not.

This is just the tip of the iceberg and we can monitor so much more.  In the next post I’ll cover using NRPE for remote monitoring of Linux servers so we can get more information (like users, processes and load) so it looks like our localhost (even this will just be scratching the surface!)

Some Icinga Core basics – Part One

Some Icinga Core basics – Part Three

Some Icinga Core basics – Part Four

Some Icinga Core basics – Part Five

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

7 thoughts on “Some Icinga Core basics – Part Two

Leave a Reply

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