Database Value for Muted Nodes

Does anyone know what the database field is for muting nodes? (e.g. UnManaged, UnManageFrom, UnManageTo for unmanaging nodes) I would like to run a script for our NOC that would mute all nodes during extended outage weekends. I took a quick look on the Nodes table but didn't see any value that would indicate it is muted.

Find more posts tagged with

script muting of nodes

sam

Mute

Node

Database

npm

Accepted answers

xtraspecialj

You probably found your answer by now, but for anyone else like me who was looking for a way to do this and found your unanswered post, I figured I'd share how I found the answer.

Unmanage data is in the Orion.Nodes SWQL Entity table, so that's no problem, but if a Node is Muted, that's a whole different story altogether...

I came across this Thwack post here where I saw he was using the new SWQL Entity (table) called Orion.AlertSuppression. I'd previously looked through the SWQL tree several times and somehow missed this new Entity. Basically you'll need to join the Orion.Nodes Entity table to the Orion.AlertSuppression Entity table where the AlertSuppression.EntityUri field equals the Nodes.Uri field.

If you feel you must use SQL for some reason then I'm sure there are some tables similar to these, but honestly you shouldn't be querying the SQL table directly unless you have no choice. Should SolarWinds change their Database Schema in the future your custom SQL queries could no longer work whereas the SWQL queries will still work fine. The only time I use SQL is when I can't find the data I want in the SWIS API (which almost never happens anymore) or for performance issues. For example, our SAM component statistics tables are huge and when I query them in SWQL it times out, so I have to use SQL queries for that stuff.

Furthermore, if you plan on making changes you should definitely not be using direct SQL updates but instead should be using Powershell or some other appropriate language to interact with their API. Changing tables directly with SQL is risky as there could be other tables that need to be updated that you aren't aware of, or, if they change their DB Schema in the future then the direct SQL Update query that previously worked fine might now either just not work at best, or do some harm at worst.

If you are curious about their API, tdanner and friends have done a great job with their GitHub page here (especially check out the Wiki section): GitHub - solarwinds/OrionSDK: SDK for the SolarWinds Orion platform, including tools, documentation, and samples in Powe…

All comments

xtraspecialj

You probably found your answer by now, but for anyone else like me who was looking for a way to do this and found your unanswered post, I figured I'd share how I found the answer.

Unmanage data is in the Orion.Nodes SWQL Entity table, so that's no problem, but if a Node is Muted, that's a whole different story altogether...

j_dennis

I found the same thing. And unfortunately that means I was not able to create a functional script for this use case. Thanks for your input. Maybe the table schema will change in the future but for now we will be using the manual process of muting nodes.

xtraspecialj

Why were you not able to create a script for this? It actually works quite easily...

What I did was create a Node custom property called “A_AlertsMuted” (by the way, the “A_” is part of a naming scheme we use for custom properties in which different categorizations of properties are prepended with a letter that stands for the category that it is a part of. We do this because Custom Properties are always listed alphabetically in the web console, so by using a prepended code letter all properties of a certain type are kept grouped together for easy finding. “A_” stands for Alerting properties, “L_” stands for Locational properties, “D_” stands for Descriptive properties, and so on. I stole it from some other post I saw on Thwack a long while back.).

Next, I created a Powershell script that looks up all Nodes in the SWQL "Nodes.AlertSuppression" entity table to see if any are currently muted or scheduled to be muted in the future.

Then, it updates the “A_AlertsMuted” custom property of those nodes to reflect its findings.

For optimal performance, the script only updates properties where the new value is different than the current value, so often times it doesn’t have to do anything and runs quite quickly. The first run where it had to update all 3,200 Nodes in our environment took about 6 minutes, but unless all Nodes are Muted/Unmuted at the same time it should never take that long again. Typically it takes less than 5 seconds to run if there are no custom property values to be changed, and a few more seconds to run if there are some changes.

After I got the script working I simply set it to run as a Scheduled Task on one of our polling engines. We set it to run every 5 minutes. Therefore the property is always updated within 5 minutes of any change. If someone were to Mute/Unmute a bunch of nodes and wants the property value updated quicker than 5 minutes then they could just RDP to the polling engine that houses the Scheduled Task and run the task on demand.

The nice thing about populating this value into a Custom Property is that we can use it everywhere. Whether we want to create a custom table for a report or view, or whether we just want to be able to Group by all Muted nodes in the “Manage Nodes” screen we now have this one easy property to filter on. It’s quite useful.

If anyone is interested in this script I can see about sanitizing it and sharing it on here. It has several customized features just for our environment, so it’ll take a bit of doing to share it, but if there’s enough interest and I have enough time I will try to get it done.

jonr

I am interested in the script. We are currently using a powershell script that uses the rest api, however for auditing purposes there is a bug somewhere in solarwinds where I need to have the suppressfrom in local time and the supressuntil in UTC and on the audit log it shows the opposite. So if I want to look back historically and make sure my guys are muting nodes for scheduled or unscheduled maintenance I am looking at the audit log and the audit message contains one value in local and the other and utc. I thought of trying to parse out the dates to convert them but it seems like too much of a hassle.

tonyreel

Hey, I'd love to see that script if it was possible. Would save me starting from scratch