Peter:
I wrote these up as a way to open a dialogue with people that hopefully have
far more knowledge about an application than I do. We do just about zero
software development, so almost our entire monitoring revolves around
commercial software. Again this is just my own personal rough draft, and I
don't expect to hand these questions to someone and walk away, this document is
my personal reminder of topics to cover during the conversations surrounding
SCOM. With all that said, I hope they help you craft a set of questions for
your own environment. Here is what I have currently:
Questions for Writing the MP in SCOM:
1. Application name and basic overview of what the application does?
2. What are the components of the application?
a. What are the properties of each component?
b. How are we going to populate properties?
i. Example:
Populating DB names of a SQL Instance.
3. How are the component(s) related?
4. How can we identify the component(s)?
a. Registry, WMI, Script based?
Questions for Vendors and/or Analysts for Monitoring via SCOM
1. Generally, How can you best determine if the application is
functioning or not? Can that be assessed with an automated check? (Stolen from
Henrik's email on this thread, which is a much better general question to lead
with. I ended up moving all my previous questions to be sub questions under
Henrik's, as mine were just more specific to help others think about what
should be monitored at a basic level, but an open ended general question is a
great jumping off point).
a. What application services are critical and should always be running?
b. Are any events written to the Windows Event Log that would indicate a
critical problem for the application's functionality?
i. If yes,
are the Event ID, Source, and Description that will be used to indicate a
critical event already known?
c. Are there any critical processes that should be monitored?
i. Should
there be a minimum/maximum threshold for the number of processes running at any
given time?
d. Conversely, are there any processes that only run when an issue has
occurred?
i. Example:
A debug process launching when the application quits unexpectedly or a crash
log collection process-something running under its own named process for which
we can monitor?
e. Does the application have any txt/log files we can parse for specific
string(s) to raise alerts?
f. Any SQL queries to alert when criteria are met and/or thresholds are
exceeded?
Thanks,
Geoff
From: [email protected] [mailto:[email protected]] On
Behalf Of Pete Hakesley
Sent: Tuesday, June 02, 2015 1:03 AM
To: [email protected]
Subject: [msmom] RE: Responsibility for Monitoring
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]<mailto:[email protected]> | w:
www.scc.com<http://www.scc.com/>
a: SCC, CV1, Cole Valley, 20 Westwood Avenue, Tyseley, Birmingham B11 3RZ
From: [email protected]<mailto:[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]>
[mailto:[email protected]] On Behalf Of Gareth Miles
Sent: Thursday, May 28, 2015 10:46 PM
To: [email protected]<mailto:[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]>
[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.
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.
