Is it possible to move acknowledged alerts back to the down queue?

Hi leeball,

Once a 'Down' sensor is acknowledged, it changes its state to 'Down (Acknowledged)' (see: Sensor States) and stays as long as necessary in this particular state. The sensor scans are processed according to their set scanning intervals but the sensor does not change its state as long as the target device does not respond in a different way.
As soon as the targeted device responds differently (for instance a former timeout is now a broken disk) the sensor will display this.

I don't comprehend your last section, would you please elaborate this more in detail?

Best,
Sebastian

Thanks for the information, sadly that sounds as I thought.

My last section is an explanation of my workflow. On the servers in question they return the number of currently outstanding updates, so for example lets say my servers all have an update released on Monday, just one.

I review that update and decide that it's not so important it needs to be installed right away, and I acknowledge the "Down" alert for a week.

On the Wednesday, another important update is released for those servers, changing the originally returned value of 1 on the Monday to 2 on the Wednesday. What I would like is to be prompted that the "Last Value" has changed from 1 to 2 despite the fact that I'd previously acknowledged the alert.

Does that make sense? Rather than being told after a week that the sensor is still down, I'd like to be told that halfway through that week the value returned changed and I should probably check it again.

Hi there,

Thank you very much for the information.

It took me a while to realize to which sensor you refer. But I'm afraid that I have to confirm your assumption. If the sensor is already 'down' or 'down (acknowledged)', the state won't change if the last value changes from 1 to 2.

Best,
Sebastian

Thanks for the confirmation, that's a shame. I think the only way to achieve this would be to modify the threshold to match the current number, but that's not as intuitive.

Luckily though, most servers have the same number of outstanding updates, so it wouldn't be too complicated.

How about having a second sensor with a 'change trigger'.

If the value on this sensor for example changes from 1 to 2 you can have this trigger resume the original sensor using PTF.PRObject

This command line tool can pause, resume or "checknow" any sensor, device, group, probe, notification,... of your PRTG installation.

Parameters:

-u=    The url of your PRTG installation.
-un=   PRTG Username.
-pw=   PRTG Password or PassHash *.
-id=   The ObjectID you want to pause, resume, or check now.
-a=    The action to perform (p for pause, r for resume, c for checknow).
-s     Optional switch to suppress the textual output.

Example to resume sensor 1001

PRObject -u=yourPRTGServer -un=myuser -pw=mypassword -id=1001 -a=r

Would that make sense?

Sensors | Multi Channel Sensors | Tools | Notifications

Kind regards,

PRTGToolsFamily

This would require adding two sensors for the one item to be reported, also it looks like these are third party utilities made by yourselves?

I'd prefer to try to keep just the one sensor and also keep it as "stock" as I can. For now, I've just changed the Upper Error Limit (#) to the current value, so if it's 1 and I've mentally acknowledged it, I'll set the Upper Error Limit (#) to that number. This means the next time it changes I'll be alerted.

I'll integrate into my update review process that when it comes to installing the updates I'll zero out that Upper Error Limit (#) again.

Hi leeball,

Indeed, the provided workaround would require a third party tool. However, we rely on solutions and sensors from PRTGToolsFamily and they can be very handy. They are doing a fantastic job here.

But it's just my two cents on this ;)

Best regards,
Sebastian