This plugin provides native CPU instrumentation for monitoring and metrics collection, including: CPU usage and metrics for user, nice, system, idle, iowait, irq, softirq, steal, and guest.
The goal behind this is to provide overall more accurate CPU utilization results. The way we calculate this is to pull the current utilization, sleep n seconds, poll again, and then take a difference between the two numbers. From my tests at my last organization I found that increasing the sleep time gave more accurate overall results. There are several reasons for this but the main reason is that by the very act of calling up the ruby interpreter you are incuring additional cpu utilization. By increasing the poll interval you allow its utilization to even out from the initial load of the interpreter. 5 is by no means a magic number but I found at my previous employer that 5 was a very reasonable compromise for accuracy and still being able to schedule it to see very granular results. The more resource contrained the machine is the more value you will get out of higher sleep/poll values.
This is a breaking change as it updates the defaults and if you are scheduling this more frequently than 10 seconds (and do not set your own sleep value) you could very easily end up with multiple instances of the same check running which would only increase the problem.
From my tests locally I did not notice much difference (about 2-3% inflated) between the data returned from this check and top -d 5 values
Provide a better default that produces smoother metric utilization picture by increasing the poll interval
Known Compatibility Issues
This changes the default poll/sleep value from 1 to 5 if you are scheduling your checks more often than 5 seconds this could make the problem even worst as they could start overlapping because of the scheduling. I find that most people I have seen are checking no more than once every 10 seconds and for those people they should be able to upgrade safely without modification.
majormoses
commented
6 years ago
The goal behind this is to provide overall more accurate CPU utilization results. The way we calculate this is to pull the current utilization, sleep
nseconds, poll again, and then take a difference between the two numbers. From my tests at my last organization I found that increasing the sleep time gave more accurate overall results. There are several reasons for this but the main reason is that by the very act of calling up the ruby interpreter you are incuring additional cpu utilization. By increasing the poll interval you allow its utilization to even out from the initial load of the interpreter.5is by no means a magic number but I found at my previous employer that5was a very reasonable compromise for accuracy and still being able to schedule it to see very granular results. The more resource contrained the machine is the more value you will get out of higher sleep/poll values.This is a breaking change as it updates the defaults and if you are scheduling this more frequently than 10 seconds (and do not set your own sleep value) you could very easily end up with multiple instances of the same check running which would only increase the problem.
From my tests locally I did not notice much difference (about 2-3% inflated) between the data returned from this check and
top -d 5valuesSigned-off-by: Ben Abrams me@benabrams.it
Pull Request Checklist
closes #35
General
[x] Update Changelog following the conventions laid out here
[ ] Update README with any necessary configuration snippets
[ ] Binstubs are created if needed
[x] RuboCop passes
[x] Existing tests pass
Test:
Purpose
Provide a better default that produces smoother metric utilization picture by increasing the poll interval
Known Compatibility Issues
This changes the default poll/sleep value from
1to5if you are scheduling your checks more often than 5 seconds this could make the problem even worst as they could start overlapping because of the scheduling. I find that most people I have seen are checking no more than once every 10 seconds and for those people they should be able to upgrade safely without modification.