AlexSoul · The Magician! · ✭✭✭✭✭

as for the trigger filter - feel free to alter query to change it to whatever action type IS required (yet again - you are telling me what you DON'T want, rather than what you DO WANT. So, I have no idea what trigger actions you are looking for. I am doing this for Emails because all my alerts have email trigger actions)

You are trying to find an evant Message in the Hardware Sensor object. This is not going to work 1. Change "Message" to "Name" 2. Type first few letters in the value field for the name and press down arrow - it should offer you available options to chose from 3. Pick your exact name you want

Use DATETIFF SQL function in your WHERE clause to filter out everything older than 24 hours: DATEDIFF(HOUR, [AuditingEvents].TimeLoggedUtc, getUTCdate()) < 24 Reference: DATEDIFF (Transact-SQL)

Sure, you are welcome. I have a slight recollection that I have read it somewhere that this is not possible at the moment due to complications in database and the way it works and data organised. I don't remember details though, but SQL works great for me -- Alex

And you can also add name of the sensor to limit it to a particular exact sensor that you need Now, back to "Message" - I think this is what you have (as mentioned above): 1. You see your event in logs. Right? 2. You then create alert based on "Hardware Sensor" 3. Both Hardware Sensor and Event objects (which are different…

Thanks alterego, I have been told by SW support (after raising a ticket) that it will only work if Type of Property to monitor is set to "APM: Application". Most of my alerts are component-based, therefore I still have to use SQL workaround, though (since SAM 6.1) without the need for additional ":" workaround --- Thanks,…

very elegant, thanks Richard

ecklerwr1​, I have no issues setting up UnDP polling and associated alerts. The problem is - every time I need to alert on another UnDP - I end up setting up new alert as well. Well, if that's the only way to approach this - then - hence my Feature Request below

Quote: I ran the direct query in DB and get the output which is not as i like... And how do you expect anyone to know what you wanted it to be? This is like saying "I went into the shop and I didn't find what I was looking for - can you help?" ... can you?

No, no, report is correct. I have checked it myself - it works good for me. Report is very fruitful and gives me all I need ... kidding ... Anyway, try this SQL - it will extract all historical alerts for you. It will NOT show active alerts, as they are not history yet. You can see all active alerts in ALERTS & ACTIVITY >…

How would it look like if it were "fruitful" then?

It would be cool if someone from SolarWinds Team can confirm that

Another thing I have just noticed - you are saying: Events are different then objects (Herd ware Sensor in this case) Try this: * Instead of searching for "Message" add these two filters: 1. Node Node Name is equal to [whatever you server name is] 2. Hardware Sensor status is equal to Critical P.S. I have noticed that…

my pleasure

Ha-ha lol, thanks buddy for the nice words Glad it has worked out for you. Ye, SQL is Rocking thing - keep tickling your brain with learning it slowly - it will pay of 1000 fold. Best, Alex

as I said, this is just tip of the iceberg. If I were to unfold my entire thinking and vision here... you would be reading few days. So, I just decided to keep it simple... for now

I was in contact with SW support and they have advise me that this is by design. http://thwack.solarwinds.com/message/232021#232021

Ye man, this is normal It is called LIFE! If you would only get what you like all the time - you wouldn't enjoy it anymore...

awesome, thanks LadaVarga‌ I am on NPM 11.5 ... might need to upgrade first.

Sorry, forgot to mention, change 4 instances above of "SolarWinds.dbo" into "SolarWindsOrion.dbo" or whatever your database is called

The Acknowledged flag does not exist in Events. It belongs to Alert. So, if you want this info - you MUST either report on Alerts OR use SQL to link your Events to Alerts (Dan above has given you some ideas already how to do it with SQL - you can take it from there and expand to what you need). If you are still not…

I doubt there are any performance implications. However, I prefer simplicity and perfection - if it should work, then it must work

My friend, I am not representing SolarWinds anyhow... I am just like you - user/customer who seeks my own answers and also helps others to get theirs. What exactly is not working for you? Why you don't like out-of-the-box alerts and reports which I have shown above as an examples?

OK, you see - we are getting there So, we have now confirmed that you alert is working and you have also concluded that without filer it works (albeit too much noise) and with filer it doesn't - hence, the problem is filter I would suggest you the following: * Go to your Reports and create a new report * Make it to report…

much appreciate for such detailed reply - thanks a lot - all clear now

ecklerwr1​ I have slightly adjusted original question to make it a bit more clear that I am not looking to monitor UnDPs with SAM, I just look for ways to monitor UnDPs with single alert Thanks for your help so far

Groups? How would you set this up for UnDP pollers? I think you need to shoot higher... way higher. I am not solving a particular issue - I am trying to find a solution for scalable design going forward. Creating alerts for every UnDP that I want to monitor and alert on is very inefficient. Just imagine having application…

OK, I agree, native hardware monitoring is good, but it is still just a fraction of what is available via SNMP polling. This will always be limited with Hardware Sensors, although I do agree they help a lot.

Hi Petr Vilem, I think we have cracked it. I was using SDK with Orion (v2) Server Type, that's why I could not see those fields. Your answer above was absolutely spot on I really appreciate your help on this. By the way, I actually CAN get "message" for script components from ChartEvidence table. I can get both STATISTIC…

That's right, but using COLON in SQL statement is much more manageable than having extra CustomProperty defined per node which will hold this COLON (if not 6.1). The main probalem is - when you create new nodes - you need to remember to stick this COLON as a default value, otherwise it will not work for those new nodes. I…