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();
Below is sample Event logging code.
EventLog log; EventLogEntryType entryType = EventLogEntryType.Error; log = new EventLog("Application"); log.Source = "TestGenerateEvents"; log.WriteEntry("This error was created for testing purposes, please ignore.", entryType);
Now, you’ll build a management pack to read the application instrumentation.
Creating a Management Pack
Although you can build a Management pack from within the Operation Manager console, it’s easier to build the Management Pack using the Management Pack authoring console displayed in Figure 2.
Figure 2: Operation Manager Authoring Console
I used the Release Candidate version for this article. Building in the console allows you to build a Management Pack without running Operations Manager.
As stated earlier, Management Packs are XML files. So, alternatively, you can build a Management pack using an XML editor.
Management Packs usually contain one or more of the following components:
- A class is Operation Manager’s representation of your application. You can build custom classes or utilize existing classes.
- Discovery identifies classes on a server and populates a class’ properties.
- Monitors view the health of a class.Monitors are part of the Health Model.
Now, you’ll look at how you add each of these components to the Management pack using the Authoring tool.
Classes
Classes and Class relationships define the Service Model. As stated earlier, the Service Model is essentially Operations Manager’s representation of the application components and the class OO notion is similar to the OO development notion. Class physical implementation is very different than classes you define in, for example, C# development. Figure 3 shows how I defined a class TestDevelopment.MyApp with a Microsoft.Windows.UserApplication base class.
Figure 3: MyApp Class
In addition to properties inherited from the base class, the MyApp class has a Version Property.
Figure 4: MyApp Class Properties
Although the Authoring tool doesn’t enforce it, best practices dictate using namespace–like conventions. Classes must be unique and namespace conventions are an easy way to achieve uniqueness.
Your class example is a somewhat trivial. More complicated Service Models define multiple classes and class relationships.
Populating class properties and making Operations Manager aware of classes is the role of Discovery Rules.
Discovery
Developers are used to classes handling their own initialization, so discovery may, at first, seem a bit non-intuitive. Recall, classes are not executable code. Classes are simply an XML representation of the application.
Determining where an application is running may require multiple steps. For example, in the sample the application runs on a server. So, first Operations Manager needs to gather all the servers it monitors and then send instructions to all Agents to scan every server’s Registry for a TestGenerateEvents key. An application may run on multiple servers or it may be composed of, for example, multiple Windows Services and a SQL Server database. Figure 5 is the discovery for the sample application.
Figure 5: Discoveries in the TestManagement Pack Sample
Below are the properties of the TestDevelopment.FindTestGenerateEvents Discovery.
Figure 6: FindTestGenerateEvents Discovery
Target, a term used throughout Management Pack development, indicates what a rule should act upon to find the particular piece of information. The sample scans the Registry so the best target would be Microsoft.Windows.Server.Computer.
Setting the version requires some additional coding. $Data allows you to see properties from discovered information.
Figure 6: FindTestGenerateEvents Version property
At this point, Operations Manager has a Service Model (Class) and a means to discover the application. Now all you need is to do is build some monitoring.
Monitors
The Health Model for the sample is defined below.
Figure 7: TestGenerateEvents Health Model
The Health of an application is based on a roll-up of each of the components above. Monitors can have two or more states. Typically, states are “Warning,” “Healthy,” and “Critical.” Most applications will have multiple monitors under each Health Model category and may define monitors for completely need categories. Below is a monitor called TestDevelopment.EventLog.
Figure 8: EventLogTest monitor
All the options are defined using a new monitor wizard. The sample uses the Simple Event Wizard accessible from the Actions pane.
Figure 9: Creating a Simple Event Monitor
Errors in the Application event log events change the state of the monitor to “Warning.” Information events change the monitor state back to “Success.”
Figure 10: Matching Operational State to Health State
You configure the Event conditions above using the expressions options below.
Figure 11: Configuring Operation State to read Events
Now, you’re ready to load the Management Pack into Operations manager and begin monitoring the sample Application instrumentation.
Navigating the Console
Below is the Operations Manager Console Application.
Figure 12: Operations Manager Console
Right-click Management Packs on the Administration screen to load the Management Pack.
Figure 13: Loading a Management Pack
It may take some time for Operations Manager to run the Discovery and find the Sample application.You should see something like the information below when the application is discovered.
Figure 14: Viewing a Discovery
To see the state change, press the appropriate buttons on the Sample application to change States.
Figure 15: Application State Changes in Operations Manager Console
Your Future in Modeling
This article just covered Management Pack basics. There are more concepts and terminology to unearth in the Resources section at the end of this article.
Although they are included in the sample code, I didn’t cover View and Rule development. If you understand the concepts you have covered here, Views and Rules will be easy to grasp.
Product Knowledge is also something you need to add to a Management Pack. It can be as simple as a link to a web site.
Future releases of Visual Studio and Operations Manager will include better modeling tools, but you can start preparing today. First, include instrumentation in your application. Follow guidelines in Enterprise Library, Codeplex, and the other Patterns Practices you’ll find under Resource.
Conclusion
As the application designer and builder, the developer is best suited to Instrumenting an application. For enterprise applications, with components scattered across multiple servers, Management Packs and System Center Operations Managers are a perfect Intrumentation monitoring pairing. Management Packs are composed of a Service Model and a Health Model and constructed from modules housed in Operations Manager. Using a Management Pack Authoring tool will ease the construction burden.
Download the Code
You can download the source code that accompanies this article here.
Resources
- Authoring Console Release Candidate
- Visual Studio Team System Management Model Designer Power Tool – February 2008 Community Technology Preview (CTP)
- Enterprise Library and .NET Instrumentation Resources:
http://msdn2.microsoft.com/en-us/library/aa480453.aspx
http://msdn2.microsoft.com/en-us/magazine/cc300488.aspx
http://www.codeguru.com/cpp/data/mfc_database/sqlserver/ article.php/c12123/ - Design for Operations on Patterns and Practices: http://www.codeplex.com/dfo
- Management Pack Training Videos on TechNet: http://technet.microsoft.com/en-us/opsmgr/bb498237.aspx
- System Center Operations Manager Documentation including the Authoring Guide: http://technet.microsoft.com/en-us/opsmgr/bb498235.aspx
About the Author
Jeffrey Juday is a software developer with Crowe Chizek in South Bend, Indiana. He has been developing software with Microsoft tools for more than 12 years in a variety of industries. Jeff currently builds solutions using BizTalk 2004, ASP.NET, SharePoint, and SQL Server 2000. You can reach Jeff at jjuday@crowechizek.com.
