1 Reply Latest reply on Apr 24, 2018 4:11 PM by mesverrum

    Variables - Per Alerting Method




      So based on another forum post I created (VARIABLE QUESTION - SAM AND NPM), can I get an answer for the following set of questions?


      1) In the Alerts area, you have multiple types of Alerts to generate against:

           A) Applications

           B) Nodes

           C) QOE Applications

           D) Interfaces

           E) F5

           F) Group


      Each set of alerts, take specific variables to alert against.   Is there a way to obtain a list of the variables, for each specific type of alerts?  I have the Application, Nodes and Interfaces working (and the F5 somewhat working).   Problem is, I need to know how to pull against the DNS information for the QOE applications and the IP Address for this type of Alert?  I typically get the ANSII code returned, for the IP Address.


      And my other question revolves around using specific S.A.M. monitors and alerting against those?   Does Solarwinds have a specific SQL monitor, that I can set an alert against?  I know you can do service and process monitoring, but I am having some issues with the one validating correctly.


      I am trying to work through these, one set at a time.   However, I do need some assistance with the list of variables based on IP Address, DNS and Node Name.   With each set of alerts, they each have their own defining variables. I need the entire list for those specific variables, if someone can point me in the correct direction or give me a link that actually contains them all?


      Thank you

        • Re: Variables - Per Alerting Method

          You can just go to the trigger actions tab of the alert and click the insert variable button and it will display the list of all the variables that are available for that object type.  I don't know that anyone has compiled this info in any kind of master list, given that there would be tens of thousands of them to search through you may as well just build the alerts in that tool because then you can validate the variable against one of your monitored objects to make sure it resolves the way you think it would.



          If you don't see a variable for the data you want there in the list you will need to use the check box at the bottom for a custom SQL/SWQL query to get the data you want.  Once you delve into using SQL and case logic you can build realllllly flexible alert templates with an absolute mountain of relevant information packed into them.



          Also, the variables are also not "that" unique, you just have to think about the relationship between the object you are alerting on and the object you want to pull a variable for.  So for example, if I am building a node alert and want the DNS in the message I just use ${N=SwisEntity;M=DNS}


          If I want to get that same variable for an object that is a child object of the node (interfaces, volumes, applications, etc) then I can just use ${N=SwisEntity;M=Node.DNS}

          If the alert object is a child of another object such as a SAM component then I'd just do ${N=SwisEntity;M=Application.Node.DNS}


          So the meat of the variables are pretty consistent, you mostly just have to get familiar with the object relationships.  With that said, I build alerts for people almost every day for the last 3 years and I still don't bother to try and remember the variables.  It is too easy to slip a typo in there and I end up having to test and fix it later so I just go straight to the insert variable button and browse the list until i get what I want.

          1 of 1 people found this helpful