We are getting repeat notifications even when this is not setup in the notification.
We have a device with a ping sensor that went down. The probe that device was on had some brief connectivity issue and each time the probe came back online, the sensor that was down sent another alert.
We understand a probe can go lose connectivity now and then, but if the sensor was already down, and we don't have repeat notifications setup, we don't want another notification.
Let me know if you want a support bundle sent in to take a look.
a brief look at the sensor log is here: http://postimg.org/image/ru5nq86v5/
Article Comments
I believe it would be a desired feature to at least be able to enable this as an option for a device/sensor - that is, if the previous state was DOWN and then goes to UNKNOWN and then back to DOWN, don't send a new notification, unless of course one has repeat notifications enabled.
Jun, 2014 - Permalink
I will put it on the wish list, but I'm afraid such a condition would be very complex to implement (into an already very complex code). Additionally there would probably be dozens of other combinations then requested by other users, which would make the interface and code even more complex. So it's not very likely that this will be implemented to be honest.
Jun, 2014 - Permalink
I have been seeing a few sensors repeat notifications recently, and it doesn't appear that the Device is pausing nor the probe going offline. I suspect it's a timeout of some sort, but don't see that in the log for the sensor or device.
6/26/2014 6:33:01 AM Disk Free Notification Info State Trigger activated (Sensor/Source/ID: 14806/15621/2) 6/26/2014 4:27:00 AM Disk Free Notification Info State Trigger activated (Sensor/Source/ID: 14806/15621/2) 6/26/2014 1:45:00 AM Disk Free Notification Info State Trigger activated (Sensor/Source/ID: 14806/15621/2) 6/25/2014 11:56:00 PM Disk Free Notification Info State Trigger activated (Sensor/Source/ID: 14806/15621/2) 6/25/2014 11:19:01 PM Disk Free Notification Info State Trigger activated (Sensor/Source/ID: 14806/15621/2) 6/25/2014 10:44:01 PM Disk Free Notification Info State Trigger activated (Sensor/Source/ID: 14806/15621/2) 6/25/2014 10:07:01 PM Disk Free Notification Info State Trigger activated (Sensor/Source/ID: 14806/15621/2) 6/25/2014 7:13:00 AM Disk Free Notification Info State Trigger activated (Sensor/Source/ID: 14806/15621/2) 6/24/2014 4:02:18 PM Disk Free Warning 9 % (Free Space D:) is below the warning limit of 10 %
Jun, 2014 - Permalink
Are you sure these were not disconnects of the Probe? Did you check the Probe Log? Also, what is the exact trigger definition on this sensor?
Jun, 2014 - Permalink
I was expecting to see the Probe showing down/up or disconnected, but do not see that in the Logs | System Events | Probe Related. I have seen this happen before, so that was why I expected to see it, odd that I don't see it showing the probe disconnected. Maybe I'll go look at the actual probe log on that probe.
The trigger is a Library defined one with no repeat defined.
Jun, 2014 - Permalink
Sensor remains in the Down state currently and shows no indication that it is changing status or going to Unknown.
When sensor is Warning for at least 125 seconds perform Email-Group
When condition continues for at least 300 seconds perform no notification and repeat every 0 minutes
When condition clears perform Email-Group
When sensor is Down for at least 125 seconds perform Email-Group
When condition continues for at least 300 seconds perform no notification and repeat every 0 minutes
When condition clears perform Email-Group
Jun, 2014 - Permalink
What are the definitions on the Library? Could it be that the sensor was moved out and into the Library at those times the notifications were triggered?
Jun, 2014 - Permalink
The library definition is:
Linked Object: Root Filter By Type: PING, WMI Free Disk Space (Multi Disk), WMI Memory Filter By Tags: (a single tag defined on the parent group)
I have verified the parent group isn't going into a Paused state, nor is the parent probe.
Jun, 2014 - Permalink
Can you please upload some screenshots showing the settings of the library node? Thank you.
Jun, 2014 - Permalink
Screen shot http://postimg.org/image/o97ofsmhz/ - let me know if you need something specific.
I may try making the linked object the parent probe instead of "root", just to see if there is any change.
Jun, 2014 - Permalink
Let me know if you need an additional screen shot: http://postimg.org/image/8jqfhdmo7/
Jul, 2014 - Permalink
If the alerts were not caused by the Probe being disconnected, it has to be that the sensor went in & out of the Library. Maybe to to changes with the Tags, or changes to the Library itself. That would be the only possible reason left.
Jul, 2014 - Permalink
Linking the parent probe or group instead of "root" hasn't helped. Yes, I agree it seems like something is taking in/out of the Library, but what? I'd really hate to have to manually pick all the items in each of my 30+ libraries to make them hard coded instead of via tags and sensor types.
Jul, 2014 - Permalink
Hello,
I'm very much afraid when a Probe disconnects, then the sensors underneath this Probe will change their state to unknown for the time the Probe is disconnected. This is because in this very moment, the PRTG Core Server has no information what-so-ever about the states of those sensors. But this also re-triggers the notifications. I'm very much afraid this cannot be avoided.
best regards.
Jun, 2014 - Permalink