Trouble getting Interface to Alert properly

Does it behave any differently when you change "r1" and "r2" in the alert to "R1" and "R2"?

Hi,

Have you tried with r1* and/or Qwest* ?

spx13320​ Personally, I would separate the trigger and scope/grouping criteria first. While not required, I find it easier to work with if testing different scenarios. Setting only the scope, I would check it at each condition created, and watch the list of interfaces continue to decrease, until showing only the exact matches you WOULD see if they were down. Then, make the trigger condition, and see if your single interface shows. If not, then I would invert the trigger, or change it to show as NOT up. Maybe there is something weird in the status of the interface?

Let us know what you find, please.

Thank you,

-Will

Hi @spz13320,

Try removing some of the criteria, until you get a match.

If you remove the "Interface Status = Down" criteria, and follow the next next next until the Alert Summary page,  you should get a pop-up towards the bottom that details:

                   This alert would be immediately triggered on X object(s) in alert scope. View list (hyperlinked), etc....

Use the hyperlink to view the objects and confrim that your selection is correct. as this should list all interfaces the have Qwest in them and belong to the devices starting with r1 or r2 (which should be case insensitive, as most of Microsoft is).

If this list contains nothing, then you have something wrong, try using the interface alias, instead of interface name.

These boxes should auto populate, was you type into the text entry box, if they match element in your DB.

Also do you have the Orion SDK installed, with the SWQL Studio? If so use the trigger dropdown to view the underlying SWQL:

This then produces a script windows for copy'pasta into the SWQL Studio, where you can quickly play around with the alert trigger criteria, and see the results instantly.

You could also use the Orion Swis view, to test the SWQL code:  http://<servername>/Orion/admin/swis.aspx 

I hope it helps

First, it looks like in your Scope section you are selecting the specific interfaces you want alerted on, then in your trigger you are redefining this using rules (Interface Name Contains Quest, Node Names Contain R1 or R2).  This is redundant.  Do one or the other, not both.  Having said that, please read on...

Second, based on the above statement, the "Interface Name Contains" section and the "Node Name Contains" section should both be in the Scope section of the alert and you should NEVER select specific items to be alerted on.  Alerts should be as general as possible and always be rule based.  This way you don't have dozens and dozens of individual alerts to manage and you don't end up with alerts that are duplicates and are no longer needed (your environment changes over time and when you write specific alerts for things you will almost definitely not remember to go back to these alerts later and update/remove them as needed).

Third, keeping the rules that define what devices to alert/not-alert on in the Scope section allows the alert to not only be cleaner to read, but also it allows the "All Alerts this Object Can Trigger On" resource to be usable.  This view resource can be found on nearly every item Details view or can be added to any item details view when you hit Customize Page.  It's a handy resource but it only works if you keep your Scopes and Trigger Conditions separate in your alerts.

Lastly, you are saying "Interface Name" contains Qwest.  The "Interface Name" for that Interface is "Serial 0/0/0".  What you would want there is "Interface Caption" Contains Qwest.  The "Interface Caption" in Orion is the combination of the "Interface Name" and the "Interface Description" (unless you manually changed the Interface's Caption at some point in the past, then the Caption is whatever you changed it to...).

However, like I said, I would never write an alert for one or two specific interfaces like this.  Trust me, this will become a nightmare to manage if you continue down this road.

What's better is to set some custom properties at either the Node or Interface level (depends on how detailed you need it to be) called ContactPrimary and ContactSecondary (you could create more if necessary, like ContactTertiary, ContactQuarternary, etc...).

Next, go into the Custom Property Editor and label all your Nodes/Interface Contact properties you just created with the email addresses that should be notified when a problem with these Nodes/Interfaces occur.  We prefer doing properties at the Node level as usually whoever is responsible for the Node will be the same people responsible for the Interfaces on that Node.  But, if you need to email different people for different interfaces, then you would want to create these properties at the Interface level.  The Custom Property editor has powerful filtering and grouping options making it really easy to bulk edit these Custom Properties and get all of your Properties on all of your Nodes/Interfaces labelled pretty easily.

Once you are done labeling your Node/Interface properties with the proper contact emails, you just go create ONE Interface Down alert and in the alert Email Trigger and Reset Actions you simply put the variable for these new Contact Custom Properties into the TO: and/or CC: lines.

So in the TO: line of your Email Actions you'd have this in there if you were using Node Custom Properties for your Contact Addresses:

TO: ${N=SwisEntity;M=Node.CustomProperties.ContactPrimary}; ${N=SwisEntity;M=Node.CustomProperties.ContactSecondary}

The beauty of this system is now you only have one Interface Down alert to manage.  Also, should any future interfaces be added to your Orion environment you no longer need to go create yet another alert for it.  All you do is make sure the Custom Properties for the Node/Interface are properly filled out and presto!  It automatically becomes alerted on and the emails go to the proper people.  Should the contact emails change in the future simply update the properties for the relevant Nodes/Interfaces and that's it.  No need to go digging through all of your alerts trying to find those email addresses so that you can update them.  You don't even need to touch the alert.

While this method takes a bit more time and thought to get up and running, it saves you so much more time in administration of these pesky alerts than it ever cost you setting it up.

We have a really big environment and used to have well over 200 alerts.  So many of these alerts were duplicates or were going to people that hadn't worked here for a long time.  We have been condensing all of our alerts using a method similar to the one I describe above and it is amazing.  We are down to less than 70 alerts and falling.  We plan to have less than 40 alerts when we are done (we have every module including SAM so we still need lots of different alerts to cover all the different object types).

By the way, if there are interfaces you don't want to alert on in your single "Interface Down" alert method I describe creating above then in the scope you can filter out any interfaces you don't want to alert on or, better yet, you can go into Manage Nodes, change it to Interface mode, select all of the interfaces you don't want to alert on when down, click Edit Properties, and set them to become Unplugged when down.  When an interface has this selected it will simply go into an "Unplugged" status when it is down and therefore not be alerted on.  Or, you can create another Interface Custom Property called AlertSuppression, make it a True/False property, go into the Custom Property Editor and set everything you don't want alerted on to TRUE, then in your alert scope just put "AlertSuppression NOT EQUAL TO TRUE".  We prefer doing it this way because the Custom Property Editor is so much easier to bulk edit things in than the Mange Nodes manager is.  Either way works though.

spx13320​ Yup, what he said ^^

Well i'll take a look so I appreciate the response, haven't had time yet to read the whole thing. However I did read the first part and I have to ONLY alert of nodes that start R1 and R2 (case does not matter) and ONLY the interface with Qwest  on the specific interface on those devices, so it's not redundant.

Nope, no difference.

Have not tried the wildcard yet, might be the easiest thing for me to test next.

Did you change Interface Name to Interface Caption?  That's the main thing that is keeping your alert from working.  Interface name is "Serial 0/0/0".  The word Qwest can't be found in it.  The word Qwest is in the Description, which will be in the Interface Caption.  So you can change the alert to read either "Interface Caption" CONTAINS Qwest or "Interface Description" contains Qwest and it should work.  I would go with Caption though as that is used more commonly.