This adds new and improved handling for Metrics over Time.
The overall execution time for the background tasks has been reduced, while also the memory management is way more efficient.
In addition to the improved core handling of the feature, performance metrics for metrics over time will NO LONGER BE WRITTEN.
This will increase the performance of the graphing solutions like InfluxDB a lot, while the monitoring by using the "-ThresholdInterval" argument is still possible.
```powershell
PS> Invoke-IcingaCheckCPU -Warning '5%' -ThresholdInterval '10m';
[WARNING] CPU Load [WARNING] Overall Load, Socket #0
\_ [WARNING] Overall Load: Value 6.546175% is greater than threshold 5% (10m Avg.)
\_ [WARNING] Socket #0
\_ [WARNING] Core 0: Value 18.391566% is greater than threshold 5% (10m Avg.)
\_ [WARNING] Core 1: Value 14.100505% is greater than threshold 5% (10m Avg.)
\_ [WARNING] Core Total: Value 6.546175% is greater than threshold 5% (10m Avg.)
| totalload::ifw_cpu::load=5.804053;5;;0;100 0_0::ifw_cpu::load=18.03764;5;;0;100 0_1::ifw_cpu::load=9.36611;5;;0;100 0_2::ifw_cpu::load=5.830669;5;;0;100 0_3::ifw_cpu::load=0.646737;5;;0;100 0_4::ifw_cpu::load=0.926955;5;;0;100 0_5::ifw_cpu::load=0.016205;5;;0;100 0_total::ifw_cpu::load=5.804053;5;;0;100
```
* Set maximum cache duration for service daemons to the right value
This commit sets the maximum duration for cached data for service
daemons to the proper amount.
Previously it was multiplied by 60, probably a typo from a time
when the assigned value was in minutes and not in seconds directly.
Therefore the value was 60 times to high which leads to a massive amount
of cached data which drags down the performance significantly.
* Updates changelog
---------
Co-authored-by: Lord Hepipud <contact@lordhepipud.de>
The former implementation had 5 threads permanently spinning fast
(10ms sleep) while waiting for a REST connection to process.
This causes higher load in general and it breaks systems where
"Turn on PowerShell Script Block Logging policy" is enabled,
because then each PS statement including Start-Sleep is logged -
resulting in 500 event log entries per second. It's a suggested
setting in some hardening guidelines.
We can easily replace the Queue with a BlockingCollection backed
by a ConcurrentQueue, which has the built-in feature to sleep until
there are new items. Now the REST API threads consumes zero CPU time
while waiting.
Fixes#20
This fixes the memory leak on the Service Check Background Daemon, mainly caused by not properly catching the boolean return values of `Add-IcingaHashtableItem`. The boolean values stayed within the scope, poluting the memory and causing functions to behave not as expected
