Knowledge Base

Why do I see Huge Peaks or Spikes in Graphs for SNMP Sensors?

Questa pagina anchora non esiste in Italiano. Confidiamo nella Vs. comprensione.

Sometimes users of PRTG Traffic Grapher report huge peaks in their graphs, especially for SNMP sensors. These spikes can be as large as 10 GBit/s for a sensor that actually monitors a 2 MBit/s connection.

If you find unexplainable spikes like this in graphs of your SNMP Sensors this most commonly has to do with one of two main issues:

a) PRTG Traffic Grapher is correctly reporting a spike
b) PRTG Traffic Grapher is reporting a device error as a spike

To investigate further into the cause you first should to try and find a pattern in the spikes. For example, do they appear roughly at the same intervals or at the same time of each day? When you find a pattern, try finding other monitoring entries on the monitored system that match these patterns. Compare the pattern with processes on your network.

In the past users of PRTG found out that scheduled backups, virus scanner updates, frequent reboots of a system, regular restarts of a specific service, and similar aspects directly or indirectly affected their network and monitored devices. Also a virus/malware outbreak or hacking attempt may cause sudden peaks. In all these cases the peaks reported by PRTG were completely correct.

If you can't find a cause like this in your network it may also be a device error or a bug in the firmware/software. Try finding information on this on the web. Maybe a firmware update is available.

Bear in mind that the main cause for erroneous peaks are so-called counter overflows.

Here is some technical background:

  • Most SNMP devices use 32-bit counters to count the number of bytes transferred via a data line. Depending on the bandwidth usage the values at some point in time will reach the 32-bit barrier.
  • For a correct overflow a counter reaches the maximum value (2^32) and continues counting from 0. PRTG detects this behaviour and calculates the actual traffic in the overflow interval (2^32 - last value + current value).
  • If the device malfunctions the counter may be reset to 0 without reaching the maximum. PRTG interprets this as a counter overflow and will calculate a value which is much too high. A huge spike is shown in the graph.
  • There is one special situation: In case of a system reset the counter is usually also reset to 0. But this case can be detected by PRTG using the system uptime reading.
  • If there is no uptime reading available on the device or the counter reset without a reboot (which should not happen based on the official SNMP specifications) the incorrect peak simply can not be detected by PRTG.

For devices with one of the limitations mentioned above you can activate the "Ignore Overflow Value" option or you can activate the Spike Filter in the sensor settings (see below).

But: We do not recommend removing peaks using PRTGs filtering mechanism if you are not certain that a buggy device is the reason for the peaks. Otherwise you are filtering out real data that may be important for your monitoring data analysis.

You have two options as regards removing peaks:

First, you can try the "High Compatibility Mode" found on the "Tweaks" page of the options dialog (Extras|Options) (under the Advanced options you will find the previously mentioned Ignore Overflow Value). This mainly removes peaks caused by device errors and by restarting / rebooting the system

If that does not help, you can remove any peaks (including historic ones) using the Spike Filter in the sensor options. The value entered here is represented in the "raw" unit monitored by the SNMP sensor. For traffic sensors this is always bytes independent of the unit setting.

By Category

PRTG Traffic Grapher V6

Related Articles