Last week I told Blerim that Icinga came to life on 6.5.2009 … really, 10 years already?

A small group of Nagios community members stood up and wanted to create more than a monitoring core with an enhanced web interface. APIs, integrations, backends, scaling, metrics, … A lot of passion and love was received from the community and actually, the Nagios ecosystem became more active again. We tried many things to improve the existing code base and limitations in both backends and frontends. TL;DR – at some point we decided to throw it away and start fresh. The rest can be read on our blog 🙂


service icinga restart

Back in 2012, Gunnar, Bernd and Marius paid a visit to Vienna. They had something with them what is known to be the first prototype of Icinga 2, codename “Strawberry“. Moving from C into C++ was a whole new world, Golang didn’t really exist back then. Oh, it can run on Windows too. Oh, such speed and performance. Oh, a new playground for our crazy ideas.

Before its first 2.0 release five years ago we had many design rounds with service sets on the Host object, virtual host checks from services and so on. This changed quite a bit after strong opinionated discussions in early 2014. Those are also the origin of the magic apply rules, with mimicking the “put a service on a hostgroup, each host member inherits it” object trick from Icinga 1. Nowadays you can generate monitoring configuration and make things easier.

“Monitoring as a code” became a thing when we had created our own DSL (domain specific language) which added functions, conditions, even loops from community feedback. We’ve also learned a lesson here with the Director released after 2.4 – not everything from inline DSL code is suitable for a configuration frontend. Also that we now have 3 APIs – Core, Web, Director – users might be confused. This is a task we will be working on in the future to unite the product stack better.

Speaking of web and modules, Icinga Web 2 started with the requirement of a general framework including web and CLI based on the Zend framework. IIRC this was 1,5 to 2 years after Icinga 2 kicked off, also explaining the version difference – 2.7 vs 2.11. Web version 1 had many short-comings and was complicated with extensions – unless you’re an experienced developer. With the power of making everything a moduie, even monitoring, the Icinga Web framework inspired the many of you.


Community work is a passion

One of the first community modules I’ve seen was the Globe module which I had shown at Icinga Camp Berlin 2017. Nicolai was so inspired to start the development of the map module. I was extremely happy that I’ve tested it quite extensively and sent a docs PR. Literally the same happened with Carsten creating the famous Grafana module – a gentle README, release hints and troubleshooting – the first impression counts. Did I mention the awesome themes already?

Pushing community ideas and spirit forward is one of the most important things in the way we have become Icinga. Without you and your shared love and criticism, we wouldn’t be here and still be sitting somewhere around the globe ranting about tools.

Back then, our community was a bit split, and not everyone had the time to answer questions on IRC, the mailing lists and the community forum at Monitoring Portal. While we want to be transparent with our development workflow, release dates and design ideas, it’s always time consuming and hard to catch up. With Icinga now supporting distributed environments with zones, endpoints, and web views and configuration forms, we needed something where text formatting and screenshots really integrate well. In late 2018, we’ve decided to create our own Icinga Discourse inviting the team, partners and users to discuss. I just love it, helping others really is a good feeling.

As you may know, the majority of the Icinga development is and was funded by NETWAYS, up until 2012 the University of Vienna sponsored my time. This is paid time and helps with creating the foundation for new features and maintenance. We also raised awareness on why funding and sponsoring is a good thing – if there is a bug biting you, or a missing feature you’d like to use in production, you can speed things up by requesting a quote, or even, by getting a support subscription through one of our partners. Sounds expensive? Maybe. Helps funding the future? Definitely.

Still, we love community contributions and value your (spare) time a lot. Sometimes contributions are hard to achieve as the code is not clear, or you actually don’t know where to start. In the past, we had our own Git server and ticket system. It worked somehow – with the move to GitHub and social coding with Pull Requests, reviews, discussions and a sound platform our daily work on Icinga has become a breeze. The help of issue templates, continuous integration (CI) on when a PR is created, and inline code comments puts the focus back on development.

Lastly, we’ve started documenting our core technical concepts and improved the development guidelines. This now also includes instructions for nightly snapshot builds.


Turning back the time a bit

Icinga 1 didn’t have packages at first glance. You had to call configure/make and pass some parameters for development libraries and headers, sometimes it didn’t work. The core was to compile and then it broke on your system, but the developer’s system worked fine. Ok, let’s create a VM for SuSE in Virtualbox … well, where is my yum?

One of the first ideas was to invite upstream packagers onto the team and learn from each other. Our many releases couldn’t reach stable distributions that fast, so we needed additional repositories. There’s Debian Backports, custom Ubuntu PPAs, EPEL for RHEL/CentOS and lastly, the SuSE OBS repos – not to forget all the other distributions in the Linux/Unix world, FreeBSD, OpenBSD, NetBSD, Gentoo, ArchLinux, … For the main officially supported platforms, we decided to create our own repository at https://packages.icinga.com.

Creating and maintaining packages next to the build infrastructure for each project, language and dependencies is a huge often underestimated effort. Our build server based on Jenkins made several iterations over the years, lately we decided to replace it with GitLab CI for less security risks and better configuration. CI and CD is just great, and with Docker containers nearly everything can be built – requiring your self-hosted infrastructure, maintained by the awesome managed service team at NETWAYS. This includes deployments with Foreman and Puppet, and of course monitoring with Icinga just like “eat your own dogfood” 🙂

Another thing which really was hard to achieve – ARM based architecture on Raspberry Pi. Sounds easy to just compile the binary packages on a different architecture. Actually we had to tackle compiler bugs and long running builds – we started a thing at the OSMC hackathon 2018 and Nicolai’s employer sponsored the last missing days on the road to official packages.


We can always improve

Looking back where we started 10 years ago, we’re in a very comfortable situation. This also includes making the initial setup a breeze, adding lots of documentation and helping on the community channels when things are on fire. With partners providing support, trainings and consultancy, the enterprise requirements are fulfilled even better.

In terms of new projects and ideas, it always turns out that we want to create 4 things, then 10 different customer issues arise, the proof of concepts don’t work out well and obviously, there’s only resources for one or two things being released later. Right on, many have asked about notification managers or mobile apps – that’s on hold for now, finishing the ongoing tasks with Core and Web major versions, Icinga DB and Icinga Reporting, and additional new module version for certificates (x509), Vsphere, Director and Business Process. Again, focus is required – you cannot manage 10 things in parallel. That being said, the monthly snap blog will be moved into a combined effort with the enhanced newsletter telling you about the latest and greatest developments. We also continue to have bi-yearly strategy workshops to refine future roadmaps and discuss changes in our ecosystem.

Those things are great to read, but even more, they are great to talk about. Our idea of meeting at Icinga Camps worked out pretty well, Berlin is by far the biggest one thus far. OSMC with the “State of Icinga” talk by Bernd is great and funny way to share the latest stories too. Our first Icinga team meeting was at OSMC 2009 with many more to come at Icinga Camps all over the world, where you’ll meet, chat and laugh. Our first Icinga Camp San Francisco 2014 happened at GitHub HQ. This is an incredible memory and kicked off the many community events after. In the past months, our community in Germany and Austria have been going strong with regular meetups, that’s truly inspiring. Not been there, or want to create your own meetup group? It is not too late.

We are also aiming for something bigger for everyone planning for next year: IcingaConf in Amsterdam in 2020.

Our way of not re-inventing the wheel but building our integrations with proven tools will continue. Today we are proud to enhance Elastic Stack with adding Icingabeat, Logstash outputs/filters and metric writers even. Adding monitoring as first class citizen in your DevOps lifecycle has become reality with official modules for Puppet, Ansible and Chef and a deeper integration into Foreman. If this isn’t enough, there’s more cloud provider integrations such as Terraform, AWS, Azure and whatnot. Enhancing metrics with Graphite and InfluxDB, provided with example Grafana dashboards and web module integrations. Dashing is still a thing, and reporting has come in its first early version for more SLA and visualization magic.

This is something we couldn’t imagine 10 years ago. We are also proud to work with many professionals and open source lovers all over the world, spreading the #monitoringlove.


The people behind, around and with Icinga

That’s not only me, I hear that often when people find my name on Google. This is a group of passionate people, each with their own character, ideas and responsibilities. Over the years, fellow friends went with us on our journey and left again for their new projects and private life.

Karo, who created the initial designs, blog posts and social media for Icinga. Amanda, who tackled technical problems and spread the love for Icinga on social media and press releases. Gunnar, who is the main architect of Icinga 2, and a passionate coder, the brain behind the DSL and many more. Hendrik who forked Icinga 1 as core and taught us how to use Git and debug the IDO backend.

Michael who worked many hours on Icinga Reports with Jasper, creating fancy web views. Thomas who took over the Oracle backend improvements for Core 1.x. Christian who tackled the Oracle backend in Icinga Web 1, followed by Jannis who enhanced version 1, created mobile 1 and helped create Icinga Web 2 back then. Scott who joined the Skype sessions from Australia, changing our German project into an English one.

Lara and Wolfgang who tackled the version 1 documentation in docbook xml, making our later decision for Markdown very easy. Christoph who created the first Icinga Core RPM packages, Shawn who tried to bring Icinga packages into EPEL, Sam helping here. Carl who’s been working on Solaris packages for 1.x. Nick and Tom paving the way for the first Puppet module. David who created the first VM appliances. Franz and Mike took care of test scripts, Carlos created the vim/nano syntax highlighting for the Icinga DSL, Jordan who’s been working on Docker containers.

Matthew who created the header status bar for Classic UI, Ricardo who took over improving the old CGIs with many enhancements. Rune who did everything testing and created the term “release fucker” back in the 1.x days – when developers didn’t test enough. Massimo helped with 1.x core issues back then. Alex created and maintained the Debian/Ubuntu packages for many years, Tim who did the same for SuSE. Gerd who worked on Icinga 2 reload and threading techniques. Simon who created the InfluxDB feature for Icinga 2.

Thank you deeply.

Many thanks also to Thomas Krenn who sponsored hardware for the initial build server, JetBrains, Navicat, Atlassian & Activestate for granting us open source project licenses back then.

Bernd, Marius and Julian are the remaining co-founders of Icinga. I was a little late to the party in May 2009, with the rest of us enjoying Icinga with our friends, partners and users every day. You’ll recognize Eric for our technical strategy and everything web and core, Blerim improving and managing all the products, helping partners, maintaining integrations, Tom pushing forward with designs and architecture and the shiny Director, VSphere, etc. modules, Markus taking care of QA, tests and the heavy build infrastructure, followed by Director development lately.

Jean moving along from Icinga 2 core into IcingaDB, followed by Noah with passion for Golang. Our UX designer Florian shaping the web in all its beauty, Johannes taking the lead for Icinga Web and many new modules, followed by Feu with her passion for CSS and better frontend widgets. Alex being the Graphite module developer who recently joined the core devs with the major network stack rewrite, helping my duties on leading the core development whilst sharing all the knowledge with our trainee Henrik. Thomas taking care of Icinga support and improving everything around it. Julia joined for spreading the love on social media and events.

Michael (mcktr) with his passion for the unforeseen Windows issue, Assaf taking care of automation with the official Ansible module, Lennart spreading the love for Puppet while Dirk is our SELinux and RedHat professional. Christian whose day job is in Sales, codes Windows PS at night, sharing his deep knowledge. Lars does a magnificent job on the FreeBSD ports, Matthew dives deep into Gentoo. Bodo is well known for his love for Ruby and Docker containers, appreciated by the community.

Carsten builds awesome Icinga Web modules, Nicolai does so too and jumps right into Director import source development as well. Kevin created a Python API library and knows Ansible&Director, Tobias did so too whilst testing quite a lot. Marianne spreads the Icinga love in her blog, OSMC talks and all over the Internet, even iX articles. Elias analysed, debugged and fixed critical bugs for Icinga 2.11. Virender creating and shaping the Chef cookbook. Our many friends at RedHat helping with the Stackguard Kernel problems.

Timo and Matthias believing in us in trouble times, and letting us test in production, Emanuel who did so too with a large cluster at Contintental. Brad who brought passion and fun from the US, What the Heck from the Netherlands as well. Dave always coming from Australia, and spreading the love (and TimTams). Marcel joining fresh and creating howtos. Jörg who believes in Open Source and still maintains PNP. Michael who develops NSClient++ in his spare time, running on hundreds of thousands Windows clients. Philipp talking things Elastic with Icinga, Jens sharing the love from Müller to the world. Sven & Michael for caring about Livestatus. Moritz spreading the love in Austria at meetups, Bernd taking care of Graylog Vagrant boxes.

Bas maintaining the Icinga packages in Debian. Rico convincing his boss to early adopt Icinga 2. Marco and Max finding all the nasty bugs in larger environments. Claudio creates plugins for ESXI monitoring and shares many howtos. Marc tackles core notifications and Director integrations. Morgan maintains the fancy Grafana notification scripts. Kris thought of the DevOps culture and believes in Icinga. The many of you improving the Icinga Template Library (ITL) commands, sending Graphite templates, documentation updates, issues, pull requests, etc.

Our many friends at customers and users who convince their managers to use and support Icinga. And to share the love – publicly talk about it. Whenever a new Audi or VW is built, Icinga watches. Whenever you buy things online, do bank transactions, go shopping, watch TV, use your mobile phone or enjoy life – Icinga takes care that it works. And when you look up the sky, maybe you can spot the ISS with Icinga exploring space.

There are many more great Icinga users, you know who you are. Thank you from our hearts for an incredible journey.

You know, we are party people celebrating after hard work. Say cheers with your favourite drink, I’ll have – obviously – a G&T.



Icinga in Amsterdam – Icinga Camp and DevOpsDays

Icinga Camp Amsterdam

vagrant_icinga2_dashingWe had a lovely time in Amsterdam meeting great community members on our Icinga Camp. Generously hosted at LeaseWeb and sponsored by OlinData, NETWAYS and Inuits we had a lot of interesting talks and discussions. Pretty much really a full day of monitoring madness connecting with the community. We also had the latest and greatest releases and ideas to share with us. (more…)

Icinga at Flossuk 2015 in York

Last week we visited York in Yorkshire (UK) to join the yearly Flossuk Spring conference. The conference takes place in another city every year which gives us (long time visitors) the chance to discover another city in lovely UK every year.
Most of the conference visitors are coming from the UK and there is faithful group of people coming to every event. We had a chance to talk about Icinga 2 and Icinga Web 2 and gave a demo on our latest versions. You can find our given presentation area.

We would like to say THANK YOU the local organisers for hosting such a fine conference. See you next year!

Icinga 2 release 2.2.0 – Agent, Cli & Apply For Rules

When releasing Icinga 2 in its final version, we got quite a lot of feedback on why there is no agent, and how to monitor remote clients. Back in the beginning of 2014 we already had an idea on how to implement it, but you’d better design, re-design and even re-design such an important feature last. Especially when there are existing solutions out there that users can adopt.

Remote Clients – the “Agent”

icinga2_execute_remote_checksThat is merely the reason why everything took longer than expected. Furthermore, an “agent” is understood quite differently by different users. One thinks of a full-featured Icinga 2 instance with local configuration, local check scheduler and host/service discovery on the master. Others just want to a secure way of executing checks remotely, and drop the old-fashioned insecure NRPE protocol. And yet, users don’t care about their operating system – an agent must run on Linux, Unix – and Windows. Luckily Icinga 2 was designed to work on Windows from conception. Before you continue reading – all the mentioned roles and distributions work and have been implemented in this release 2.2.0 already.

Installation & CLI idea

But there is more – how to safely install that agent? While installing an Icinga 2 (HA) Cluster is relatively easy, it still requires knowledge on SSL certificates and other manual configuration steps. So we noticed that many users struggled with it. And such a thing just for an agent? No, there must be something more simple. In the design and concept phase of the agent bits in Icinga 2, we came up with our very own cli implementation. It supports you by adding setup wizards for master and client nodes, doing all the SSL setup magic. Furthermore, the Icinga 2 cluster protocol was extended to support CSR-Auto-Signing. Simply said – your client nodes can be installed with a single generated ticket number, no need for local SSL certificates.
Going further, remote satellite nodes with their local config will report their objects to the central master. There are cli commands to assist you in adding the nodes, black/whitelisting hosts and services and also generating local configuration on the master. There is plenty of newly written documentation for that, so be sure to check it out. Oh, and if you don’t require that, and just want to execute remote commands – that’s all in there as well.

CLI with Auto-Completion

That cli framewicinga2_cli_command_feature_auto_completionork also supports context based bash auto-completion. We’ve also integrated existing scripts like “feature enable” or “object list” into the cli, and removed the old shell and python scripts. The “python-icinga2” package is gone for that very reason too. Generating your CA and SSL certificates is also supported out of the box. Similar to the agent setup on Linux, the native Windows installer uses the icinga2 cli commands too.

More dynamic configuration with apply for

While this is already one of the most epic things we’ve ever implemented – cli & agent – we did not stop there. Users have been asking, why custom attributes (the vars. identifier) could only hold strings, numbers and boolean values but not arrays or dictionaries. The latter could be used like groups for better apply rules expressions.
So, we added that support, and decided to dump the values as json into the existing backends, adding a new column “is_json” to allow existing interfaces to show that correctly, as seen in Icinga Web 2 already. But we did not stop here – why not extend the existing apply rules to loop over arrays/dictionaries? That way you can save yourself a lot of typing and generate new service apply rules based on host custom attributes. Sounds complicated, but once you’ve tried it, you’ll never want to go back. That gets even more interesting when you generate the host from your CMDB, Puppet, <insert #devops tool here>. It certainly provides an even more dynamic approach. Take a look at the configuration screenshots for the new “apply <objecttype> <optionalprefix> for (key => value in dict)” syntax 🙂
icinga2_custom_dict_arr_attributes_host icinga2_custom_dict_arr_attributes_services icinga2_custom_dict_arr_attributes_icingaweb2

More config magic – apply with variables

Iicinga2_cli_command_object_list_filtern a different situation – back with the agent, and its dependencies, we’ve learnt, that setting local variables in apply rules should be able to read host or service attributes in that scope. For instance, you would want to generate host and service dependencies for your vmware or cloud farm, and set the parent_host_name attribute directly in the child hosts inherited template. No need for duplicate dependency rules – control them using apply and a locally-scoped variable set. You’ll find a more telling example on the doumentation as well, and also that this feature isn’t dependency-exclusive – it can be used for all apply rules.
And while that could become tremendously complicated, the “object list” cli command allows you to filter by name or type wildcard strings. Plus, we’ve worked a lot on possible configuration errors, making them as telling as possible, even for complicated nested apply rules.

More Features: Graphite, GELF

Apart from the core feature set, we noticed at Icinga Camp San Francisco that many already use the GraphiteWriter in production – which is freaking awesome! While chatting with Grant from SpaceX, we’ve also made sure that everyone out there can configure the host and service prefix template, thus adding more statistics and making it more usable afterall. You’ll also recognize the GelfWriter feature, which was contributed by the graylog2 developers and we found it so nice to include it in 2.2. There’s a talk on this years OSMC on that topic, more details once OSMC is over.

Get Icinga 2

Last but not least – thanks everyone for their ongoing feedback. The documentation and also the example configuration has been overhauled in many places. Be it better explanations of apply rules and their expressions in general, or detailed examples on how to use the new apply for rules. We’ve even shipped in an example configuration. The old strategy with single objects just does not work that well now with ever more dynamic apply rules, and only confuses you, the user 😉
The cluster vagrant boxes ship new demo configurations for cluster and remote check execution bits, if you want to give it a try.
Package builds are running, and hopefully everyone gets 2.2.0 asap. While downloading, please be sure to read the Changelog and all the changes introduced with this release. They require your attention! 🙂
As always, thanks for using Icinga 2 and watch out for Icinga Web 2 🙂 Feedback, bugs or feature requests are always welcome!
PS: This video was taken during Icinga 2 development. Get the Windows Agent from packages.icinga.org and try it yourself!


2.2.0 Changelog

For details on the below issues see https://dev.icinga.com/versions/200


  • DB IDO schema update to version `1.12.0`
    • schema files in `lib/db_ido_{mysql,pgsql}/schema` (source)
    • Table `programstatus`: New column `program_version`
    • Table `customvariables` and `customvariablestatus`: New column `is_json` (required for custom attribute array/dictionary support)
  • New features
    • GelfWriter: Logging check results, state changes, notifications to GELF (graylog2, logstash) #7619
    • Agent/Client/Node framework #7249
    • Windows plugins for the client/agent parts #7242 #7243
  • New CLI commands #7245
    • `icinga2 feature {enable,disable}` replaces `icinga2-{enable,disable}-feature` script #7250
    • `icinga2 object list` replaces `icinga2-list-objects` script #7251
    • `icinga2 pki` replaces` icinga2-build-{ca,key}` scripts #7247
    • `icinga2 repository` manages `/etc/icinga2/repository.d` which must be included in `icinga2.conf` #7255
    • `icinga2 node` cli command provides node (master, satellite, agent) setup (wizard) and management functionality #7248
    • `icinga2 daemon` for existing daemon arguments (`-c`, `-C`). Removed `-u` and `-g` parameters in favor of [init.conf](#init-conf).
    • bash auto-completion & terminal colors #7396
  • Configuration
    • Former `localhost` example host is now defined in hosts.conf #7594
    • All example services moved into advanced apply rules in services.conf
    • Updated downtimes configuration example in downtimes.conf #7472
    • Updated notification apply example in notifications.conf #7594
    • Support for object attribute ‘zone’ #7400
    • Support setting object variables in apply rules #7479
    • Support arrays and dictionaries in custom attributes #6544 #7560
    • Add apply for rules for advanced dynamic object generation #7561
    • New attribute `accept_commands` for ApiListener #7559
    • New init.conf file included first containing new constants `RunAsUser` and `RunAsGroup`.
  • Cluster
    • Add CSR Auto-Signing support using generated ticket #7244
    • Allow to execute remote commands on endpoint clients #7559
  • Perfdata
    • PerfdataWriter: Don’t change perfdata, pass through from plugins #7268
    • GraphiteWriter: Add warn/crit/min/max perfdata and downtime_depth stats values #7366 #6946
  • Packages
    • `python-icinga2` package dropped in favor of integrated cli commands #7245
    • Windows Installer for the agent parts #7243

Please remove `conf.d/hosts/localhost*` after verifying your updated configuration!


  • Feature #6544: Support for array in custom variable.
  • Feature #6946: Add downtime depth as statistic metric for GraphiteWriter
  • Feature #7187: Document how to use multiple assign/ignore statements with logical “and” & “or”
  • Feature #7199: Cli commands: add filter capability to ‘object list’
  • Feature #7241: Windows Wizard
  • Feature #7242: Windows plugins
  • Feature #7243: Windows installer
  • Feature #7244: CSR auto-signing
  • Feature #7245: Cli commands
  • Feature #7246: Cli command framework
  • Feature #7247: Cli command: pki
  • Feature #7248: Cli command: Node
  • Feature #7249: Node Repository
  • Feature #7250: Cli command: Feature
  • Feature #7251: Cli command: Object
  • Feature #7252: Cli command: SCM
  • Feature #7253: Cli Commands: Node Repository Blacklist & Whitelist
  • Feature #7254: Documentation: Agent/Satellite Setup
  • Feature #7255: Cli command: Repository
  • Feature #7262: macro processor needs an array printer
  • Feature #7319: Documentation: Add support for locally-scoped variables for host/service in applied Dependency
  • Feature #7334: GraphiteWriter: Add support for customized metric prefix names
  • Feature #7356: Documentation: Cli Commands
  • Feature #7366: GraphiteWriter: Add warn/crit/min/max perfdata values if existing
  • Feature #7370: CLI command: variable
  • Feature #7391: Add program_version column to programstatus table
  • Feature #7396: Implement generic color support for terminals
  • Feature #7400: Remove zone keyword and allow to use object attribute ‘zone’
  • Feature #7415: CLI: List disabled features in feature list too
  • Feature #7421: Add -h next to –help
  • Feature #7423: Cli command: Node Setup
  • Feature #7452: Replace cJSON with a better JSON parser
  • Feature #7465: Cli command: Node Setup Wizard (for Satellites and Agents)
  • Feature #7467: Remove virtual agent name feature for localhost
  • Feature #7472: Update downtimes.conf example config
  • Feature #7478: Documentation: Mention ‘icinga2 object list’ in config validation
  • Feature #7479: Set host/service variable in apply rules
  • Feature #7480: Documentation: Add host/services variables in apply rules
  • Feature #7504: Documentation: Revamp getting started with 1 host and multiple (service) applies
  • Feature #7514: Documentation: Move troubleshooting after the getting started chapter
  • Feature #7524: Documentation: Explain how to manage agent config in central repository
  • Feature #7543: Documentation for arrays & dictionaries in custom attributes and their usage in apply rules for
  • Feature #7559: Execute remote commands on the agent w/o local objects by passing custom attributes
  • Feature #7560: Support dictionaries in custom attributes
  • Feature #7561: Generate objects using apply with foreach in arrays or dictionaries (key => value)
  • Feature #7566: Implement support for arbitrarily complex indexers
  • Feature #7594: Revamp sample configuration: add NodeName host, move services into apply rules schema
  • Feature #7596: Plugin Check Commands: disk is missing ‘-p’, ‘x’ parameter
  • Feature #7619: Add GelfWriter for writing log events to graylog2/logstash
  • Feature #7620: Documentation: Update Icinga Web 2 installation
  • Feature #7622: Icinga 2 should use less RAM
  • Feature #7680: Conditionally enable MySQL and PostgresSQL, add support for FreeBSD and DragonFlyBSD
  • Bug #6547: delaying notifications with times.begin should postpone first notification into that window
  • Bug #7257: default value for “disable_notifications” in service dependencies is set to “false”
  • Bug #7268: Icinga2 changes perfdata order and removes maximum
  • Bug #7272: icinga2 returns exponential perfdata format with check_nt
  • Bug #7275: snmp-load checkcommand has wrong threshold syntax
  • Bug #7276: SLES (Suse Linux Enterprise Server) 11 SP3 package dependency failure
  • Bug #7302: ITL: check_procs and check_http are missing arguments
  • Bug #7324: config parser crashes on unknown attribute in assign
  • Bug #7327: Icinga2 docs: link supported operators from sections about apply rules
  • Bug #7331: Error messages for invalid imports missing
  • Bug #7338: Docs: Default command timeout is 60s not 5m
  • Bug #7339: Importing a CheckCommand in a NotificationCommand results in an exception without stacktrace.
  • Bug #7349: Documentation: Wrong check command for snmp-int(erface)
  • Bug #7351: snmp-load checkcommand has a wrong “-T” param value
  • Bug #7359: Setting snmp_v2 can cause snmp-manubulon-command derived checks to fail
  • Bug #7365: Typo for “HTTP Checks” match in groups.conf
  • Bug #7369: Fix reading perfdata in compat/checkresultreader
  • Bug #7372: custom attribute name ‘type’ causes empty vars dictionary
  • Bug #7373: Wrong usermod command for external command pipe setup
  • Bug #7378: Commands are auto-completed when they shouldn’t be
  • Bug #7379: failed en/disable feature should return error
  • Bug #7380: Debian package root permissions interfere with icinga2 cli commands as icinga user
  • Bug #7392: Schema upgrade files are missing in /usr/share/icinga2-ido-{mysql,pgsql}
  • Bug #7417: CMake warnings on OS X
  • Bug #7428: Documentation: 1-about contribute links to non-existing report a bug howto
  • Bug #7433: Unity build fails on RHEL 5
  • Bug #7446: When replaying logs the secobj attribute is ignored
  • Bug #7473: Performance data via API is broken
  • Bug #7475: can’t assign Service to Host in nested HostGroup
  • Bug #7477: Fix typos and other small corrections in documentation
  • Bug #7482: OnStateLoaded isn’t called for objects which don’t have any state
  • Bug #7483: Hosts/services should not have themselves as parents
  • Bug #7495: Utility::GetFQDN doesn’t work on OS X
  • Bug #7503: Icinga2 fails to start due to configuration errors
  • Bug #7520: Use ScriptVariable::Get for RunAsUser/RunAsGroup
  • Bug #7536: Object list dump erraneously evaluates template definitions
  • Bug #7537: Nesting an object in a template causes the template to become non-abstract
  • Bug #7538: There is no __name available to nested objects
  • Bug #7573: link missing in documentation about livestatus
  • Bug #7577: Invalid checkresult object causes Icinga 2 to crash
  • Bug #7579: only notify users on recovery which have been notified before (not-ok state)
  • Bug #7585: Nested templates do not work (anymore)
  • Bug #7586: Exception when executing check
  • Bug #7597: Compilation Error with boost 1.56 under Windows
  • Bug #7599: Plugin execution on Windows does not work
  • Bug #7617: mkclass crashes when called without arguments
  • Bug #7623: Missing state filter ‘OK’ must not prevent recovery notifications being sent
  • Bug #7624: Installation on Windows fails
  • Bug #7625: IDO module crashes on Windows
  • Bug #7646: Get rid of static boost::mutex variables
  • Bug #7648: Unit tests fail to run
  • Bug #7650: Wrong set of dependency state when a host depends on a service
  • Bug #7681: CreateProcess fails on Windows 7
  • Bug #7688: DebugInfo is missing for nested dictionaries

DevOpsDays London – See you there!

Only a couple of days left, until DevOpsDays London 2013 open their doors. We’ll fly over to London and take the opportunity to participate in their Ignite sessions to present our latest in Icinga development.


This means I’ll have to squeeze everything into 15 x 20 seconds, in a continuous verbal flow! If some of you guys are over there as well, please keep an eye out for Icinga Team shirts 🙂 See you in London
(The tube map is an awesome idea. Thanks to the DevOps guys in London!)