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

Constructing An Alert Using Groups and GroupStatusRootCause

What I want to do is:

- Create groups (e.g. Database Administration) and add nodes as applicable

- Attach application monitors as applicable to the nodes in the group (e.g SQL / DB2)

- Trigger an alert and send an email to the appropriate team (in correlation with the group) to notify them when any monitored component or application goes critical or down, including node down. The goal here is to have one all-encompassing alert defined for each group and call it a day.

I'd like to use this approach to streamline administration, using template overrides where necessary on nodes. It seems I can accomplish the above task with the ${GroupStatusRootCause} variable. However, when a node in this test group (Database Administration) has an application monitor in a state of down (i.e service down) or critical (e.g. cpu>90%), the group still shows a status of "up" (green.) This in turn renders the "Group Status is equal to Critical" or "Group Status is equal to Down" trigger useless. I'm assuming I have a misunderstanding of GroupStatus or have a setting incorrect?

In addition, I'm pretty new to this and my alert creation skills are lacking. Shouldn't something like the attached be sufficient?

Thanks in advance!

Orion Core 2012.1.0, SAM 5.0.1, IPAM 3.0, NPM 10.3

attachments.zip

Find more posts tagged with

Accepted answers

All comments

Sohail.Bhamani

Your alert structure looks good. When you create the group, if you expand the Advanced section near the bottom of the first screen, you can select a different roll up method. By default its set to mixed I believe. You could set it to show worst status and it may solve your issue.

Sohail Bhamani

Loop1 Systems

http://www.loop1systems.com

dprocopio

Thanks. Yes, I've tried changing the roll up method to worst status but it never changes in the display. The release notes for NPM 10.3.1 state "Group member status now displays correctly on reports in the web console." However, does this mean I'm only displaying improperly or status is getting recorded improperly?

I've also read elsewhere that application and component status does not roll up to the parent group object:

Nov 11, 2011

"Groups don't currently have the concept of a child status, which is what's depicted on your nodes in the screenshot above. So down interfaces, applications, etc. will not bubble up to the group status Icon unless those items are explicitly added to the group. I'll be logging a feature enhancement request for this now."

http://thwack.solarwinds.com/message/156478#156478

If this is still the case it seems rather silly...what, then, is the point of Group Status? The only way I could get the alert that I created to fire was if I took the node down. If this information could roll up I could knock my # of alerts in half, at least.

Sohail.Bhamani

Nice. I found that post as well.

For the nodes that are showing the red/yellow child status indicator, do you have the objects causing those in the group as well? If its a node related property then its already there, but if its related to interfaces, volumes, apps, etc, then it would have to be added to the group.

Also, there is an issue if you have too many groups in the current version. Before you put all your eggs into one basket, how many groups are you planning on having?

Sohail Bhamani

Loop1 Systems

http://www.loop1systems.com

dprocopio

Thanks Again!

My issue seems to be around application and component monitors associated with nodes not rolling their status up to the parent group object. I've seen that adding the application monitor itself to the group might alleviate this issue...but come on SW....that's messy and not at all why an admin would want to leverage groups in the first place. Why would I essentially want to add the same node (or monitor associated with it) to the same group several times over? I'm trying to clean up a legacy mess left to me and make management of this system easy for other IS Operations staff to reproduce. I'm also trying to keep a clean, easily readable web console. The current solution just takes the mess out of one area (custom attributes) and moves it to another (groups.)

As far as # of groups go, that is to be determined. I'd imagine no more than 10.

dprocopio

I have been advised that this feature will likely not be mature until 10.4.1, if that...

Sohail.Bhamani

Better than never though huh?

Sohail Bhamani

Loop1 Systems

http://www.loop1systems.com