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
In order to deal with overflown octet in/out counters, the plugin checks if the counters that were currently retrieved from the device have a value lower than the ones stored in the file from the previous run(s).
But the same thing will happen (i.e. retrieved counters are lower than previously stored ones) in case of a device reboot. So the plugin will assume a reset of the counters as an overflow and will report erroneous interface utilization (way over 100%). In case warning/critical thresholds have been specified, the plugin will also report warning/critical result.
Obviously the best way to solve this would be to introduce an extra check for the device uptime.
A good workaround though, that requires much less changes in the plugin code, is to check if both octet-in and -out counters have "overflown" at the same run.
It is extremely rare that a simultaneous in/out counter overflown would have happened in real world interface traffic conditions, so I think this workaround is a pretty safe to assume.
If you agree I can create a pull request that implements this workaround.
Thank you.
The text was updated successfully, but these errors were encountered:
In order to deal with overflown octet in/out counters, the plugin checks if the counters that were currently retrieved from the device have a value lower than the ones stored in the file from the previous run(s).
But the same thing will happen (i.e. retrieved counters are lower than previously stored ones) in case of a device reboot. So the plugin will assume a reset of the counters as an overflow and will report erroneous interface utilization (way over 100%). In case warning/critical thresholds have been specified, the plugin will also report warning/critical result.
Obviously the best way to solve this would be to introduce an extra check for the device uptime.
A good workaround though, that requires much less changes in the plugin code, is to check if both octet-in and -out counters have "overflown" at the same run.
It is extremely rare that a simultaneous in/out counter overflown would have happened in real world interface traffic conditions, so I think this workaround is a pretty safe to assume.
If you agree I can create a pull request that implements this workaround.
Thank you.
The text was updated successfully, but these errors were encountered: