I have a switch that is occasionally returning a zero value for the ifOutDiscards counter. I believe this is a bug in the switch. PRTG does have a workaround to handle such situations, but PRTG's workaround seems to be not ideal.
The problem with these zero values is that PRTG takes a delta on each polling interval. This, suppose the discards counter were 6000 and not currently increasing. Successive polls might give, for example, 6000, 6000, 0, 6000, 6000. If these are taken at face value, the deltas would be 0, 0, -6000, +6000, 0. The -6000 would be taken as an enormous positive number 4294961296. However, PRTG has the option "Ignore overflow values", which correctly renders the enormous delta as zero.
However, a problem occurs on the next delta. Rather than ignoring the spurious zero value, it seems that PRTG has actually records it, and uses it as a basis for the next delta. Therefore, the next delta seems to be +6000, which is also wrong. We therefore see spikes on the discards graph ... not enormous spikes, but nevertheless spikes, and all of the same height corresponding to the actual value of ifOutDiscards.
At first sight, the option "Ignore zero values for delta sensors" would appear to be designed to solve this, but it does seem to work. Sure it ignores the zero value on the falling edge, but it seems that PRTG still records the zero value as a basis for the next poll.
Could you please suggest how to handle this situation in PRTG. (I am also raising a case at Cisco TAC for the original zero-value problem.)
The logical behaviour of PRTG shurely should be that if a counter returns zero (and therefore appears to have overflowed), and the previous value was less than 2^31, then not to record the zero value as a basis for the next delta, but to keep the previous value.
Thanks in advance.
Add comment