-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Interval weirdness #61
Comments
yeah - thanks for the headsup @axrayn, definitely something to improve. A quick simple change could be as you noted to use:
and if sleep < 0 then issue a waning log about it. WDYT? |
Sounds good, with an absolute floor of 0 so Stud doesn't complain about a negative? |
Yup, and as noted above, issue a warning log about it so that the user will know if the polling job regularly exceeds the sleep time. |
Any updates on this? I'm having the issue where there are gaps in my graphs because I set the interval for 60 seconds, but in reality it's |
Hi @colinsurprenant , I am facing the same issue. please help me resolve this.... |
Attempt to adhere to the interval, regardless of how long execution takes. After executing, sleep off only the _remainder_ of the interval (if any), and log a helpful warning when execution takes longer than the interval. Resolves: logstash-plugins#61
* interval: only sleep off remainder Attempt to adhere to the interval, regardless of how long execution takes. After executing, sleep off only the _remainder_ of the interval (if any), and log a helpful warning when execution takes longer than the interval. Resolves: #61
This will probably be a lot better once we go from single-threaded to multi-threaded but I noticed today that the 'interval' counter only starts when all device polls have completed (either responded or timed out) rather than starting again every 'interval' e.g. START - WORK - FINISH - SLEEP FOR INTERVAL (then repeat)
This means that if you have 100 devices in your hosts list that for the sake of argument all take 1 second to respond and you have a interval of '300', your polling cycles will be every 400 seconds not every 300 seconds. Once you start incurring more penalties through timeouts, your polling cycle can blow out substantially.
I noticed it today with a list of 30 routers, of which 16 weren't responding (firewall rules blocking) so my polling cycles were running an extra ~50 seconds slower and therefore meant graphs set with a 5m interval were progressively not working.
It may just end up being something to note in the docs that this is the expected behaviour and that users will need to use multiple inputs to spread out the number of devices to compensate for this.
The text was updated successfully, but these errors were encountered: