nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials
Store

Do Alert Suppression's really work? (9.5.1)

FormerMember

I have yet to have alert suppressions work in any version of Orion. The alert fails to trigger at all if I use one.

For instance, since there isn't a 'not contain' I used the suppression to set 'Node Name is equal to DEVICENAME' but when I do the alert never triggers. If I take it out it works.

Thoughts?

Find more posts tagged with

Accepted answers

All comments

Questionario

the alert suppression is like a separate condition statement.

if you enter node.caption = ABC, it will suppress the alert if there is a node which caption is ABC.

you could create a suppression whenever node ABC is down, you have to add the condition that the status equals to down then (in addition to noce.caption = ABC). then the alert would not ever trigger if node ABC is down.

what you probably want though is to only exclude node ABC from being alerted upon, this you would define in the trigger statement, not in the alert suppression. just add a condition that node.caption is not equal to ABC.

let me know if this explanation helped

LGentile

I use suppression fairly extensively to suppress servers that are down when site routers are down (thus servers are unreachable). Since i'm still on v10 SP1 i don't use the new dependency method (something I am really looking forward to using).

The key here is the logic. Remember that the conditions are checked across the entire database, so if you say something like 'Node Name is equal to xxx', so long as that condition is true, the alert is supressed (in your case, so long as that node exists in your database, that alert will never trigger).

What I did was use a custom property. I don't know what your reason/usage of suppression is, mine is for router outages as I said.

So, I created a custom property called 'Metric' and I assigned all routers a number (say, 20). Servers get assigned 100 (the numbers mean nothing, it's just a way to differentiate which sites i have set up this way and which alerts are used - the alerts check for the metric #).

Anyhow, I also use the City custom property so I can do a double check for the location of a node and whether the router is down.

So my logic looks like this: (looking for a node down event and suppressing where I don't need to know about it due to a network outage):

TRIGGER:

If Node Status = Down

City contains 'Cleveland, Ohio'

SUPPRESSION:

Metric = 20

Status is not equal to 'Up'

City contains 'Cleveland, Ohio'

There are more checks in the alert for device type, what team cares about the device, etc.. but that's all the logic really needed for me. The Metric says it's a router. Some sites have multiple routers/buildings so the city field becomes important for differentiating, so we just add text to that field and make sure all the servers/nodes in that location have the same City values.

This may or may not help you - like I said I don't know what you want to suppress, I am guessing you just want a specific device ignored. I would suggest creating a custom property that is checked by the suppression logic, say something like a True/False field for 'Monitor_Status'. I used a similar field in our Node Down alerts - if that field is false, any node down event for that device is just ignored because the condition has to be True for the alert to trigger. Sometimes it's easier to set a specific trigger condition vs. suppressing it.

FormerMember

GREAT explanation!

I guess my 'logic' was faulty..... I had configured an alert to trip on disk space usage. Something like:

Node Status is Equal to Up
VolumeType is Equal to FixedDisk
Volume Percent Used is greater than 95

But I had the suppression to 'ignore' if it was a certain node
Node Name is Equal to ServerABC

I 'expected' it to trigger on any volume on any node higher than 95 except for the one specified. What it actually did was not trigger at all - until I removed the suppression all together.

So at the suggestion earlier I just added to the trigger NodeName is not Equal to ServerABC.

Questionario

glad i could help (if it was my explanation that helped you)

on a side note about your use-case, we use the PercentDisk_Marker custom property, for one this will change the bar on graphs on to where the "critical" value is and we use this value for alerting on disk space, if this value is empty, we alert on 80% usage, if the value is not empty, we alert on the value in this custom property, the volumes we do not want to alert on we just set to 101 (as 101% usage will never be reached).

this way you dont need to edit the alert everytime and can suppress alerting not only for specific nodes but also on specific volumes and still monitor these volumes usage statistics

LGentile

Yeah the logic can be really tricky. What I do when creating new advanced alerts is this - I sit and think 'is there ANY way this condition I am trying to ignore can possibly be true', or something like that - in other words, what could break the logic?

It took me a while to really get a handle on logic methods. I have a lot of my alerts mapped out in flowcharts to help me keep things in line.

What I would suggest for you is to add a new custom property called 'Monitor_disk' or something. In your trigger condition, just check to see if 'Monitor_disk' is true, and if it is, the alert will fire. If false, the condition is just ignored - no need for suppression.

If you want, you could also add to your trigger condition something like:

Trigger Alert when all of the following apply:

- Node name is not equal to 'NAME'

- Trigger Alert when any of the following apply:

- Node status equal to Up

.... the rest of your normal conditions...

This way, it will still skip triggering if the node you want to ignore is in there. There are downsides to both methods - for this one the alert trigger conditions could look messy over time, and each time you add a new server to the ignore list, it will reset the alert. For the earlier custom property selection, you will have to remind anyone else how to do this so it's not missed.

The good thing about custom properties is that in the Web console, it's so easy to go find all the servers you checked as true/false for disk monitoring (and the CPE i suppose).

Either way should work - i cheaped out and did the ignore method for alerts where i didn't create a special custom property. For example, I have properties to turn of different components of hardware monitoring (PSUs, etc) but not for minor components like fans and temperature - so for those alerts i wimped out and just added the first piece of 'All' logic before the actual conditions i wanted. There may be a better way, but this works for me!

byrona

There is a technical reference that SolarWinds published concerning Advanced Alerts that touches on the Suppression topic, you should check it out HERE.

netlogix

From the way I interpreted how suppression work is more of a full query on the database.

I think that suppression with the node name not equal abc is still off, because if the node abc is deleted or re-named, the alert will never fire off because there isn't a node called abc now and you will still get alerts on abc's volumes.

I am not sure if I get the whole point of suppression, but I think you want to change exclude a condition, the include definition should have something like node name not equal abc.