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

Alert Suppressions

We are having problems with alert suppressions. There are three types of issues:

1. A 'Tiered alerting' where if you cannot get past the core switch(its down or unreachable) , do not alert on the devices beyond it. If you can get past the switch, but not past the firewall, alert on that but not all the nodes in your remote sites. And so on. I had this problem before hand and brought it up only to be told a new condition "unreachable" (or some such) would come out with v9 and I could simply suppress the alert if "X was unreachable". I cannot find any such condition and I am wondering if the improved the SQL queries well enough to put complex suppression statements in and have them work.

2. All of the existing alerts we had before going to 9 got a suppression condition added (if Node = Unmanaged) which I had thought was an implied condition, not one that had to be explicitly stated. Is this required now? Also, the existing alerts didn't work after the upgrade; we had to replace the existing email addresses with new ones and then swicth back before they would fire and send off email.

3. We have several APM alerts (if APM APP = Down, alert) that generate email notifications. Sometimes if they are associated with a Node and that node is in unmanaged mode, the alerts will trigger and sometimes they will not. Is there a way to make this consistent? I know the alerts based on the APM will not allow me to put in custom node properties so I am not sure how well it integrates with the NPM.

Thanks in advance for any help.

Find more posts tagged with

Accepted answers

All comments

FormerMember

. A 'Tiered alerting' where if you cannot get past the core switch(its down or unreachable) , do not alert on the devices beyond it. If you can get past the switch, but not past the firewall, alert on that but not all the nodes in your remote sites. And so on. I had this problem before hand and brought it up only to be told a new condition "unreachable" (or some such) would come out with v9 and I could simply suppress the alert if "X was unreachable". I cannot find any such condition and I am wondering if the improved the SQL queries well enough to put complex suppression statements in and have them work.

We are planning to add that feature, but it was never scheduled for 9.0.

2. All of the existing alerts we had before going to 9 got a suppression condition added (if Node = Unmanaged) which I had thought was an implied condition, not one that had to be explicitly stated. Is this required now? Also, the existing alerts didn't work after the upgrade; we had to replace the existing email addresses with new ones and then swicth back before they would fire and send off email.

Are you saying that this condition was added during upgrade?

3. We have several APM alerts (if APM APP = Down, alert) that generate email notifications. Sometimes if they are associated with a Node and that node is in unmanaged mode, the alerts will trigger and sometimes they will not. Is there a way to make this consistent? I know the alerts based on the APM will not allow me to put in custom node properties so I am not sure how well it integrates with the NPM.

These shouldn't trigger if the node is unmanaged. Could you open a Support ticket on that one so that we could gather more info?

BBNOC

We are planning to add that feature, but it was never scheduled for 9.0.

Well I called in and that is what the guy on the phone said when I was trying to explain that my alert suppressions would not work. And no, I do not know who it was. We are still trying to suppress alerts based on these points:

If you can't get to the data center core switches, only alert on core switches (we have two in a redundant setup), not everything beyond. If you can't get past the Data Center firewall, only alert on the firewall and anything inside it, not the nodes beyond. If the remote office Firewall is down, alert on it but not the nodes beyond. If the you can't get past the remote office switch, alert on that but not the nodes beyond it.

When I tried setting that up before I was told it was too complex for the SQL query to run before the alert fired.

2. All of the existing alerts we had before going to 9 got a suppression condition added (if Node = Unmanaged) which I had thought was an implied condition, not one that had to be explicitly stated. Is this required now? Also, the existing alerts didn't work after the upgrade; we had to replace the existing email addresses with new ones and then swicth back before they would fire and send off email.

Are you saying that this condition was added during upgrade?

yep. I made 90% of the alerts here and none of them had a suppress if Node = unmanaged. And none of them alerted if the node was unmanaged. But now all of them have that line.

3. We have several APM alerts (if APM APP = Down, alert) that generate email notifications. Sometimes if they are associated with a Node and that node is in unmanaged mode, the alerts will trigger and sometimes they will not. Is there a way to make this consistent? I know the alerts based on the APM will not allow me to put in custom node properties so I am not sure how well it integrates with the NPM.
These shouldn't trigger if the node is unmanaged. Could you open a Support ticket on that one so that we could gather more info?

I will in a couple of days though honestly I have been less then impressed with the support when I call. After two different TSRs calling me 'dude' and the 'cannot reach' condition not being available in 9, I don't have a lot of faith with your support. But I will give it another whirl.

FormerMember

The part about the "unmanaged" line is really weird because we definitely didn't touch that part of the code. So we can't figure out where that could come from.