...
The OIDs that are being queried for interface throughput calculation can be 32-bit or 64-bit. While it is more likely for a 32-bit counter to overflow, 64-bit counters can also overflow. The result of such an overflow is with utmost certainty a off throughput calculation.
Original text:
As there is no direct possibility to poll bandwidth data from, e.g., a switch, the calculation of the bandwidth is basically like this:
(B(t_2) - B(t_1)) / (t_2 - t_1) |
Where t_2 > t_1 are points in time, and B(t) is the total amount of bytes (octets) passed by an interface, starting from 0 when the device boots.
...
The counter B may have some delay in getting the current value, as there might be high traffic on the interface and counters not being updated instantaneously. This systematic error tends to compensate by difference calculation roughly, thus, B_error is taken to be minor for the moment.
The counter for the amount of bytes can be 32-bit or 64-bit sized. Having the smaller counters, you risk encountering a counter overflow. The bigger the polling interval, the higher this risk; thus, you should remain at 1 min whenever possible, also for other reasons. With the increasing development of Checkmk, measures have been implemented to detect and compensate counter overflow, which nevertheless will not be perfect.
...
For debugging this further, two SNMP walks or agent outputs are necessary, together with the service graphs of the Checkmk site. Unfortunately, you will not have the measurement data available that caused the strange graph display, thus only rough testing is possible here. Usually, at the end of debugging, there will be plausible reasons for t_error.
Related articles
| Filter by label (Content by label) | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...