cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post
Level 13

Are Custom Alert Variables Not Possible?

Jump to solution

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.

Labels (2)
1 Solution

You were correct when you said that it has to be a "built in" variable, they don't let us just walk the SWQL tables to take whatever we want unless you build a custom sql/swql variable.  As far as what is the point, why is the sky green?  SW devs do what they want?

- Marc Netterfield, Github

View solution in original post

0 Kudos
6 Replies
Level 7

Solarwinds has no issues regarding their default alerts, it allows you also to customize your alerts and it's possible to configure it via web console. Just go to manage alerts and select desired alerts then duplicate and edit. I tried also testing your variable, simulate in trigger actions but no problem at all. You might wanna check this link for other resolutions for this case.

:Alert on custom properties in the Orion Platform

:Create a custom alert in SAM

0 Kudos

Sorry, what?  I don't think you are understanding what I'm asking about... I'm quite aware of how to customize SolarWinds alerts.  That isn't what I'm talking about at all nor did I say anything about that in my post.

My only issue is with using custom variables that are not available in the variable picker when editing actions or alert messages.  You say you tested my variable and it worked, but I highly doubt that's true unless you edited my variable to be used with a node type alert.  The variable I gave as an example is to be used when alerting on a SAM Component.  I've tried the variable in two separate Orion environments that we have and it doesn't work with either.   Other custom variables I've tried do not work at all.   My point stands, if custom variables don't work then what is the point of the new variable system they came out with several years ago? 

0 Kudos

You were correct when you said that it has to be a "built in" variable, they don't let us just walk the SWQL tables to take whatever we want unless you build a custom sql/swql variable.  As far as what is the point, why is the sky green?  SW devs do what they want?

- Marc Netterfield, Github

View solution in original post

0 Kudos

Yep, I was hoping I was wrong, but the more I experimented with it in both our production and QA instances, the more I discovered that it indeed does work this way.  Makes no sense to me at all...  It seems the variable system they came up with was designed so that we could walk the SWIS entity tables, otherwise why build the system the way they did?  Seems like it would save them a ton of work and give amazing customization to their users.

Well, it sounds like a feature request I can make that will sit there for several years and either finally get implemented or completely ignored...   *sigh*

0 Kudos

To your point about null values dumping out the whole SWQL query, the workaround I have been using is just to wrap the whole thing in an isnull function, usually something like

"select top 1 isnull((select my thing from whatever table),'None Found') as Result from orion.nodes"

- Marc Netterfield, Github
0 Kudos

Yeah, that's what I do as well.  Often I forget though.  Still seems like they should just have a function that says anything wrapped in ${ } should either resolve to a value or be ignored.

0 Kudos