Fake Spike in Traffic Sensor

Hi Hossein,

I first recommend to check if you monitor the x64 bit counters or the 32 bit ones. You can see that on the overview page of the sensor on the right side. With this high traffic throughput, 64 bit counters are highly recommended to avoid multiple overflows during a scanning interval.

The traffic sensors calculate delta values from the current results to the result before. There is no known issue with the calculated deltas known in the current version. If you want to calculate them on your own, you can click on the historic data tab of the sensor and export the raw data.

Kind regards,
Felix Saure, Tech Support Team

Hi there, First, I'm using 64 bit counters for SNMP traffic sensor already. Cause it's PRTG built-in sensors! Then, i checked raw data and it shows the same incorrect data also.

Dear Hossein,

PRTG can request 32 bit counters as well as 64 bot counters, that's why asked. As the raw data also shows these spikes, this might be a glitch in the firmware of the device which you monitor. To confirm that, you can use our free SNMP Tester and perform a Scan Interfaces and repeat that. This will show the raw data returned by the device.

In PRTG, you can enter the settings of the channel by clicking on the gauge symbol to enable the Spike Filter. This will filter out such unreasonable values.

Kind regards,
Felix Saure, Tech Support Team

Dear Support Team, How can i check that issue by SNMP Tester while just sometimes occurs and i don't know when?! Also, i want to know that is this OK that i have more than 2000 sensor and i have a lot of 30s interval? Could this be the cause of these bugs?

Hello Hossein,

To catch these sporadic spikes on packet level, you can run a WirShark capture on the probe host, if you use SNMP v1 or SNMP v2. If any spikes in PRTG are captured, you can compare the WireShark results with the results in PRTG. 2,000 sensors in a 30 second interval shouldn't be an issue, there are much larger installations running without such issues. As there are no other similar reports regarding issues with spikes, it's likely that the device reports these wrong values.

Kind regards,
Felix Saure, Tech Support Team

Hi Felix, Although the prtg documentation says that over 2,000 sensors should use 5-minute interval, you still say if, for example, there are 10,000 sensors and assume half of them have 1-minute interval and the other half has 30-second, it will not cause such problems?

Dear Hossein,

Correct, even if performance issues occur on your core server or probes, PRTG will still not write down any random results, just what's getting returned by the devices which are getting monitored.

Kind regards,
Felix Saure, Tech Support Team

As you mentioned above, what about this:

Probe Process CPU Load: This channel shows the CPU load in percent that the probe process causes. Extensive CPU load can lead to false, incomplete, and incorrect monitoring results. This value should usually stay below 50%.

https://www.paessler.com/manuals/prtg/probe_health_sensor

Thanks for your attention.

Hello Hossein,

Thanks for getting back to us. Then distributing the sensors across multiple probes is required, that sensor will inform you when a certain value is exceeded.

The CPU load of course depends on the number of CPU cores and if the host is shared with another application, or if the CPU cores are located on the same socket.

Kind regards,
Felix Saure, Tech Support Team