Closed axrayn closed 3 years ago
yeah - thanks for the headsup @axrayn, definitely something to improve.
A quick simple change could be as you noted to use:
sleep = (interval - (stop_time - start_time))
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 interval
+ time to poll, and it's kinda random. I'm only polling for one host, it's a Cisco Nexus switch with hundreds of interfaces, so polling for 60 seconds interval is actually around 70...
Hi @colinsurprenant , I am facing the same issue. please help me resolve this....
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.