Tag: alerts

Let’s talk notifications for a minute.

Everyone complains that a tool is noisy for alerts (typically emails).

Why not find a way to limit what you receive, and eliminate, the noise.

Sure, there’s alert tuning, but there are a ton of built-in options with Subscriptions in SCOM.

Let’s Start by talking about now a subscription is built in SCOM.

Step 1 – An owner (or ‘subscriber’) is needed

This can be an email address, group name or variable you may want to pass to a command line for a destination (e.g. support team/NOC/POC)

Step 2 – A channel is needed (simply put, a way to get the data out of SCOM)

This can be SMTP (email), or a custom executable to a ticketing system, NetCool, BMC True Sight, xMatters, Derdack, to name a few.

Step 3 – Criteria to send to an owner (details)

Time to set up a subscription, and learn as we go!

Do you have the necessary 3 parts (subscriber, channel)

Do you have a destination/subscriber already set up?

Yes, see go to Channel

No, follow the subscriber blog here

Do you have a channel set up

Yes, see go to Subscription

No, follow the Channel blog here

Do you have a naming convention for the subscription parts?

The Subscription name needs to be intuitive, i.e. Application Name, Team Name, Company Name (depending on the environment)

Process an Application’s alerts

Example     ‘BizTalk alerts’

If BizTalk alerts needed to go to different teams

‘BizTalk DEV Alerts’ or ‘BizTalk PROD Alerts’

or if Criteria is involved ‘BizTalk Performance Alerts’

or if alerts need to route to another company ‘Contoso BizTalk alerts’

Capitalize what needs emphasis so in the Subscriptions view (make searches or sorts easier and more intuitive)

Making sense where I’m going with this?

Criteria can influence the name

CLASS, MONITOR, RULE, SEVERITY, GROUP, RESOLUTION STATE

To me the value comes in with the Description field in a subscription.

Adding relevant detail here makes life easier when followed, to know what the subscription is doing.

Try this model for the Subscription Description

CRITERIA

SUBSCRIBER

COMMENTS

Example

+MONITOR = Health Service Heartbeat Failure +SEVERITY = Warning/Critical +RESOLUTION STATE NOT equals 255 +SUBSCRIBERS = GROUP Server Admins via Email +Comments: Created 2016-02-12 for SCOM Agent tuning

Time to set up a subscription

Subscription Summary Healthservice Watcher subscription to alert on any NEW Healthservice Heartbeat failures

Name     SCOM HealthService Watcher

Description

+MONITOR = Health Service Heartbeat Failure +SEVERITY = Warning/Critical +RESOLUTION STATE NOT equals 255 +SUBSCRIBERS = GROUP Server Admins via Email +Comments: Created 2016-02-12 for SCOM Agent tuning

Criteria

Notify on all alerts where

created by Health Service Heartbeat Failure rules or monitors (e.g., sources)

and of a Warning or Critical severity

and with Not Equals 255 resolution state

Subscribers

GROUP Server Admins via eMail

Channels

SMTP Channel