11 KiB

Raw Blame History

Service Monitoring

The power of Icinga 2 lies in its modularity. There are thousands of community plugins available next to the standard plugins provided by the Monitoring Plugins project.

Requirements

Plugins

All existing Nagios or Icinga 1.x plugins work with Icinga 2. Here's a list of popular community sites which host check plugins:

The recommended way of setting up these plugins is to copy them to a common directory and create a new global constant, e.g. CustomPluginDir in your constants.conf configuration file:

# cp check_snmp_int.pl /opt/monitoring/plugins
# chmod +x /opt/plugins/check_snmp_int.pl

# cat /etc/icinga2/constants.conf
/**
 * This file defines global constants which can be used in
 * the other configuration files. At a minimum the
 * PluginDir constant should be defined.
 */

const PluginDir = "/usr/lib/nagios/plugins"
const CustomPluginDir = "/opt/monitoring/plugins"

Prior to using the check plugin with Icinga 2 you should ensure that it is working properly by trying to run it on the console using whichever user Icinga 2 is running as:

# su - icinga -s /bin/bash
$ /opt/monitoring/plugins/check_snmp_int.pl --help

Additional libraries may be required for some plugins. Please consult the plugin documentation and/or plugin provided README for installation instructions. Sometimes plugins contain hard-coded paths to other components. Instead of changing the plugin it might be easier to create logical links which is (more) update-safe.

Sometimes there are plugins which do not exactly fit your requirements. Either you'll modify an existing plugin or you'll write one by yourself.

CheckCommand Definition

Each plugin requires a CheckCommand object in your configuration which can be used in the Service or Host object definition.

Please check if the Icinga 2 package already provides an existing CheckCommand definition. If yes throroughly check the required parameters and integrate the check command into your host and service objects.

There are the following conventions to follow when adding a new command object definition:

Always import the plugin-check-command template
Use command-arguments whenever possible. The command attribute must be an array in [ ... ] then for shell escaping.
Define a unique prefix for the command's specific command arguments. That way you can safely set them on host/service level and you'll always know which command they control.
Use command argument default values, e.g. for thresholds
Use advanced conditions like set_if definitions.

Example for a custom my-snmp-int check command:

object CheckCommand "my-snmp-int" {
  import "plugin-check-command"

  command = [ CustomPluginDir + "/check_snmp_int.pl" ]

  arguments = {
    "-H" = "$snmp_address$"
    "-C" = "$snmp_community$"
    "-p" = "$snmp_port$"
    "-2" = {
      set_if = "$snmp_v2$"
    }
    "-n" = "$snmp_interface$"
    "-f" = {
      set_if = "$snmp_perf$"
    }
    "-w" = "$snmp_warn$"
    "-c" = "$snmp_crit$"
  }

  vars.snmp_v2 = true
  vars.snmp_perf = true
  vars.snmp_warn = "300,400"
  vars.snmp_crit = "0,600"
}

For further information on your monitoring configuration read the Monitoring Basics chapter.

If you have created your own CheckCommand definition please kindly send it upstream

Plugin API

Currently Icinga 2 supports the native plugin API specification from the Monitoring Plugins project.

The Monitoring Plugin API is defined in the Monitoring Plugins Development Guidelines.