Alert Suppression

Alert Suppression in terms of Orion can be confusing. Orion takes suppression to mean Router A goes down so do not alert me to all downstream devices cause I will assume they will be down as well due to Router A. Example can be found on Orion Guide page 281.

I think you mean suppression as "Do not alert in certain cases".

I believe that you can accomplish what you are looking for in the Trigger Condition statements of the advanced alert. My suggestion would be to try something like the following:

Trigger Alert when all of the following apply
Node Status is equal to Down
Trigger Alert when any of the following apply
      custom_property1 is equal to value1
      custom_property1 is eaual to value2

The trick here is to list all possible values of your custom property but the one that you do not want to be alerted on.

As for empty values in your custom property you can easily filter, sort and update your custom properties in bulk with custom property editor on your Orion machine.  Check my post on this thread to see how you can use filters and copy paste to edit MANY custom property fields at once.

Its tough to really see what you are trying to do without knowing your Trigger Condition. If you could post it I may be able to help more.

Hopefully this made sense its still early here. :)

Trigger Alert when all of the following apply Node Status is equal to Down Trigger Alert when any of the following apply       custom_property1 is equal to value1       custom_property1 is eaual to value2

Suppression is a bit misleading when you first run into it, unfortunately. I think it should be expanded to handle this type of case as well.

What you have posted is essentially what I have, except I exclude a single type instead of including all:

Trigger when all the following apply
Node Status is equal to Down
Node is critical
Custom Property (Equipment Type) is not equal to value (excluded type)

The difficulty is that I am not the only person that manages NPM and there isn't any built in functionality to enforce constraints on the custom properties. With the method I currently have if the Equipment type property isn't set the alert isn't triggered (found that one out the hard way...). With your method if someone else adds a device and doesn't consider alerting and ensure the type is added to the list, or mangles the property somehow the alert isn't sent. In either case it is easy to miss an alert on a potentially critical piece of hardware.

If I could suppress the alert in the case that a custom property (or any property really) could be limited to the single node in question it prevent the above failures.

Alternatively if a lack of a value would evaluate a bit differently this could be somewhat avoided as well. i.e. If the Custom Property is not set (so == ""/NULL), custom_property not equal to value1 (where value1 is defined) should evaluate to TRUE. I suspect (but haven't double checked to verify) that the current behavior may be caused by storing a NULL in the database and so the condition is not evaluated. This seems somewhat misleading since it is possible to select NULL or nothing as the value for the comparison from which I assumed that the comparison would evaluate as I described here.

However, I feel it would be much more intuitive to suppress alerts based on node specific information, rather than creating a convoluted set of inclusive checks in the trigger condition.

I can think of a great number of cases where I would like to suppress an alert based on conditions that exist for that particular node only:
- special class of devices such as this
- testing or maintenance window work where you still want to monitor a node but don't want to receive alerts and so don't want to unmanage the node.
- Want to exclude a single specific device from an alert for some reason

The strength of Orion's alerting engine is that it is very easy to configure an alert that applies to everything...

The weakness is that it is very hard to tailor a specific alert for specific nodes/types of nodes/cases/etc as this quickly becomes an incredible burden on the database (many connections, etc) and becomes very difficult to manage the rapidly expanding list of alerts.

I know where your coming from but I still think this is possible using Advanced alerts. After seeing your Trigger I have a suggestion. It's hard for me to test it on my system because I do not have a similar case or custom property to test with.

Trigger when all the following apply Node Status is equal to Down Node is critical Custom Property (Equipment Type) is not equal to value (excluded type)

As it stands now all of those conditions must apply before the alert is triggered. So this will not allow for adding more "exluded custom properties". I also noticed that there is a "is empty" feature for custom properties.

Maybe this?

Trigger when all the following apply
Node status is equal to Down
Node is critical
      Trigger when any of the following apply
      custom_property is not value1
      custom_property is empty

I belive this would give you: Any node that is down, critical and either not value1 or empty. If you wanted to exclude another custom_property you would just add custom_property is not value2 under the value1 exclusion.

Let me know what this does or if this works. It gets really confusing. I usually write down and diagram the logic to better figure it out. Maybe that will help.

The logic isn't usually too bad, it is how the alerting engine interprets the information that is provided that gets tricky.

I hadn't thought of adding the "not set" condition. That might just work too. I'll test and report.

Trigger when all the following apply Node status is equal to Down Node is critical       Trigger when any of the following apply       custom_property is not value1       custom_property is empty

That appears to work as expected. Good deal.

Now if suppression worked the way I wish it would I wouldn't have to duplicate the conditions in the reset conditions too! :)

Thanks for the suggestion

Glad it worked for you.