What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general. You are invited to get involved by asking and answering questions!

Learn more

PRTG Network Monitor

Intuitive to Use. Easy to manage.
300.000 administrators have chosen PRTG to monitor their network. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free Download

Top Tags


View all Tags

Handling spurious zero values for counters

Votes:

0

Your Vote:

Up

Down

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.

counters overflow snmp

Created on Apr 3, 2013 10:08:24 AM by  dorreke (1) 1



1 Reply

Votes:

0

Your Vote:

Up

Down

Please submit a ticket along with the 1 day of raw logs and a screenshot of the graph with the spikes for this issue to [email protected]

You can export 1 days data by going to the historic data tab and selecting a period where you saw this spike and selecting no interval so that it exports the raw data.

Created on Apr 4, 2013 12:23:27 PM by  Greg Campion [Paessler Support]



Please log in or register to enter your reply.


Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.