You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[dev.icinga.com #10497] check_memory and check_swap plugins do unit conversion and rounding before percentage calculations resulting in imprecise percentages
#3571
Assignee: jflach
Status: Resolved (closed on 2016-02-19 10:30:49 +00:00)
Target Version: 2.4.2
Last Update: 2016-02-23 09:58:17 +00:00 (in Redmine)
Icinga Version: 2.3.11
Backport?: Already backported
Include in Changelog: 1
Several check plugins, including check_memory on windows, and check_swap have a programming error in them, causing them to have imprecise percentage calculations, when large units are used.
For example, a server with 8 GB or memory and 1.452 GB free memory should properly be reporting 18.15% free memory, but is actually reporting 1/8 = 12.5% free memory, if the GB unit is used.
On line 206 and 207, printInfo.tRam and printInfo.aRam (which are 64-bit unsigned integers) are populated with total and available RAM measurements, converted into the desired unit, rounded to the nearest whole number, and then stored as an integer.
Later, on line 166, the percentage is then calculated by dividing printInfo.aRam by printInfo.tRam, resulting in the imprecise calculation mentioned earlier.
As a workaround, a unit should be large enough to provide a sufficient amount of digits for a reasonably precise percentage calculation. MB should be fine, GB is not unless you have servers with very large amounts (>100) of RAM. Even then, users should be aware of the limited precision.
As a solution, the code should be updated to perform a percentage calculation prior to rounding of the values in question.
Fixed precision for percentage calculations with large units
The check_memory and check_swap plugins on Windows were incorrectly
rounding the memory/swap measurements to the nearest unit prior to
calculating a percentage. This was causing imprecise percentage
values when the unit selected meant that the values in question had
few significant figures.
fixes #10497
Signed-off-by: Jean Flach <jean-marcel.flach@netways.de>
Fixed precision for percentage calculations with large units
The check_memory and check_swap plugins on Windows were incorrectly
rounding the memory/swap measurements to the nearest unit prior to
calculating a percentage. This was causing imprecise percentage
values when the unit selected meant that the values in question had
few significant figures.
fixes #10497
Signed-off-by: Jean Flach <jean-marcel.flach@netways.de>
The text was updated successfully, but these errors were encountered:
Here's a patch for the issue in question as promised. While making the patch though, I have realised that it's probably a configuration error to have such a large unit configured in the first place, because it means that your performance data is just as truncated, not just the percentage in the check output.
Ah well, at least I figured out how to set up an Icinga2 development environment for next time. :-) I hope the patch fulfills the specs of the project.
This issue has been migrated from Redmine: https://dev.icinga.com/issues/10497
Created by pv2b on 2015-10-30 12:59:57 +00:00
Assignee: jflach
Status: Resolved (closed on 2016-02-19 10:30:49 +00:00)
Target Version: 2.4.2
Last Update: 2016-02-23 09:58:17 +00:00 (in Redmine)
Several check plugins, including check_memory on windows, and check_swap have a programming error in them, causing them to have imprecise percentage calculations, when large units are used.
For example, a server with 8 GB or memory and 1.452 GB free memory should properly be reporting 18.15% free memory, but is actually reporting 1/8 = 12.5% free memory, if the GB unit is used.
Looking at the source file from here as an example: https://github.com/Icinga/icinga2/blob/f7b5aa33ce2672f220ef285b42eaedfa077a71a7/plugins/check\_memory.cpp
On line 206 and 207, printInfo.tRam and printInfo.aRam (which are 64-bit unsigned integers) are populated with total and available RAM measurements, converted into the desired unit, rounded to the nearest whole number, and then stored as an integer.
Later, on line 166, the percentage is then calculated by dividing printInfo.aRam by printInfo.tRam, resulting in the imprecise calculation mentioned earlier.
As a workaround, a unit should be large enough to provide a sufficient amount of digits for a reasonably precise percentage calculation. MB should be fine, GB is not unless you have servers with very large amounts (>100) of RAM. Even then, users should be aware of the limited precision.
As a solution, the code should be updated to perform a percentage calculation prior to rounding of the values in question.
Attachments
Changesets
2016-02-19 10:30:12 +00:00 by pv2b 5c18c1e
2016-02-23 08:47:19 +00:00 by pv2b 30f9a1e
The text was updated successfully, but these errors were encountered: