Icinga 2 Features: User-Focused Monitoring


Icinga 2  introduces a new object-based configuration format, which offers templates and user-friendly features such as freely definable macros. Taking inspiration from Puppet formats, Icinga 2 offers clear, “one best way” configuration rules. This allows Icinga 2 to depart from Nagios(TM)’s multiple configuration formats (e.g. defining host/service dependencies and parent/child relationships for hosts) – the cause of much user confusion.

The Icinga 2 configuration format is currently set as text files to begin with, in preparation for later transition to configuration via API, or GUI and CLI. A configuration migration script that translates existing Icinga 1.x / Nagios configurations into the new Icinga 2 format also makes migration easier.


Similar to Icinga 1.x, event handlers and notifications will be supported. Thanks to the new dynamic configuration format, users will be able to adjust notification settings at runtime (e.g. in order to implement on-call rotation).

For example, new notification objects replace notification-specific attributes for services, while user and user groups replace contact and contact groups. This new format allows notifications to be defined more precisely and intuitively.

On top of this, escalations in Icinga 2 are configured as notifications with a defined beginning and end.


In Icinga 2, services are the only checkable objects. Hosts only have a calculated state and no checks are needed.  To maintain compatibility with the hundreds of existing plugins for Icinga 1.x , a plugin interface to support Nagios(TM)-style monitoring is also available. This too has a modular design, so that support for other kinds of checks can later be implemented.

With this new monitoring model, the core can delegate the execution of service checks based on the availability of remote Icinga 2 instances. This vastly improves monitoring performance in large, distributed environments, while reducing maintenance work. Services can be assigned to specific check instances using configuration settings.


Instead of specifying various arguments for services checks that need to be modified with plugin changes, Icinga 2 offers the convenience of global macros that can be defined and assigned to hosts as parameters for service checks. Indeed, there are no fixed macros for IP addresses also offering greater flexibility, especially in clustered setups.

From Icinga.1.x:

define command {
    command_name  ping4
    command_line  $USER1$/check_ping -H $HOSTADDRESS$ -w $ARG1$ -c $ARG2$ -p 5
define service {
    use                     local-service
    host_name               localhost
    service_description     PING
    check_command           ping4!100.0,20%!500.0,60%

To Icinga 2:

object CheckCommand "ping4" {
    command = "$plugindir$/check_ping -H $HOSTADDRESS$ -w $wrta$,$wpl%$ -c $crta$,$cpl%$",
   macros = {
        wrta = 100,
        wpl = 20,
        crta = 500,
        cpl = 60
object Host ”localhost" {
   services[“PING“] = {
      check_command = “ping4”,
      //macros[“wrta”] = 250