Releasing Icinga DB 1.2.0 and Icinga DB Web 1.1.2

by Alvar Penning | Apr 11, 2024

We are excited to release two new versions today: Icinga DB v1.2.0 and Icinga DB Web v1.1.2.

Icinga DB

This release addresses multiple issues related to fault recoveries, with a particular focus on retryable database errors that may occur when using Icinga DB with database clusters.

Since there may be a large number of errors that are resolved by retrying after a certain amount of time, #698 changed the retry behavior to retry every database-related error for five minutes. This helps Icinga DB survive network hiccups or more complicated database situations, such as working with a database cluster.

The latter was specifically addressed in #711 for Galera Clusters on MySQL or MariaDB by configuring wsrep_sync_wait on used database sessions. Galera users should refer to the Configuration documentation for more details.

In summary, the most notable changes are as follows:

Custom Variables: Render large numbers as-is, not using scientific notation. #657
Enhance retries for database errors and other failures for up to five minutes. #693, #698, #739, #740
MySQL/MariaDB: Use strict SQL mode. #699
MySQL/MariaDB Galera Cluster: Set wsrep_sync_wait for cluster-wide causality checks. #711
Don’t crash history sync in the absence of Redis®*. #725
Update dependencies. 27 times

Schema

In addition to mandatory schema upgrades, this release includes an optional upgrade that can be applied subsequently. Details are available in the Upgrading documentation and #656.

All schema changes are listed below:

Allow host and service check attempts >= 256. #656
Composite INDEX for the history table to speed up history view in Icinga DB Web. #686
MySQL/MariaDB: Fix icingadb_schema.timestamp not being Unix time. #700
PostgreSQL: Change get_sla_ok_percent to return decimal numbers in SLA overview. #710

Icinga DB Web

Transporting Commands

Actions are transferred to the Icinga 2 API, as hopefully many of you are aware of. Though, in case Icinga 2 is not able to serve the request, Icinga DB Web uses a different endpoint if configured. This broke in the last release, but is now fixed. It also seems that some of you directly link to such action routes, which we didn’t expect. This caused them to return a JSON response in case of standard HTTP requests. They will respond with HTML again, now.

Broken CommandTransport in cluster mode #950
Directly accessed action routes don’t respond with HTML anymore, but JSON #945

Get What You Want

While we are talking about not wanting JSON as response, it also was difficult for those who wanted it. If there are large amounts of data to be fetched, the response doesn’t end abruptly now since memory consumption is reduced. It also was only possible to get a JSON response by using the format=json query parameter. Now, the Accept HTTP header can also be used if set to application/json.

Unable to get JSON history output #955
Accept: application/json doesn’t give the same result as ?format=json #988

Find What You Like

In case you have searched for objects which should not match a particular custom variable, you might have missed some of the results you expected to find. This was already broken for a long time, so we figure that not many of you regularly use negated searches like that. Or you just didn’t notice, as some results still showed up. So, please don’t be surprised if you now find more results than before. A similar issue happened if you attempted to find objects, that are related to a different object, which you used to filter for. Also with a negated search. If an object was found, that wasn’t related, it still caused a result to not appear. If this sounds complicated, it is. But it’s fixed now.

Host/service filtering != for costumvar not working correctly #865
Filtering services not working as expected #965

Embrace The Future, Still, Please

Some might be somewhat annoyed by the migration widget in the top right. Our goal was to make it useful, not annoying though. But then again, this is only our assumption. We did not hear that many complaints about it, so it cannot be that bad, can it? (Take your chance to unleash your frustration now, we are listening!) The new migration command introduced with v1.1 also did not migrate all URL query parameters correctly. This is fixed now, though if you already migrated, you still have to fix the URLs manually. Sorry for this inconvenience.