CPU Load Percentages > 100 & < 0

Dear Luke

Spikes can have several causes, most of them are incorrect values returned by the device.

It is possible to filter spikes out and get the graphs back to a reasonable scaling. To do this, please go to the sensor and left-click one of the channels to open its configuration. Please enable the spike filter and enter minimum and/or maximum values.

Not all channels have spike filters. If you have a traffic sensor, the "traffic in" and "traffic out" channels do have a spike filter, but the "traffic total" has not. In this case, "traffic in" and "traffic out" must be configured.

The CPU sensor however also has a spike filter for the "total" channel.

Sorry to drag this up - however I've noticed this occurring quite frequently of late, and performing this spike filtering individually is going to be incredibly time consuming (especially for multi-cored systems).

Is there any way of implementing a global spike filter for sensors that obviously should be impossible to go above 100%? If not - can you add it onto the dev list please!

Dear Chris

I understand that the inconsistent CPU load results are annoying. However, we don't plan to implement a global spike filter setting. Please allow me to explain the reasoning.

Getting too low and/or too high CPU load values is overall a rare issue. Currently we focus on other features, which would benefit a large user base.

If you often get wrong results, the best option is to look for other means to monitor the CPU load. Please try the SNMP CPU load sensor. It perhaps provides more reasonable results. This requires to enable SNMP in Windows by configuring the SNMP service accordingly and allow access from the probe.

I would like to add that I am in the same situation. I'm am monitoring 70+ servers and the majority show percentages greater than 100%. It is definitely not a rare issue for me. Having to configure spike values on all my servers is an absolute pain and should be able to be set globally or from a parent group.

The alternate to configuring SNMP on Windows is an even greater pain.

If it is a known issue with WMI than that should be addressed separately or noted in the sensor.

Dear jcrookslakemac

A logic built into the sensor trying to correct obviously wrong data could lead to other issues. If a device returns false data, but PRTG tries to repair it, a deeper issue with the device would be covered up. While some sensors do include some data correction, we generally follow the philosophy to show what the device returns.

The spike filter can be applied in bulk via multi edit.