How can I change error levels?

And I guess that's the same for an SSH based sensor (i.e. SSH DIsk Free) if it gets an SSH related error (i.e. timeout), right?

It would be good to be able to separate the actual sensor errors from the errors caused by the underlying mechanism used to do the check. For example, it's a different error if PRTG is not able to connect to SSH and a different one if the disk is full, different if PRTG cannot find the IP to PING and if the host is really not answering, and one might want to act accordingly.

Maybe something to consider in the future?

Thanks for the help.

Actually, in the case mentioned, you should get specific error messages that show whether there was a SSH connection issue or if the disk is full, particularly the latter can be defined using limits on the channel values. That said - the connection issue would always be an error, since the sensor cannot connect (which is an error, seeing as nothing can be monitored). If there is a connection, however (as would be the case with the full disk), the error would be specified and this wouldn't be a connection but a limit error (if so defined). But if a sensor cannot connect to the target object, this will yield an error in all cases.

In this case the issue is that I would like an alert to be sent (email, sms, etc) when the Disk is almost full but not if the SSH timed out. If SSH times out it would be more appropriate to mark the status as Unknown, which is actually the case since we don't really know that there's a problem with the Disk itself.

As it is right now PRTG sends alerts for lot's of false positives for Disk usage because for example the server is under load and cannot respond in time.

I guess I have to find another way around these issues then. I still believe that separating these errors to different statuses is a good idea.

Thanks for the help.

I've passed your request on to development for consideration.

Has there been any development in this area?

I have the same criticism of the logic here. Let me explain:

Firstly, in the world of monitoring I think there are two things we need to avoid at all costs, in order of priority:

1. Any situation where an IT system is allowed to fail without the monitoring system alerting anyone. That is obviously very bad.

2. Any situation where the monitoring system creates an alert when the system being monitored is NOT in an error state. i.e. "False Positive".

If false positives become frequent, IT Support staff become 'deaf & blind' to alerts and they start to expect them, and worse still, they start to assume that every alert is "just another false positive". This is super dangerous.

So the problem with a sensor reporting an error state because the sensor itself cannot measure the device, is that this is technically a false positive (if we regard the monitoring system as NOT part of the systems being monitored, which is the case when the monitoring system is not owned by the organisation who's IT systems are being monitored).

So...we would very much like to NOT have PRTG give us an error or warning when we have a problem with WMI or RPC etc. We would prefer to have a different type of error, that could (ideally) be used to fire a different notification, such as sending an email to the engineers that are responsible for PRTG, not those responsible for the device being monitored.

I expect that that other customers will share this viewpoint, and I hope that it will get some attention, because a resolution would help to make PRTG a better product, by making it produce less false positives :)

Thank you!

Matt

Dear Matt

Thank you for your input.

Some months ago, we introduced a setting which allows up to five error states in succession before a sensor switches to alarm state (in the meantime, the sensor goes into the warning state.)

Both channel limits, as well as measuring errors turn a sensor to the alarm state. This is intended as there is something wrong in the network. You can use threshold notifications for sensors to get notified on channel values. However the sensor states are intended to inform you on a different level, they don't discern the reason why a sensor is down.

If you have constant RPC errors, please check the monitored servers, or use a different method of monitoring like SNMP.

We intentionally designed PRTG in a way which makes it hard to hide errors on monitored devices. Please use the sensor error messages to take the according action. We have no plans to offer an option to suppress a sensor error state caused by a WMI/RPC connection issue. If you are flooded by unwanted notifications, please use threshold triggers instead of state triggers.