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

Unmanaged nodes triggered alerts???

ahthomas

I unmanaged a large group of nodes for a maintenance window. Even though the showed as unmanaged, and went unmanaged an hour before the alerts happened, the alerts still triggered. How does this happen, and how does one prevent this from happening again?

Using NPM 10.3, Windows 2008 and SQL 2008 Enterprise.

Find more posts tagged with

Accepted answers

All comments

ChrystalT

Have you opened a support ticket on this? If not, then I would. The alerts should be ignoring the unmanaged nodes.

Please post back with your results from support.

Thanks,

Chrystal Taylor

http://www.loop1systems.com

ahthomas

I did. They didn't really know what the problem was.

FormerMember

I opened a ticket for this same problem today

Update for Case #364892 - "Bad Alerts"

danielleh

Thank you for posting back with your ticket #. Please keep us updated on your progress with support.

Thanks!

FormerMember

They suggest adding condition for status not equal unmanaged. UN-acceptable. NPM never behaved like this for us and now our NOC is getting bogus alarms resulting in people paged resulting in people not happy being woke up in the middle of the night. So now we are scrambling to try and find an eval of another product so we can use it until NPM alerts are fixed.

FormerMember

Got another email saying

Edit your advanced alert and add the following trigger condition:

Node/interface Status is not equal to Unmanaged

I asked for the ticket to be escalated since NPM has never behaved like this for us.

FormerMember

So the problem I was having this time around occurs when you put something in unmanaged after the the alert has already triggered.

GZhytar

Folks,

closing the loop here - we cleared the misunderstanding and ticket is closed. In a nutshell, when the node/interface is Unmanaged, it only means node/interface is not polled. As a side effect the alerts are not triggered, because the alert engine does not detect any change on the node/interface (as it is not polled). However, when a new Advanced Alert is created or the conditions are edited on existing alert, the alert is triggered and all alert actions are performed as it does not check to see if the node/interface is unmanaged. This is by design and is pretty much the same in all previous NPM versions.

, thanks for bringing this question, I hope this info will be useful for other folks as well.

FormerMember

Please note the order of my replies in this thread are out of order. The explanation of why this happens to us makes sense and there is a way to get the false's cleared out so they don't come back

jmayrand

I agree on this.

If a node is set into maintenance the business rules on the backend should remove the active alerts not just block future alerts. Seems like a simple feature request to me. We are dealing with this quite a bit. But again not knowing the original design intentions there could be a reason why SolarWinds chose to go this way. Perhaps a configuration check box that lets you determine the behavior you want and if node is in maintenance after the alert has triggered clear it or not?

RichardLetts

Historically Solarwinds had a lot fewer alerts and they all checked the node status explicitly if the alert needed to be disabled when the node was unmanaged.

The behavoir has not changed, it's just that

1. we've gained more out of the box alerts,e.g. environmental alerts, stack ring alerts, and the check of condiions on these alerts has not been 'fixed' to take into account the unmanaged or maintenance node status

2. the out of the box alerts have become uneditible, so the quick fix we did once (and forgot about) on a shipping alerts not becomes more work than simply editing the conditions.

jmayrand

In reading my response I agree I did not answer what you were saying. But I think we agree on one thing and that is we should not have to implicitly tell an alert to ignore maintenance items that behavior should be OOB. We have been going through all our alert rules to add this that if in maintenance do not process the alert. This should be default behavior...

Is that what you were describing?