[icinga-devel] Icinga2 0.0.2 Milestone Compat 1.x Details
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
* 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
jabber: dnsmichi at jabber.ccc.de
irc: irc.freenode.net/icinga dnsmichi
icinga open source monitoring
position: lead core developer
More information about the icinga-devel