This release and milestone is dedicated to “Compat 1.x” which in general means to act as drop-in replacement to the current Icinga 1.x Core. It’s tagged 0.0.2 and can be downloaded from sourceforge. Please follow the instructions in the INSTALL file closely.
Modern architecture
Icinga 2 is multithreaded and supports checks, notifications and event handlers in parallel. Recent benchmark tests have shown that Icinga 2 can run approximately 120,000 active checks per minute using check_dummy as an external plugin (run on dual core Intel Xeon server). With passive checkresults even more services can be checked on a single Icinga 2 instance.
New configuration format
We’ve done our homework with your feedback and have pushed development ressources into creating a config conversion script (tools/configconvert/README and wiki).
The conversion script is able to convert most 1.x configurations keeping the existing template tree. Your tests with configuration in the wild are required – feedback welcome!
Making configuration easier – the Icinga template library is provided with Icinga 2 and offers plenty of predefined template objects within your configuration. You can use includes with wildcards and search directories (details on the docs). And yet, keep in mind that it’s all about templates and one way to organise your configuration. Everything can be a template, and just used – like services in your host definitions.
Documentation can be found in the source tarball in docs/ directory – install asciidoc and run ./configure ; make to generate those.
Compatibility
All existing plugins will work with Icinga2. The only difference is that the complicated “pass the args with ‘!’ and have $ARGn$ mapped onto them” is now gone. You’ll define your macros within the macros dictionary either on the service object or directly on the command object, and use them in your command definition then. Give them meaningful names and resolve errors more easily! You can even define default macros in the command definition.
Using Icinga 1.x this would look like
define command {
command_name check_ping4
command_line /usr/local/icinga/libexec/check_ping -4 -H $HOSTADDRESS$ -w $ARG1$,$ARG2% -c $ARG3$,$ARG4$%
}
define service {
service_description ping4
host_name localhost
check_command check_ping4!100!5!200!15
...
}
define host {
host_name localhost
adress 127.0.0.1
...
}
Icinga2 allows you to define free macro strings inherited from the host/service to the command. The service “ping4” also uses the template “ping4” from the Icinga Template Library (ITL).
object CheckCommand "check_ping4" inherits "plugin-check-command" {
command = "/usr/local/icinga/libexec/check_ping -4 -H $HOSTADDRESS$ -w $wrta$,$wpl$% -c $crta$,$cpl$%"
}
object Host "localhost" {
services["ping4"] = {
templates = [ "ping4" ],
check_command = "check_ping4",
macros = {
wrta = 100,
wpl = 5,
crta = 200,
cpl = 15,
}
},
macros = {
address = "127.0.0.1",
},
hostcheck = "ping4",
}
By default, the icinga2.conf example loads the Compat and CompatLog components which will write status.dat/objects.cache and icinga.log in Icinga 1.x format. These can be used in an Icinga Classic UI 1.x installation (details on the tutorial). Status, History, Reporting (Alerts, Notifications, Downtimes, etc) – it is already available.
Even if there are freely definable macros as dictionary, reaching compatibility with Icinga 1.x macros e.g. $HOSTADDRESS$ or $SERVICEOUTPUT$ was one of the primary goals for this milestone. Furthermore, you can now define all required environment macros using “export_macros” (compared to Icinga 1.x with all-or-nothing, a huge benefit).
Checks, Alerts and Notifications
The delegation, checker and notification components will schedule and execute the checks and notify when problems arise.
- Flapping
- Downtimes
- Dependencies
- Freshness
- Event Handler
- Notifications
- Acknowledgements
- Comments
Flapping, Dependencies, etc are statically defined in the initial configuration, while downtimes must be set using the external command pipe (i.e. through Classic UI). Downtimes follow the fixed and flexible approach known from Icinga 1.x. Event handlers from 1.x are now defined using the “event_command” setting in a service object.
A notification is a new object in Icinga 2. It acts as a relation between the service and the user (contact), getting its own notification command. That way you can easily create multiple notifications, but only referencing one user. The old way of duplicating the contacts to XY-mail and XY-sms in order to use proper notifications is gone in Icinga2. For details check the tutorial. The well known cryptic “notification_options w,u,f,d,r” are now split into state and type filters into 2 configuration options.
object User "michi" {
notification_state_filter = (StateFilterUnknown | StateFilterWarning | StateFilterCritical),
notification_type_filter = (NotificationFilterRecovery | NotificationFilterAcknowledgement),
}
Furthermore, an escalation is now the same as a notification, but with a defined begin and end time (Icinga 1.x was a counter based on the notification_interval). That way, it will run in parallel to the existing notifications, and not replace them in case of escalation. We think this will make escalations and notifications organisation relatively easy compared to the old system.
Legacy 1.x Configuration
Support for legacy Icinga 1.x time periods has been added, which is exactly the same as found in the Icinga 1.x documentation. Checks and notifications/escalations are based on time periods, if defined. Hosts only have a virtual state, provided by an existing service check (as “hostcheck”). Contacts have been renamed to users because they can be used not only for notifications, but also just for authorization (made possible with the notifications object). Groups exist for grouping only, members must be defined at the object definition.
External Interfaces
All important external commands (e.g. reschedule check, acknowledge problem, schedule downtime) are available when loading the Compat component.
The new configuration format let’s you define multiple performance data writers with different output templates for PNP, inGraph, Graphite, etc.
If you are running an Icinga 1.x distributed setup, it may also be reasonable to replace the master (or the slaves). For that reason, Icinga 2 also supports the check result reaper from a spool directory on disk. Using the LConf (or NSCA) distributed mechanism this allows you to replace the current master, either reaping the check results from disk, or receiving passive check results via external command pipe.
In regard to native logging, you can use 3 types: ConsoleLogger, FileLogger and SyslogLogger with different severity settings. This will help debug Icinga 2 while it’s being tested in your environment 🙂
An optional database and livestatus component is still under development (Icinga Web, Reporting, other GUIs).
Conclusion
We’ve been writing a tutorial to guide you with the installation and the basic configuration steps after downloading Icinga 2 0.0.2. Either follow the tutorial or copy the sample icinga2.conf.dist to icinga2.conf starting icinga2 with the provided init script – it looks like this:
The next milestones will be DB, Livestatus followed by topics like Agents, API, Business Processes and so on – you’ll see there’s plenty of things to do for the final release 🙂
