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_waitfor 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
INDEXfor the history table to speed up history view in Icinga DB Web. #686 - MySQL/MariaDB: Fix
icingadb_schema.timestampnot being Unix time. #700 - PostgreSQL: Change
get_sla_ok_percentto 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
CommandTransportin 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/jsondoesn’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
!=forcostumvarnot 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.
