Today we are happy to announce that after many delays, re-writes, pushbacks and restructuring Icinga for Windows v1.11.0 is finally released! First, we would like to thank everyone for contributing feedback over the past month to track down issues and testing new integrations.
While Icinga for Windows v1.11.0 is not shipping everything we wanted to include in this release, we made great progress to rework some underlining code and enhance the user experience in certain areas, while also implementing some new features. At this point the Icinga for Windows team would like to give a shoutout to the Icinga Core developers, who did a fantastic job implementing a cool new feature to Icinga 2.14, which will directly work hand-in-hand with Icinga for Windows – more on that later!
Whats new in v1.11.0
Like always, you can view the list of changes directly inside the changelog, but here are the most important ones:
Bugfixes
- Fixes services filters to properly handle excludes while using wildcards
- Sync-IcingaRepository will now properly save the SSH user and hostname while using SCP sync to a Linux host
- Framework migration tasks will now check the version of the current used Framework version and apply possible pending migrations exactly for this installation instead of throwing an exception in case multiple framework verisons were found
- The argument -ThresholdInterval is now working properly on older Windows machines (Windows 2012 R2) and also no longer invalidates switch arguments like -NoPerfData
- The REST-Api endpoint checker will now always return properly formatted check-result objects as well accepts arguments on POST requests with and without leading “–“
- Fixes a huge memory leak within the REST-Api handler
Features/Optimizations
- You can now configure the Director JSON-Object used for registering hosts with the Director Self-Service API to modify IP address and host display name
- The name of the created/synced repository is now stored within the ifw.repo.json file
- Using -RebuildCache on the icinga command will now run for the Framework as well as all installed components, to ensure everything is rebuild at once
- Added a new secure way to interpret enum data from Icinga providers, ensuring there is always a fallback in case of strange outputs (fixes disk health and Hyper-V plugin results)
- Service users can now be submitted as user@domain as well as domain/user
- Write-IcingaAgentApiConfig now supports a cipher list as argument for setting up the Icinga API
- Both, icinga and Install-Icinga command now support the -NoSSLValidation flag and set the proper TLS version for communication – this makes installations in self-signed environments more straight forward
- New-/Update-/Sync-IcingaRepository now provide a progress bar telling how many files have been downloaded/progresses while the SCP version now prints the SCP upload progress as text output
- Update-Icinga now supports the -Version flag to update/downgrade to specific versions [log1-c]
Is that all?
We have some more things we would like to talk about. At first, we have started to prepare Icinga for Windows on how we want to work with plugins in the future. Currently, the component collections like plugins will ship not only the actual plugin, but certain data providers as well, which plugins will make use of. For the CPU plugin, we have now started to move the data provider from the plugin repository for the Framework itself. This is a first step on future changes, to centralize core data information for Windows, MSSQL, Hyper-V, and so on directly inside the Framework, allowing the reduction of dependencies required for other modules. In addition, the new global structure of the dataset will improve performance and allow for some cool other things we have planned for v1.12.0 and beyond. Stay tuned for that!
Improved CPU plugin
While we improved the data provider for the CPU plugin, as also implemented a breaking change on the plugin. While the update will be fine and will not require a user action, the metrics collected have moved to a different Performance Counter. Instead of using % Processor Time, we now use % Processor Utility. This change allows us to stay closer to performance metrics reported by the Windows Task-Manager, as well as allow the native split of the available processor information in the sockets and NUMA nodes.
While the new version of the plugin does all Total calculation by itself, data is no longer distinguished on single core systems where load of core 0 and core Total did not match. in addition, you can not only filter the monitoring for specific sockets but also only change the plugin behavior to compare your thresholds against the Overvall Load only, instead of all cores. This allows for metric collection of each single core, while keeping alerts to a minimum.
Improvements to Hyper-V (released later)
While we also did some changes to the Hyper-V monitoring to not only include blackout time monitoring for the VMHealth plugin, we also added support to check for duplicate virtual machines with a cluster/single node environment with a new plugin Invoke-IcingaCheckHyperVDuplicateVM.
In addition to these two extensions, it is also possible to monitor the node count of a cluster with the HyperVHealth plugin.
All these changes will not be available right away, as we will postpone the release of the Hyper-V plugins by a couple more days two tweak certain threshold and configuration metrics. Stay tuned for the next days!
Other plugin collections
While Hyper-V is still postponed, we have released new versions for MSSQL– and Cluster-Plugins in the meantime. There is only one fix available within the cluster plugins, which resolves an issue on fetching volumes because of a misplaced logic (Thanks PatrickHees for the fix!)
The biggest change of both plugin collections is caused by a new Icinga Director basket and Icinga configuration shipped with the release, which is required for a cool new Icinga 2.14 feature!
Let’s talk API!
As you might have already read in Julians blogpost regarding the 2.14.0 release, the Icinga Core team (thanks again!) added an amazing new feature which now allows the Icinga Agent to natively communicate with the Icinga for Windows REST-Api!
By doing so, Icinga will no longer require forking a PowerShell process for every single check executed. Instead, the Icinga Agent will do a curl-like request towards the Icinga for Windows checker endpoint over the REST-Api, submit a check-execution and receive a check-result object in return. All in-memory without new processes being spawned.
Positive side effects
Not only is this a huge performance boost for Icinga for Windows directly, but also solves an issue where people might click on “Check Now” within the Icinga Web multiple times, hoping to speed up the metric collection. While Icinga will still try to execute all checks scheduled, the Icinga for Windows API design allows by default only 5 concurrent checks being executed. All other checks are pending and waiting for a slot within the API to become free. As no additional process has to be spawned, the CPU using during this time is limited to everything the API has to offer, keeping the machine healthy and relaxed, while still providing check results and metrics faster than ever!
How to setup
We have written a very detailed documentation section for the requirements of this feature and how to setup everything properly for both, Icinga Director and plain Icinga config users. The easiest way for enabling this feature would be to update every single Icinga component (Master/Satellite/Agent) to v2.14.0.
While this in theory sounds great, the reality kicks in and we probably have to run a multi-version environment. To summarize the documentation, here is what you need:
- Icinga 2.14.0 on the master(s)
- Icinga Director v1.11.0 (or the current master, as the release is still pending)
- The latest Icinga for Windows v1.11.0 configuration installed (Director Baskets or plain Icinga conf)
Icinga Director
With these basic requirements, we can start to configure our environment. For Icinga Director users, we have to run the Kickstart-Wizard first after upgrading the masters to 2.14.0, to import a new CheckCommand ifw-api into our system.
You can now use this CheckCommand as import source for your PowerShell Base CheckCommand provided by Icinga for Windows.
Once completed, deploy your Icinga configuration and the feature is done.
!!! It is very important to update to Icinga Director v1.11.0 (or the current master) BEFORE deploying this change, as all your Icinga systems NOT running v2.14.0 will no longer be able to validate the configuration, because they will lack the CheckCommand ifw-api !!!
Plain Icinga Config
For those not using the Icinga Director, some similar steps apply. You will require to update to v2.14.0 on your masters and update the Icinga for Windows configuration files for all plugins, which were shipped with the latest release of each repository.
Now you have to modify the PowerShell Base CheckCommand to import the ifw-api CheckCommand as well:
object CheckCommand "PowerShell Base" {
import "plugin-check-command"
import "ifw-api"
...
Now we are almost done, but we also require making one additional change BEFORE deploying this configuration, to not break our Icinga components not running v2.14.0.
For all the older Icinga installations to not break, we require to deploy a dummy CheckCommand for ifw-api, ensuring older versions will not fail but newer versions will not load this dummy object. Use one of your global-zones you deploy to ALL of your machines and add the following Checkcommand:
if (! globals.System || ! System.get_template || ! get_template(CheckCommand, "ifw-api-check-command")) {
object CheckCommand "ifw-api" {
import "plugin-check-command"
}
}
This might look weird but will ensure that older Icinga binaries will load this command while still maintaining a huge backwards capability, and all newer Icinga binaries will ignore the command and use the ifw-api command shipped with it.
Success
Once you have made the above changes, you are running in a hybrid mode, while all Agents running v2.14.0 and later will talk natively to the Icinga for Windows API and older versions still use the PowerShell to call the API, ensuring you have enough time to upgrade your entire infrastructure.
You can check on the Inspect Button in Icinga Web if the command is running with the latest version:
Next Steps
We are incredibly happy to finally be able to share the latest version with you and the new, awesome API feature. We can’t wait to hear your feedback on this and how it changes your monitoring landscape!
Of course, we will not stop here, as we are already in full development of Icinga for Windows v1.12.0 with additional improvements and many more performance optimizations on the horizon. The Age of PowerShell is truly amazing!
We hope you enjoy this release – have a wonderful time and stay tuned for more, amazing updates!
