Developing Microsoft System Center Operations Manager 2007 Management Packs
Developers are best suited to building application monitoring features. On the Microsoft platform, that means building Management Packs complete with a Service and Health Model.
Models and Modeling are hardly the terms you equate with the Information Technology industry. Yet, modeling is exactly what you need to learn to build Management Packs for Microsoft Operations Manager 2007. Microsoft's new holistic model-centric approach is a complete departure from the server-centric ways of Operations Manager 2005 (MOM).
In this article, I'm going to build a simple management pack from the ground up and show how application instrumentation and modeling come together to monitor the health of your Enterprise Applications.
System Center Operations Manager 2007 Overview
A complete introduction to Operation Manager is beyond the scope of this article, so I'm just touching on the basics. For a complete introduction, see the Resources section at the end of this article.
If you've ever built a web application, desktop application, or connected an application to a server database, you know the health of your application is contingent on the servers and databases hosting or connected to your application. For example: Your web application may be online, but if the database the application is connected to is corrupted, your whole application is effectively offline.
Operations Manager monitors the health of the distributed components of your application spanning the client, server, and even the network; tying everything together in dashboard-like views. Figure 1 depicts the components of Operations Manager.
Figure 1: Operations Manager Architecture
As you can see, parts of Operations Manager exist on the system being monitored and parts exist on the Operations Manager server. An Agent Service runs on any machine being monitored by Operations Manager.
Ops Manager sends instructions to the Agents running on a monitored machine. Instructions normally consist of things like gather specific events in the event log or periodically sample specific data from Windows Management Instrumentation. The events or readings are sent back to the Ops Management server and, based on the information, Ops Manager raises alerts or simply stores the information.
Not Your Grandfather's Modeling
Ops Manager ships with a standard set of Modules. Modules are the basic building blocks capable of monitoring and collecting information from various software instrumentation components such as event logs, performance monitoring, and Windows Management Instrumentation.
Mixing and matching the various Modules using a XML modeling language called System Definition Model (SDM), Management Packs describe what to monitor (Service Model) and how those components are monitored (Health Model).
Ops Manager and many of its other products ship with some standard Management Packs. Developers often build their Management Packs on top of these standard Management packs.
The Service Model describes a set of classes and class properties. The notion of classes is very similar to the Object Oriented development (OO) notion of classes; however, the physical implementation of the classes is different. Like the OO notion, classes extend an existing abstract class. You'll look at classes in more detail later in the article.
The Health Model describes how to monitor an application (Monitors). Monitors collect application state information like: whether the application is configured correctly and whether all the components composing an application are running. Typical application states are Critical, Warning, and Healthy.
Aside from the Service Model classes, almost all other Management Pack components are built from Rules. Rules, put simply, make everything go. So, for example, Discovery Rules instruct Ops Manager where to look to find a Class and populates properties. Alert Rules notify an administrator to a particular problem and can be initiated by a state change to a Monitor.
Now, I'm going to build a simple management pack from the ground up to show you how all these ideas come together.
Some Basic Instrumentation
Although you can monitor basic aspects of an application or the server an application is running on, you really need to implement instrumentation in your application to effectively monitor your application from Operations Manager. A complete discussion of application instrumentation is beyond the scope of this article, but you'll find helpful resources listed at the end of this article.
The sample application performs two instrumentation actions:
- Writes keys to the Windows Registry so Operations Manager can locate the server hosting the application. The application logs a version number and a display name. As you will see later, this information will appear in Operations Manager.
- The application logs "Errors" to signal a problem and "Information" to signal the problem is corrected.
Below is some sample Registry code.
RegistryKey rkey = Registry.LocalMachine.OpenSubKey("Software", true); RegistryKey rkeyEntries = rkey.CreateSubKey("TestGenerateEvents"); rkeyEntries.SetValue("Version", "1.0"); rkeyEntries.SetValue("ProductName", "TestGenerateEvents"); rkey.Close(); rkeyEntries.Close();