Years ago, when SolarWinds changed the alert variable system to the current one that uses the ${N=...M=...} system, I thought the whole point was that it would put it in line with the SWIS relationships, thus allowing users to navigate the SWIS entity tree to create variables. However, it seems that if a variable doesn't exist in the variable picker then you have to use custom SQL/SWQL to get the value. For example, I'm alerting on an SAM component monitor and I want to display the vCenter name of the node where the component lives. Using the SWIS entity tree, this variable should work no problem:
${N=SwisEntity;M=Application.Node.RelyVCenter.DisplayName}However, it doesn't...
Am I doing something wrong, or does SolarWinds have to manually build all of the variables before we can use them? If so, then what was the point of this new variable system?
It seems like a pretty big oversight if this is the case... Using SWQL studio, users can easily see all of the entities and their relationship, so building custom variables would be a cinch. This would also take the weight off of SolarWinds having to field requests from users to build variables for us. Furthermore, SolarWinds could easily write a program that would build variables for us based off of the SWIS entity metadata tables.
As a small aside, if a variable doesn't work, it'd be nice if it just didn't display anything in the message instead of displaying the variable itself. When I tested the vCenter DisplayName variable above, it actually displayed the entire variable in the message rather than just being null. The same thing happens when you use a custom SWQL/SQL variable where the query doesn't resolve to anything. Instead of display nothing, it displays the entire variable, including the query itself. It's quite unseemly for unknowing users when they receive the email with it in it.
