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<http://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]> [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.
