Icinga 2 – Features

User-focused monitoring

Monitoring a network with multitude of services, devices and dependencies between them is complex enough. No need to make set-up or maintenance of the monitoring system itself any more complex. That’s why Icinga 2 features a new configuration format that is intuitive to write, efficient to execute and even adjusts to the changing conditions of your environment at run-time.

l

Clear-cut, object-based configuration

Icinga 2 introduces a new object-based, rule-driven configuration format, which offers user-friendly features such as apply rules for dynamic object generation. 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.

i

Apply & assign attributes

Keep configuration work to a minimum by defining templates to ”apply” to configuration objects. Apply services and notifications to hosts, or downtimes and dependencies to services for example. Use “assign where” or “ignore where” expressions to specify valid targets.

apply Service "load" {
  import "generic-service"
  check_command = "load"
  assign where "linux-server" in host.groups
  ignore where host.vars.no_load_check
}

Clever commands & runtime macros

Commands in Icinga 2 are smarter than their Nagios™-style cousins. To begin with, Icinga 2 offers three distinct command types: Check, notification and event commands. They can be given default values, custom attributes, runtime macros and conditional behaviours. Each additional option can be given precedence over the other, so that your configuration intelligently adapts at runtime to changing monitoring conditions.

z

Dynamic Notifications

Similar to Icinga 1, event handlers and notifications are supported. Thanks to the new dynamic configuration format, users can 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, as are recurring downtimes.