[icinga-devel] Icinga2 0.0.2 Milestone Compat 1.x Details

Michael Friedrich michael.friedrich at gmail.com
Tue Jul 2 20:01:32 CEST 2013

Dear Icinga developers & community,

basically we've assigned plenty of tasks and issues reaching out for 
compatibility with Icinga Core 1.x. While this made the milestone pretty 
huge, there feature set now implemented and available is pretty awesome.

You'll find most of the changes in short on the blog post

If you want to get started on the first configuration examples, either 
build the sources having asciidoc installed (look into docs/) or follow 
the tutorial online: 

You may figure that there's more than just a simple 
host/service/notification/user object to define ;-) Either way, having 
an existing Icinga 1.x icinga.cfg tree around, navigate to 
tools/configconvert/ and consult the README on calling the icinga2 
conversion script. For details check 

The configuration format is ~95% final, so every (config gui) addon dev 
is invited to dive into the new format :)

Next to the configuration stuff - Icinga Classic UI standalone works 
like a charm with Icinga2 having Compat and CompatLog loaded, as well as 
having Perfdata writers for PNP4Nagios, inGraph, graphite, etc.

Details on the features and changes

* the host check state will be a virtual state provided from a given 
service object and its check output. currently, this is a single object, 
but with business process this can be changed then too (different milestone)

* the new notification object works as relation between services and 
users (contacts). that way one can define one user for n notifications 
for 1 service. it supports templates and inherits values from the linked 
service object. it got its own notification command.

* commands are now divided into 3 type of commands: Check, Notification 
and Event. This will organise the configuration a bit better, and also 
makes sure to use the right command in the right place. Further, those 
commands take more than just a commandline (macros, etc).

* escalations are now notifications, but with a given begin and end 
time. on escalation, they will generate additional notifications, but 
leaving the "normal" notifications

* notification_options have always been cryptic. Our design decision was 
to split it into "state" and "type" allowing more logical filters on the 
notifications then. Furthermore, those values are made script constants 
provided through the itl, i.e. StateFilterCritical. All values can be 
or'ed together. Note: There's more detailed filters available, e.g. for 

* the command arguments with '!' and then $ARGn$ are no more. Icinga2 
allows freely definable macros which can be used on the check commands 
e.g. defining dedicated environment macros is possible using 
"export_macros" on the command object definition - the same place where 
you can define default macros for the command parameters.

* Dependencies are now defined on the host/service object itsself.

* Downtimes are still dynamic events to be set through the external 
command pipe for now.

* All *enable* attributes are named as "enable_*". More details on the 
configuration changes itsself are listed on the wiki: 

* Timeperiods support the legacy 1.x format (but being prepared for more 
dynamic configuration by calendar providers) and can be used for check 
and notification periods.

* Perfdata Writer, Checkresult Reaper, External Command Pipe, Compat & 
CompatLog (status.dat/objects.cache, icinga.log), and 
Console|File|SyslogLogger complete the native external interfaces 
feature set.

* In-short: Icinga2 will run, check, alert, notify, log. All existing 
plugins are compatible.

There's likely more in-depth details which I may have forgotten after 
joining Gunnar's development deeply last week - still, you got the git 
history: https://git.icinga.org/?p=icinga2.git;a=shortlog and the 
development tracker activity: 
https://dev.icinga.org/projects/i2/activity to follow. Tip: @icinga_dev 
on twitter pulls the 5 recent issue changes every 1/2 hour on 

The next milestones will target database and livestatus support, and 
after that agents, distributed, business processes, api.

You'll find us lurking on #icinga-devel on freenode too.

Kudos to Gunnar (shroud) for doing a magnificant job on making this happen.

Thanks for testing,
DI (FH) Michael Friedrich

mail:     michael.friedrich at gmail.com
twitter:  https://twitter.com/dnsmichi
jabber:   dnsmichi at jabber.ccc.de
irc:      irc.freenode.net/icinga dnsmichi

icinga open source monitoring
position: lead core developer
url:      https://www.icinga.org

More information about the icinga-devel mailing list