Releasing Icinga 2.14 and 2.13.8

We are happy to announce the release of Icinga 2.14.0 and 2.13.8 today. Especially the 2.14.0 release comes with a lot of fixes and improvements and this blog post will highlight the most important ones. There are some breaking changes in 2.14.0, so please make sure to read the corresponding section before upgrading.

Features

Faster Config Loading

We put a lot of effort into reducing the time and resources needed for loading the configuration in large setups. Cutting the config load time in half compared to previous releases is realistic, though it is hard to predict the exact impact on a particular installation as this is heavily influenced by the structure of the configuration.

This improvement comes with a few user-visible changes. One such change is that using the icinga2 object list command now requires manually running icinga2 daemon --validate --dump-objects first. This generates a cache file that was previously written each time a config is loaded, taking considerable resources to do so. If an outdated file is present, a warning is displayed with instructions on how to generate an up-to-date one. Additionally, some constructs in the configuration we don’t expect to be used commonly are no longer allowed as this made room for more optimizations. What exactly is affected is included in the list of breaking changes.

Icinga for Windows Checks via API

Icinga for Windows already provides its own REST API which can be used to execute checks. This is done to avoid loading a PowerShell process for every single check execution. With Icinga 2.14, it is now possible to run checks by using that API natively from the Icinga 2 process, resulting in faster check execution times and less CPU usage.

To use this feature to its full extent, changes in other components are required. These are planned to be included in the upcoming Icinga for Windows 1.11 and Icinga Director 1.11 releases.

Redundancy Groups for Dependencies

It’s now possible to define multiple independent dependencies that are each provided in a redundant way. This is achieved by the new redundancy_group attribute for dependencies: if two or more dependencies are placed into the same redundancy group, the dependency is treated as being available as long as at least one of the parents is available. For example, for a service that needs DNS and a database to function properly, you can now create multiple dependencies with redundancy_group = "dns" for multiple DNS servers and multiple dependencies with redundancy_group = "database" for the servers in a redundant database cluster.

Breaking Changes

• ElasticsearchWriter now requires at least Elasticsearch 7.x in order to also support Elasticsearch 8.x.
• Redundant dependencies now have to be configured explicitly using the new redundancy_group attribute.
• Using icinga2 object list now requires manually calling icinga2 daemon --validate --dump-objects beforehand.
• Dependency cycles are now detected and rejected during config validation instead of during check execution.
• Global variables can no longer be modified from within object/apply blocks or within functions/lambdas that are executed there or later at runtime.
• The empty string can no longer be used as an object name and the groups attribute of Host, Service, and User objects can only contain strings now. Doing so resulted in inconsistent behavior before.
• CheckResultReader and StatusDataWriter were removed, both were deprecated since Icinga 2.9.
• The MSI packages for Windows no longer include the bundled NSClient++ installer, the performance data writers and the Icinga 2 documentation, reducing their size by 75%.
• The default email notification scripts installed to /etc/icinga2/scripts/ now link to Icinga DB Web instead of the old IDO monitoring module.
• The API no longer returns TicketSalt in /v1/variables.

Bugfixes

The most important bugfixes in the 2.14 release are:

• Icinga DB: normalize several values written to Redis to prevent the Icinga DB daemon from crashing.
• Fixed an issue where a connection was not terminated properly after reaching a timeout and Icinga failed to reconnect to another node.
• Flexible downtimes no longer end too early when added on a host or service that already is in a problem state.
• Fix lost acknowledgement comments after processing the replay log.
• The API now rejects config modifications during reload with HTTP status 503. Previously, such modifications were accepted by the API but not applied properly.
• Fix parsing of performance data that is split across multiple lines in the plugin output.
• The built-in icinga check now also reports reload failures on Linux.
• Downtime end notifications are no longer delayed by up to a minute.

And much more

The lists above are not exhaustive and there are many more changes. For example, we also updates our dependencies, which includes switching to OpenSSL 3.0 for our Windows builds as the version used so far will reach its end of support later this year. For more, please check out the full changelog for Icinga 2.14.0 and the upgrading docs.

Icinga 2.13.8

At the same time, we also publish a new bugfix release for Icinga 2.13 which provides some of the fixes included in 2.14 as well. For all the details, please check out the full changelog for Icinga 2.13.8.