Open for Voting

Force 'poll now' alert action

Please create an option for an alert trigger action that will force 'poll now' the actual object that triggered the alert.

This will be for WPM Transaction monitors and for SAM component monitors like SQL Server User Experience monitors and Oracle User Experience Monitors, for HTTPS monitors and some PowerShell monitors we have.

I know that for node objects there is a fast polling cycle being performed by SW to really check if a node is down, but I'm not aware of any fast polling cycle for SAM component monitors nor for WPM transaction monitors. The idea of forced poll now as an alert action for WPM Transaction monitors and for SAM component monitors is a way I've thought of to somehow get a similar approach being utilized on a node object's fast polling cycle.

Having a fast polling cycle for WPM Transaction monitors and for SAM component monitors looks can perhaps be sent as a feature request on its own.

The way it works right now for SAM component monitors is that if a certain poll fails, a down status - a red circle - is automatically given to that SAM component monitor, which then triggers our Component is down alert for XYZ IT resolver teams.

Before they even get an alert they want SW to first try to poll it again. However, adjusting the polling interval of the app monitor from every 5 minutes to every 1 minute will increase polling load on the SW server. They just want SW to retry polling only when one poll has failed, so in this case the additional load is only going to take place when one poll is down. But if the polling interval itself will be set to 1 minute, it will then always be every one minute, and will add heavier load as compared to "force-poll-only-when-it's-down approach".

Based on what I'm hearing from our internal IT resolver teams, it sounded like the feature they want is similar to fast polling on a node.

Fast polling as far as I know does not automatically mark an object with a down status - it sets the node object to warning while force polling every 10 or so seconds and only after that will a final, official node status will be given.

If this "Force 'poll now' alert action" gets implemented, I plan to :

- use the Force 'poll now' alert action as the very first trigger action,

- set a delay of say 90 seconds to allow the force poll to do its trick,

- and then fire a Send Email action.

- couple that with using "Condition must exist for more than 120 seconds" under the trigger condition tab

But I think implementing the same node object fast polling technique for component monitor objects or web transaction monitor objects will be more cool emoticons_happy.png

  • Would be nice to have it for NPM and SAM. The feature would be great in situations where we are polling for NPM resources every 10 minutes and on each poll cpu or another resource was showing as high but if you go on the box it is generally a short spike and then disappears. And although we have lags in our alerts it does not matter because NPM sees the resource as high and the alert when it comes out is not accurate but if you could a 'poll now' then it would force solarwinds to recheck the resource to verify that it is still high.

  • ok... now I got you emoticons_happy.png Thanks.

    I do agree that when app/component rolls into down status more often then not this is due to some sort of one-off communications or polling problems, rather then actual stats of the component. I think the idea is worth it, just need to expand/edit a bit with info from your last reply.

    The workaround for this issue on my side is two fold:

    1. I have a special keyword in component and application template description which will exclude down status alerts for those particular apps/components where down status doesn't mean anything. Most of the time to report any performance problems I would either have warning or critical thresholds set. DOWN status as such tells me nothing, other than most likely node is down, which I will receive anyway via node down alert

    2. I have another alert which I call "Polling Issues". It will pick up above conditions, i.e. where keyword is set and status is down, and will report as a separate alert. This particular polling issues alert will have 30 minutes delay timer before triggering any alerts

    Combination of the above two works perfectly well. I would love to share, but all my alerts are SQL based and have custom tables and references, so, will not be helpful to you. I guess if you get the concept you may be able to replicate this

    I also advise you to check this resource here, which talk about those "Polling Issues" in more details. Those are reports, but I have alerts configured for each of them as well

    Hope this will lead you to some sort of workarounds at your side, until this idea is implemented

    +1 vote from me emoticons_wink.png

    P.S. I would suggest you to update your idea with notes from your last comment. Makes it easier to understand what actual problem is. Fast polling is the way to go I believe, similar to how it is done with nodes

  • Yes, forced poll option is available for 'manual' clicking.

    The way it works right now for SAM component monitors is that if a certain poll fails, a down status - a red circle - is automatically given to that SAM component monitor, which then triggers our Component is down alert for XYZ IT resolver teams.

    Before they even get an alert they want SW to first try to poll it again. However, adjusting the polling interval of the app monitor from every 5 minutes to every 1 minute will increase polling load on the SW server. They just want SW to retry polling only when one poll has failed, so in this case the additional load is only going to take place when one poll is down. But if the polling interval itself will be set to 1 minute, it will then always be every one minute, and will add heavier load as compared to "force-poll-only-when-it's-down approach".

    Based on what I'm hearing from our internal IT resolver teams, it sounded like the feature they want is similar to fast polling on a node.

    Fast polling as far as I know does not automatically mark an object with a down status - it sets the node object to warning while force polling every 10 or so seconds and only after that will a final, official node status will be given.

  • I am still a bit confused tbh. Forced poll is available on SAM application level, whereas you can also set polling cycle on application level as well. So, I can see both options are there already... Can you give/expand on case please.

    In your case, if some apps need fast polling I would segregate them into different template and set this to minimum allowed polling cycle. I think it can be as low as 30 seconds, but I am not 100% sure - just out of my head. Might be 1 minute though

  • This will be for WPM Transaction monitors and for SAM component monitors like SQL Server User Experience monitors and Oracle User Experience Monitors, for HTTPS monitors and some PowerShell monitors we have.

    I know that for node objects there is a fast polling cycle being performed by SW to really check if a node is down, but I'm not aware of any fast polling cycle for SAM component monitors nor for WPM transaction monitors. The idea of forced poll now as an alert action for WPM Transaction monitors and for SAM component monitors is a way I've thought of to somehow get a similar approach being utilized on a node object's fast polling cycle.

    Having a fast polling cycle for WPM Transaction monitors and for SAM component monitors looks can perhaps be sent as a feature request on its own.

  • Not clear what is the rationale. Would you please expand?

  • I like the idea, but force poll might add some additional load onto the poller when its a medium or large environment.

    We have alternative options which are already existing like wait until or wait for * polls etc