It’s a discussion. A strong suggestion. Look at the MP docs MS puts out with
their management packs and create a simplified one for every MP you create.
Write/Update it in parallel with creating the monitors. It will pay off in the
long run. It can also be used to show work.
This is a give and take process. Some things are simple, but I require each
requestor to provide the information and help work out the details of what I
can give them. The do have to provide, what they want monitored (service, log,
process) and how big an issue it is (wake up on call, ticket, email -
Critical, Warning, Info) and the basic instructions for every alert. Because
really, at 2 am for some strange application I never work on, what am I suppose
to do when event log entry is 934? At least get a starting point.
Oh yea, we have another rule. The recipient team of the alert must agree to
receive it. If they don’t then the requesting team gets all of them. If there
is a dispute on who gets the alerts, the management of the two teams work it
out. I am neutral, not my issue to solve. Also these fights are a major time
sink and I am to busy dealing with figuring out how to create these monitors to
mess around in meetings over who gets the alerts.
My simplified doc has - [I have now written two of these 😊 ]
Title Page with Name, date, author version
Revision history table
Introduction to NAME MP (generally just one or two paragraphs describing it and
the naming the people who requested it and worked on it together for reference.
Supported Configuration (SCOM 2007 / SCOM 2012r2) and the name of the files.
somename.mp, somename.override.xml
Discovery - how it works / classes
Monitoring and Alerting - general overview of the overall process for this
monitor, sometimes has Visio diagram for alerting
Each and every monitor has something like this -
Name
FooBar Service Monitor
Health States
Service running - Healthy
Service not running – Critical
Alerting
Alert in critical state
Alert Name
Alert FooBar - Service not running
Alert Description
The FooBar service is no longer running on
$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$
Instructions:
REF: link to doc site (we have a do site for the more complex in house apps)
1. Contact the [TeamName] OnCall and request they restart the service.
2. Assign ticket to GROUP
NOTE
Unique stuff here
From: Pete Hakesley
Sent: Tuesday, June 2, 2015 1:04 AM
To: [email protected]
Hi
Would be interested in your questions!
We are also struggling with an on-boarding process and monitoring take on
process within our business.
Peter Hakesley | Monitoring & Automation Technical Lead Engineer, Data Centre
Services
t: +44(0)845 155 6556 ext: 4006
e: [email protected] | w: www.scc.com
a: SCC, CV1, Cole Valley, 20 Westwood Avenue, Tyseley, Birmingham B11 3RZ
From: [email protected] [mailto:[email protected]] On
Behalf Of Orlebeck, Geoffrey
Sent: 01 June 2015 22:22
To: '[email protected]'
Subject: [msmom] RE: Responsibility for Monitoring
Thank you everyone for the replies. I’ve come up with a rough outline of
questions to pose to our department whenever they want something monitored or
something new is being introduced. This definitely helped me scope the outline
appropriately. Thanks again.
-Geoff
From: [email protected] [mailto:[email protected]] On
Behalf Of Gareth Miles
Sent: Thursday, May 28, 2015 10:46 PM
To: [email protected]
Subject: [msmom] RE: Responsibility for Monitoring
Hi Jeoff
I work for an online gaming company, we have a diverse number of technical
departments, flash, web, dba, security, comms, desktop, server etc etc. Like
you, monitoring has historically been a last minute thought on most projects.
About two years ago we started to create awareness in SCOM and other monitoring
tools we use, the benefits of including a monitoring person from the beginning
of design i.e. structuring EventID’s appropriately to work well with SCOM and
identifying scripts that need to be written to supply to the monitoring team in
order to effectively monitor aspects of the final product. We now have this
working well, monitoring is part of most new projects.
General requests come through traditional channels, more in depth request
require a sit down to discuss what is required and what can and can’t be done.
In my mind, effectively monitoring with SCOM requires knowledge in SCOM, vbs,
xml, registry, sql, wmi, powershell. With these, as long as the requester has
given decent info and supporting scripts, you can monitor pretty much anything.
That said, although I know sql, I wouldn’t battle trying to figure out how a
certain product works, I would expect the requester to provide that, and adapt
what’s provided to work with SCOM.
I hope that helps.
Cheers
Garerth
From: [email protected] [mailto:[email protected]] On
Behalf Of Orlebeck, Geoffrey
Sent: 28 May 2015 11:24 PM
To: '[email protected]'
Subject: [msmom] Responsibility for Monitoring
I’m pretty new to SCOM (less than 6mons) and I was wondering for the more
experienced SCOM folks, how does responsibility for creating monitors work at
your company?
What I mean by that is, does an admin/analyst come to you and simply say “I
need to know about _x_” and it’s up to you to work out how to target and
achieve that goal? Or do you ask for guidance about how to discover and/or
monitor that request before you agree to start? Can users make direct requests
or must they go through an approval process of some kind?
I’ve just had a couple instances where I get “I need to know when ______
fails”, but no real direction beyond that. If I ask, they may or may not know
much about it, and I end up researching to figure it out and make it work.
That’s not a complaint, I’m just curious if where you work there is an expected
standard the admins/analysts have to meet before the creation of a rule/monitor
starts.
Is it a 50-50 collaborative effort with the requestor(s)? Do you try to get as
far as you can before reaching out? I just know I’m not an expert in all the
areas, so I need to lean on others’ knowledge of a particular system or
component and how it works.
I’m really curious how SCOM is treated in other companies and what works best
for them. SCOM has been an afterthought here for a long time and I’m trying to
leverage the potential I see with SCOM. I’d like to get a dialogue going with
our staff so we can really make this work well. Thoughts and opinions are
welcomed! War stories or pitfalls to avoid as well.
Thank you.
-Geoff
Confidentiality Notice: This is a transmission from Community Hospital of the
Monterey Peninsula. This message and any attached documents may be confidential
and contain information protected by state and federal medical privacy
statutes. They are intended only for the use of the addressee. If you are not
the intended recipient, any disclosure, copying, or distribution of this
information is strictly prohibited. If you received this transmission in error,
please accept our apologies and notify the sender. Thank you.
The information transmitted is intended only for the person or entity to which
it is addressed and may contain confidential and/or privileged material. Any
review, retransmission, dissemination or other use of, or taking of any action
in reliance upon, this information by persons or entities other than the
intended recipient is prohibited. If you received this in error, please contact
the sender and delete the material from any computer.
Furthermore, the information contained in this message, and any attachments
thereto, is for information purposes only and may contain the personal views
and opinions of the author, which are not necessarily the views and opinions of
the company.
Confidentiality Notice: This is a transmission from Community Hospital of the
Monterey Peninsula. This message and any attached documents may be confidential
and contain information protected by state and federal medical privacy
statutes. They are intended only for the use of the addressee. If you are not
the intended recipient, any disclosure, copying, or distribution of this
information is strictly prohibited. If you received this transmission in error,
please accept our apologies and notify the sender. Thank you.
