Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials

Testing custom node poller alerts in NPM 10.6

To the point... I assigned the Cisco fan status alert to one of my routers in which I enumerated the output to a text value. When I test the alert against that node, the email lists another custom poller, ifSpeed, rather than the fan status poller.

Is this a bug? Can one test custom poller alerts in the Adv Alert manager with NPM v10.6?

Thanks.

Find more posts tagged with

Accepted answers

All comments

JiriPsota

This is not a bug. Test is used to test alert action, it does not care about trigger condition.

borgan

You are missing my point. I am aware that the Test refers only to the Trigger Action, but in this case, the referenced alert is incorrect. I had to delete all other custom pollers in order for the alert test to properly reference the custom poller that is actually named in the alert trigger. That much I know is not normal.

adatole

Nope, JiriPsota wasn't missing your point, although he may not have stated his answer clearly.

The "Test" button doesn't really test THAT criteria. It pulls up ANY criteria (ie: any universal device poller) and just takes it as-is.

Meaning, the "test" button does not actually TEST the alert trigger at all. It doesn't see if the specific UnDP is on the box, or if the condition is true, or ANYTHING. It really just tests to see if the alert action will work IN ANY SITUATION.

Thus, a better "test" is to create the alert, but then modify the criteria so it is only for one node, and so that ANY threshold is acceptable (where rawStatus is not null). Then save the alert, hit the "CLEAR" button, and let the alert fire. You will get an "alert" which shows you if the actual variables are being read correctly.

From there you can modify the alert trigger and/or alert action until it's the way you like, and then remove the node-specific criteria (and set the threshold correctly) and you should be good to go.

borgan

I see what you mean, but I was specifically stating that I had not ever seen the referenced alert that was being tested at the time be incorrect. Yes, the node, interface, or volume selected against which to test the alert is random and does not matter (though something must be selected), but all tests I have run in the past have at least referenced the CiscoEnvMonFanState poller rather than the ifSpeed poller, as was the specific issue in this case. I found that I had to delete all other assigned pollers to a particular device, before I could successfully test the trigger for the fan state poller and see the correct name of the poller listed in the email body. Are you saying this is normal?

Since I am leaning into a rant here , I might as well say that the documentation for the macros available through the "Insert Variable" tool is and always has been very poor - esp. for custom poller variables.Users should not have to employ a trial and error approach in order to determine which variables will yield what output. Is there no reference that defines and/or gives examples for the macros?