Check out this new Technical Reference on Understanding Orion Advanced Alerts.
The suppression is tied to the trigger condition, so it can be as specific as the trigger.
This is a wonderful guide, thanks for posting this.
One question I still have regarding suppression;
Is the suppression an open ended query that can be met by any object or set of objects in the database that if met will suppress the alert or is it specific to the object that triggered the alert in the first place?
If the first is true then the example in the guide of a suppression versus a suppression embedded in the Alert Conditions are not the same. The first would look through the entire database for any interface that met the condition where as the second would only look at the interfaces on the device that triggered the alert.
And then there is the third possibility of me completely not understanding something here. = )
Per this post: and based upon my experience, I was under the impression that the suppression was not related to the triggering object(s) and could be met if the condition is true for any object in the database.
Hmmm. I'll have to check with dev on that one
You are correct in that the entire db is scanned for the suppression condition but this is done as a combined query with the trigger condition, so the two examples would be equivalent. (Unless there is a nuance I'm not getting)
So, if I had the following alert and suppression for that alert, would it suppress the alert for only the node named Bob and still notify me for all other nodes where the CPU was greater than 90 or would it always suppress the alert so long as a node existed in the database named Bob?
In my experience it would suppress all alerts so long as there was a node in the database named Bob.
Trigger when all of the following apply
CPU Utilization is greater than 90
Suppress Alert when all of the following apply
Node name is equal to Bob
If I may interject please. Based on the understanding that suppression is based on a separate DB query, it appears that it may be good general practice to "suppress' using the proper logic qualifiers on the Trigger tab so as to be more specific. It would seem all too possible to create suppression conditions that are less specific that none desires.
If that sounds like a wise approach, then there is an even greater case for using well designed custom properties than ever before. If one tries to accomplish "suppression" on the Trigger tab rather than the Suppression tab, the list of suppressions could get quite long, depending on the situation. Therefore, custom properties would come in quite handy in maintaining functionality and sanity!
Thoughts?
Borgan
Firstly I just have to say that your avatar makes me laugh every time I see it!
As far as your points are concerned, I completely agree. In most (probably all) environments smart use of custom properties will make handling alerts much easier and coherent.
As far as how suppressions are handled, I (think) can see cases for both doing them via the suppression tab as well as building them into the alert itself; however, once again in either case good use of custom properties is going to make all the difference in the world.
Thanks Byron. That is a pic of my grandson!
Back to the subject at hand. So, lets try a simple example to see if we are on the same page.
Say you have a network of one switch with ten attached nodes. You also have 10 other nodes that are not attached to that switch.
Then you construct a node down alert for all 21 nodes but include a suppression condition for the switch-attached nodes based on the status of the switch. With our current proposed understanding of the nature of the suppression SQL query, we will NOT get a node down alert for ANY node, not just for the nodes attached to the switch. In other words, the suppression condition assumes a universal dependency which in fact does not exist.
In the real world, there will be many switches or other upstream devices, each with dependent devices. So, the challenge becomes how to configure suppression that is specific, yet all-inclusive.
Are we looking at more alerts, rather than less alerts to get this done?
