Interface variables on trigger action for "Node is in a Warning or Critical State" alert

GrahamV

Good day,

I'm fairly new to Solarwinds HCO.

For the "Node is in a warning or Critical State" alert, I would like to provide interface metric values in the email action, in the following manner:

InPercentUtilizationThreshold:${N=SwisEntity;M=SwitchPortEntriesAsMapped.MappedInterfaces.InPercentUtilizationThreshold.Level2Value}
State:${N=SwisEntity;M=SwitchPortEntriesAsMapped.MappedInterfaces.InPercentUtilizationThreshold.IsLevel2State}
Value:${N=SwisEntity;M=SwitchPortEntriesAsMapped.MappedInterfaces.InPercentUtilizationThreshold.CurrentValue}

(if there are better values to use, then please let me know)

This would return something like this in the email body:

InPercentUtilizationThreshold:95
State:False
Value:85

So, when a network switch interface is responsible for the node state change, I would hope to see the information in the alert email. However, I'm not sure that this is what is actually happening. How can I know that the interface values from the variables are for the offending interface, and not something else such as the average data for all of the switches interfaces? Can anybody perhaps indicate if  I'm working toward the correct solution with this approach or not?

In addition, I would also like to adapt the alert, and only provide the interface information where applicable. So, if this is a server based alert, and not a network switch, then it should not use the variables.above, any ideas? I suspect that I would need to use  some SQL\SWQL?

KInd regards

Graham

mesverrum

You are going down a very complicated road with this angle.  One of the things to keep an eye on when it comes to alerts is to be aware of the type of entity the alert targets. Right now you are describing having an alert on a Node, but wanting to display variables relating to its child interface.  But you already hinted at it, how does the alert know which interface caused the status change?  it doesnt.  You can get realllllllly deep with sql and basically hard code queries to identify the interface(s) that cause a status change but thats just not how these things were designed to work. 

You want to know about an interface?  Create your alerts to target interfaces, then the variables will all just automatically resolve to the interface that triggers the alert.

Having one master level alert on anything that could possibly impact the node status would be a wild amount of custom sql that would be really non performant compared to just making separate alerts with message payloads that are specific to their entity type and trigger scenario.