Showing results for 
Search instead for 
Did you mean: 
Create Post

Why Are We Required To Use The NodeID Variable In The SWQL Query Polling Option?

Jump to solution

I'm curious to know why we are forced to use the ${NodeID} macro when using the SWQL polling option when building out a profile. I do not recall seeing this requirement in the beta, though, I cannot find my notes to verify. (and we all know, beta=definitely going to be in production...)

Additionally, while building out the profile, it would be nice to validate the query in more detail, rather than just checking to make sure ${NodeID} is listed somewhere. Perhaps something similar to how SAM actually runs the component, gathering real(-ish) results.



1 Solution
Level 8

The restriction was removed based on the feedback mentioned in this thread. SCM displays just a warning instead to prevent accidental edits. I hope you like it...

View solution in original post

8 Replies
Level 8

The restriction was removed based on the feedback mentioned in this thread. SCM displays just a warning instead to prevent accidental edits. I hope you like it...

View solution in original post




Thank you!

Level 8

Hi Will, verification of custom profile elements was not finshed in Beta version yet.

I'm also curious what SWQL query are you thinking of? What pieceof information are you trying to monitor for changes?

The logic in that restriction is the following: Each server configuration is related to a specific server, monitored as Orion node, therefore missing NodeId in the SWQL query is invalid since such query can return server unrelated data.

martin.filip​ For me, I customize a bunch of things, and this tool was the first step towards keeping my settings the way I need them. During the beta, I thought I had setup SWQL queries to monitor some of those settings, but was unable to do (what I thought were) those same queries in the current version.

As an example, I may want to check for various settings from the Orion.Setting table, to make sure nobody, or nothing, has gone back in to change them.


I know there are numerous ways to do most things with SolarWinds, however, I just feel like putting a limitation on this specific feature limits it more than improves it. An override option would be nice, perhaps something similar to how you have to go into the advanced settings to enable the SWQL query and file parser options.

Even if I were to assign this to the OrionDB server, being monitored in NPM and SCM, how would that NodeID be useful in the query above? I mean, if I were to use a SQL query, then I would DEFINITELY need to connect to the DB server, as that is the only place to pull data. However, with a SWQL query, doesn't the SWIS connection jump through the web side of things? I mean, it ultimately gets data from the DB server, but how, and why, would I want to start limiting results based on a NodeID that doesn't even matter? (at least that's how my tiny brain is understanding things...)

Thank you,


I got your point. I will definitly open that discussion internally based on your input...

The major difference is, that you're using Orion server to monitor itself for changes. Than you obviously do not need NodeId.

thank you for clarification.

bshopp​, any idea why we are forced to use the ${NodeID} macro? Is there a hidden toggle for that requirement, some way to bypass it? I would like to test a few things via the SWQL monitor, such as changes to internal system settings. However, with the requirement, I don't understand how I can accomplish this task. Any suggestions?

0 Kudos

You have to include the NodeID to limit the query to whatever node the profile is assigned to. Otherwise you'd get changes for all nodes. What query are you trying to build that you can't add it to?

I'm just wanting to see, and track, various data points in the DB, via a SWQL query. Mostly, however, I think it's more towards the possibilities of what can be done, rather than doing something very specific right now. Having seen the power of the tool in beta, I was excited to have the option to look at specific data results, and monitor those results. For me, I find native SolarWinds functionality can do the majority of what we need, and get us 95% of the way to the finish line. However, I also know how many times I have had to MacGyver things together to finish that last 5%. This tool had the potential to close the gap, providing super easy ways to track that weird, random, and otherwise awkward data.

Thank you,


0 Kudos