SCOM and Distributed Applications: Associating Components

It's hard to believe it's been close to a month since my last post, with SCOM R2 rolling out things are busy at BridgeWays as we work with people and help them extend OpsMgr into areas where in many cases they had limited, proxy based, or in the worst case no monitoring at all.  What's proxy monitoring?  That's when someone else tells you whether or not the service is running well and is most often the case when a service is using a back-end like Oracle where the tools are very expensive and the systems admins have no direct view on the data.

With the new management packs that we provide this lack of monitoring is being addressed because you can now pull Oracle, Apache HTTP, JBoss, MySQL, etc into Operations Manager ... goodbye incomplete and fuzzy information, how many times have you tried correlating data from different tools and lost hours or days of your life that you really wish you could get back.  That's why people like what they see when I roll out distributed applications that I build through the Distributed Application Designer (DAD).

The next series of posts I'm going to make will be centered around DAD. Things like how to build out nice models, how to control the data that is rolling up through the Availability health model, how to extend the application to also roll up Performance health, basically how to take the individual management packs and build an application specific service model and health model that filters out the alerts that have no impact on the application you want to monitor directly.

So where to start... the first place is with a video blog that Maarten Goet published a while back, this will walk you through the initial creation of a distributed application through DAD.  Before I put down the link to Maarten's post I want to highlight a few things about distributed applications in general:

1. Save your distributed application into its own unsealed MP.  Do not save it into the Default overrides MP.  Create a new management, this will make things much cleaner in the future when you need to maintain it.
2. Finding the components you want to put into your model can sometimes be a bit of a challenge.  Before you start modeling take some time to go through the object hierarchy.  The better you scope your components, the more maintainable your application will be long term.
3. Avoid using high level parent objects for availability when you really want to look at a child.  An example of this is a web server and all the hosted web sites, keep things as specific as possible since the goal is to scope all the errors to the context of the application we want to monitor.  If you bring in the Web Server, you'll get the alerts rolling up from all sites not just the ones that are part of the service you are modeling.
4. Building out the application using DAD is only the first step, once we have our application in place we still need to build out our service model.
5. When building the service model, avoid reusing existing performance views.  I'll talk directly to this in a follow up post, the main point is that if you leverage existing views, you ar not getting a copy of the view, you are getting a pointer to the view which means changes to the view in either MP will be reflected in both service models making it difficult to have dashboards that are properly scoped.
6. Currently in R2 you have to save perspectives (for example a Web Application synthetic transaction that you created) to the Distributed Application MP, you can add them as a component in your application model.

With those basic ideas in mind, here is the link to the video blog that Maarten put together: http://www.techlog.org/archive/2007/07/01/blogcast_operations_manager_20/blogcasts

In Part 2 I'm going to go over some of the things you should consider when you make your Distributed Application Model.

Part 1 - Associating Components
Part 2 - Building the Service Model
Part 3 - Building Custom Views
Part 4 - Building Performance Views
Part 5 - Service Level Objectives

 

Comments

[nike shox]

Currently in R2 you have to save perspectives (for example a Web Application synthetic transaction that you created) to the Distributed Application MP, you can add them as a component in your application model.