Is it possible to inherit a sensor status after a pause? The issue was are having specifically is that if something is "down" and sends an alert, then it is paused, then it is resumed, if it is still in "down" it sends a new alert.
In our specific case, we are monitoring ESXi datastore usage. The sensor alerts because there is not enough free space, and then we pause that sensor to mark it as acknowledge and begin to work the issue. During that time, if a dependency causes this sensor to pause (example: internet outage causes all sensors in the LAN to pause), when that dependency causes the sensor to resume it sends a new alert, then it goes back to a paused state. So in-between it being paused for the dependency and then it setting itself as paused because it was acknowledged, there is a brief moment where the sensor is not paused, which causes it to send an alert.
Is there a way to avoid this?
Article Comments
To answer my own question, I found out that this is actually incorrect. I was working off some information from a co-worker and when I tested it further it looks like the pause does keep. The issue he was having is that the sensor was not paused at all, and it re-alerted after the pause by dependency cleared. That is not the end of the world to us and I would say is probably a good default setting. Our process will be to acknowledge and pause these sensors, hopefully eliminating any re-alerts.
Feb, 2014 - Permalink
Hello,
thank you very much for your KB-Post. I'm afraid this can't be changed though (in a manner of setting or configuration as a user). The only way to change this would be changing the code of PRTG, which in this case we don't really want to do. The handling of sensor states, and foremost, their possible transitions from one state into another (it's a huge matrix already), make a very complex part of PRTG's code. It's one of the most important parts of PRTG and we only want to change it, when it's really necessary, and many users benefit largely from the change.
A remembered state or inherited state would make the code much more complex, and also understanding (as a user, and for us in supporting cases) certain transitions much harder.
Agreed, such notifications can be a bit annoying, but the current "procedure" also is a very clear principle (for years actually), to which users are "used to". After a pause a sensor is expected to perform a scan, new scan. A pause is, in many ways (technically, internally, and also "philosophically" for us) like a reset for an object in PRTG. It will then scan anew, and in this case go into a new error state.
best regards.
Feb, 2014 - Permalink