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

Variable for alerts

Jump to solution

Wheres a good source on how to read variables for alerts? What language is it written in? Is there a glossary of terms?

0 Kudos
1 Solution
Level 12

There are some basic ${IP} and ${CAPTION} variables. Not sure where those are documented, but you will eventually move past those anyway, so here is how to get the to advanced variables.

The variables are based on the SWQL database, which is a fancy SQL database. For most of this to make sense you will need to download the API from https://github.com/solarwinds/OrionSDK/releases
Even if you are not going to use the API, there is a tool called SWQL studio.  That is where you will be spending a lot of time.  You can test your SWQL statements for custom alerts, custom widgets, etc.. with SWQL studio.  

One thing to note in SWQL studio is that some of the items are under "Orion" and some are not, and it does not make sense, so don't even try, that's another topic.  For example, you have to expand "+...{} Orion" to see Orion.Nodes, but for Applications it's under Orion.APM. It's a history lesson to understand it.

So the first thing you need to know is the base object you are alerting on:

Node, application, volume, etc. It's the thing you selected in the trigger condition for "I want to alert on".  That directly corresponds to something in SWQL. 

Nodes = Orion.Nodes
Volumes = Orion.Volumes
Interfaces = Orion.NPM.Interfaces
Application = Orion.APM.Applications


Now you need to open SWQL studio.  Lets use Orion.Nodes as an example.  When you expand Orion.Nodes, you see a LOT of properties.  Most of them can be used as variables. You use the format ${N=SwisEntity;M=VARIABLE}, for example: ${N=SwisEntity;M=Caption}, ${N=SwisEntity;M=IP}, ${N=SwisEntity;M=MachineType}, ${N=SwisEntity;M=DetailsURL}, etc...

Stick with those basics at first.  From here it starts to get Complicated.

If you scroll past the basic properties, you start seeing a lot of things with an icon that looks like 3 links in a chain.  Those are automatic links (like sql joins) to other tables.  Lets start with an easy example to see how chaining works:  In Orion.Nodes there is a link to "Engine (Orion.Engines)".  This is a link to the polling engine for that node.  Not real useful here, but it's an easy example.  So go look in Orion.Engines table, one of the fields is "ServerName" it's the name of the Orion polling engine for this node, to access that variable in a Node alert you would use ${N=SwisEntity;M=Engine.ServerName}. 

Now lets looks at another chaining example.  Say this is a volume alert.  If you use ${N=SwisEntity;M=Caption} now you get the name of the volume, not the name of the node like we did in the node alert.  But looking at the Orion.Volumes table is a link to the Nodes table.  So you can do things like this "Volume ${N=SwisEntity;M=Caption} on server ${N=SwisEntity;M=Node.Caption} is almost full"  

Special note:  The Link is called "node" to the Orion.Nodes table.  You use the link name not the table name when you are chaining.  That is why it's ${N=SwisEntity;M=Node.Caption} instead of ${N=SwisEntity;M=Nodes.Caption}.  I will probably get this wrong at least once in this example, this same with the "Engine" link in the nodes table, there is no "s" at the end.  There is a reason for this, but we're not going that deep here.

BUT If you order now, we can send you two for the price of one.  Lets go another level.  So the volumes tables links to the nodes table and the nodes table links to the engines table.  So if I want the polling engine name for the volume, it's ${N=SwisEntity;M=Node.Engine.ServerName}  Maybe we should have a challenge to see how far we can run these links without creating a circle.

I also have a parting gift.  Back to the nodes, but this works on anything.  CUSTOM PROPERTIES!  For this example we have created a custom property on Nodes, called "TechContact", We edit the servers node and enter the name of the technical person in charge of this server.  So when this server (node) alerts, you can have something like "Server ${N=SwisEntity;M=Caption} is down, please contact ${N=SwisEntity;M=CustomProperties.TechContact}".  If you are alerting on a volume almost full, but the custom property is not on the volume it's on the node, you can do this.  "volume ${N=SwisEntity;M=Caption} on Server ${N=SwisEntity;M=Node.Caption} is almost full, please call ${N=SwisEntity;M=Node.CustomProperties.TechContact}"


Again sorry for the first post, my mind was somewhere else.

View solution in original post

4 Replies
Level 12

There are some basic ${IP} and ${CAPTION} variables. Not sure where those are documented, but you will eventually move past those anyway, so here is how to get the to advanced variables.

The variables are based on the SWQL database, which is a fancy SQL database. For most of this to make sense you will need to download the API from https://github.com/solarwinds/OrionSDK/releases
Even if you are not going to use the API, there is a tool called SWQL studio.  That is where you will be spending a lot of time.  You can test your SWQL statements for custom alerts, custom widgets, etc.. with SWQL studio.  

One thing to note in SWQL studio is that some of the items are under "Orion" and some are not, and it does not make sense, so don't even try, that's another topic.  For example, you have to expand "+...{} Orion" to see Orion.Nodes, but for Applications it's under Orion.APM. It's a history lesson to understand it.

So the first thing you need to know is the base object you are alerting on:

Node, application, volume, etc. It's the thing you selected in the trigger condition for "I want to alert on".  That directly corresponds to something in SWQL. 

Nodes = Orion.Nodes
Volumes = Orion.Volumes
Interfaces = Orion.NPM.Interfaces
Application = Orion.APM.Applications


Now you need to open SWQL studio.  Lets use Orion.Nodes as an example.  When you expand Orion.Nodes, you see a LOT of properties.  Most of them can be used as variables. You use the format ${N=SwisEntity;M=VARIABLE}, for example: ${N=SwisEntity;M=Caption}, ${N=SwisEntity;M=IP}, ${N=SwisEntity;M=MachineType}, ${N=SwisEntity;M=DetailsURL}, etc...

Stick with those basics at first.  From here it starts to get Complicated.

If you scroll past the basic properties, you start seeing a lot of things with an icon that looks like 3 links in a chain.  Those are automatic links (like sql joins) to other tables.  Lets start with an easy example to see how chaining works:  In Orion.Nodes there is a link to "Engine (Orion.Engines)".  This is a link to the polling engine for that node.  Not real useful here, but it's an easy example.  So go look in Orion.Engines table, one of the fields is "ServerName" it's the name of the Orion polling engine for this node, to access that variable in a Node alert you would use ${N=SwisEntity;M=Engine.ServerName}. 

Now lets looks at another chaining example.  Say this is a volume alert.  If you use ${N=SwisEntity;M=Caption} now you get the name of the volume, not the name of the node like we did in the node alert.  But looking at the Orion.Volumes table is a link to the Nodes table.  So you can do things like this "Volume ${N=SwisEntity;M=Caption} on server ${N=SwisEntity;M=Node.Caption} is almost full"  

Special note:  The Link is called "node" to the Orion.Nodes table.  You use the link name not the table name when you are chaining.  That is why it's ${N=SwisEntity;M=Node.Caption} instead of ${N=SwisEntity;M=Nodes.Caption}.  I will probably get this wrong at least once in this example, this same with the "Engine" link in the nodes table, there is no "s" at the end.  There is a reason for this, but we're not going that deep here.

BUT If you order now, we can send you two for the price of one.  Lets go another level.  So the volumes tables links to the nodes table and the nodes table links to the engines table.  So if I want the polling engine name for the volume, it's ${N=SwisEntity;M=Node.Engine.ServerName}  Maybe we should have a challenge to see how far we can run these links without creating a circle.

I also have a parting gift.  Back to the nodes, but this works on anything.  CUSTOM PROPERTIES!  For this example we have created a custom property on Nodes, called "TechContact", We edit the servers node and enter the name of the technical person in charge of this server.  So when this server (node) alerts, you can have something like "Server ${N=SwisEntity;M=Caption} is down, please contact ${N=SwisEntity;M=CustomProperties.TechContact}".  If you are alerting on a volume almost full, but the custom property is not on the volume it's on the node, you can do this.  "volume ${N=SwisEntity;M=Caption} on Server ${N=SwisEntity;M=Node.Caption} is almost full, please call ${N=SwisEntity;M=Node.CustomProperties.TechContact}"


Again sorry for the first post, my mind was somewhere else.

View solution in original post

Hi, great article.

I am trying to use some information from a Universal Device Poller, but can not fathom how to address the information as a variable to use in an email.

The information in my case is the Time Remaining on a (non APC) UPS.

APC UPS's are supported natively, and some of their variables are provided directly using

${N=SwisEntity;M=PCUs.RunTimeRemaining}

If its possible, could you perhaps provide an example how you arrive at a UnDP variable please.

I have found examples below, but they dont work, the syntax below obviously doesnt include the poller name or variable name, so I am not entirely surprised they dont work.

Custom Node Poller (Universal Device Poller)
    Poller Unique Name: ${N=SwisEntity;M=CustomPoller.UniqueName}
    Poller Display Name: ${N=SwisEntity;M=CustomPollerStatusScalar.DisplayName}
    Poller Current Value: ${N=SwisEntity;M=CustomPollerStatusScalar.Status}
    Poller Current Numeric Value: ${N=SwisEntity;M=CustomPollerStatusScalar.RawStatus}

 

0 Kudos

Yep found one mistake already ${Node.Engines.ServerName} should have been ${Node.Engine.ServerName}... no "s" on node or engine.... 

there it's fixed now.  Let me know there's probably a dozen more spelling errors or typos in there.

The only thing I would add is that trying to do them by memory is a huge waste of mental effort. I've been writing these things for hundreds of companies for years and I still mess them up on a regular basis when I try to wing it from memory your best bet is just to use the insert variable button inside the alert building tool
- Marc Netterfield, Github
0 Kudos