Xplat Xperts

Writing Managements Packs for SCOM: A more robust Hyper-V MP

Have you ever been looking at a management pack and wishing it was collecting just a little more information for you?  You're not the only one, there are quite a few people who writes MPs from scratch to support applications they are running, but there are more who are still a little leery of going down the path of MP Authoring.  In the next series of posts I'm going to walk through extending the base Hyper-V management pack so that it provides more information around how healthy the servers really are. 

Tools of the trade:

1. System Center Operations Manager 2007 R2 Authoring Console: I don't use it for much, but it's a good tool to use when you want to build out quick Windows based monitors, validate the XML schema, and see all the views you have created. http://www.microsoft.com/downloads/details.aspx?FamilyID=9104af8b-ff87-45a1-81cd-b73e6f6b51f0&displaylang=en
2. XML editor: trying to make things like Dashboards and collection rules with the console is somewhat cryptic and generally far too painful so use an XML editor or better Visual Studio
3. Authoring Guide: keep it handy so you can make reference to it when some of the XML layout makes you want to scream. http://technet.microsoft.com/en-us/opsmgr/bb498235.aspx
4. Install the SCOM console on the system you will be doing the authoring on.

Now let's run through the steps to get things setup:

1. Get a copy of the MP you want to extend, you do this by downloading the manual install package as opposed to installing the MP via the SCOM catalog.  For Hyper-V you can get the installer at: http://www.microsoft.com/DownLoads/details.aspx?familyid=502E7A26-2FEA-4052-89FD-8F75142DE4F2&displaylang=en
2. Run the installer and extract the sealed MPs to a local path like c:\authoring\dependencies
3. Launch the Authoring Console
4. Select File->New.. Empty Management Pack
5. Give your MP a name, I used BridgeWays.Windows.HyperV
6. Give your new MP a Display Name, such as "BridgeWays Windows Hyper-V"
7. Create

You now have an unsaved shell Management Pack that does nothing.  So let's set it up to extend the core Hyper-V MP:

1. Click Tools->Options...
2. Go to the references tab and add in the System Center directory and the directory where you put the Hyper-V MP.
   
   
3. Next, go File->Management Pack Properties and go to the References tab
4. Click Add Reference
5. Select the MPs that you want to extend and use, I selected the Hyper-V MPs
   

Now we're ready to start adding our items to the MP.

Let's start by check to see if we can extend the MP directly, ie add our own folders and views to the Hyper-V folder in the SCOM Monitoring hierarchy.  This is determined by whether or not the root folder is flagged as 'internal' or 'public'.

1. In the Authoring Console, click the Presentation tab.
2. Right-Click the Microsoft.Windows.HyperV.RootFolder and select New->Folder
3. Give your new folder an object name such as BridgeWays.Windows.HyperV.Performance and a display name like Performance
4. Click the Folder tab and make sure the selected folder is Microsoft.Windows.HyperV.RootFolder
5. Click OK

No luck with the Hyper-V MP, the root folder is internal and it doesn't have any other folders so in this case we'll have to build out a parallel MP that has our new information in it.  For Hyper-V it's not a big deal since there are only the 3 state views, for an MP like SQL Server, luck is on our side the root folder is public so we can extend that MP directly.

To create the new folder, simply follow the previous steps, but give your folder a more precise name like "BridgeWays Windows Hyper-V" and set the parent folder to be Microsoft.SystemCenter.Monitoring.ViewFolder.Root .  Now we have a new root folder for any views we want to create.

So now, let's create a duplicate state view within our new folder.  This state view will simply duplicate the same information as the Hyper-V MP shows in the Server Role View.  I'm doing this because I know I'll be adding a number of monitors as well as performance views and I don't want to have to switch from one folder to another when I'm watching the environment.  Again, Hyper-V only has 3 state views so it's not a big deal to duplicate them.

1. Right click on the new folder (BridgeWays.Windows.HyperV.Root in my case) and select New->State View
2. Give it a new ID postfix, such as ServerRole.State
3. Give it a Display name, such as "Server Role State"
4. Click the ellipses by Target and select the target we want to show in the state view, in this case Microsoft.Windows.HyperV.ServerRole
5. Click Finish

That's it, we've just duplicated the Server Role View from the Hyper-V MP to our new custom MP.  The beauty of this is we don't have to redo the discoveries or anything because the data is already being populated by the core MP.

For the next post, we'll look at adding our own monitors to the discovered servers.

Using System Center Configuration Manager to Simplify BridgeWays Deployments

We make great effort in ensuring that getting the BridgeWays Management Packs up and running in any Operations Manager environment is as painless as possible.  When you consider the wide array of supported platforms, this isn't as easy as it might sound.  Different platforms expect different packaging technologies, as well as different commands to install them.  When deploying our providers to any of our supported Unix/Linux computers, we have implemented tasks in the management pack for taking care of this.  These tasks will make use of the same SSH and SFTP modules that the Operations Manager Unix/Linux Discovery Wizard uses to communicate with the machine, determine the platform and version, and then push and install the appropriate package to the machine.  You can deploy everything from the Operations Manager console without ever having to touch those target machines.

When deploying to Windows however, these tasks are not available.  But, if your organization is also using System Center Configuration Manager (SCCM), this can also be simplified.  In the following steps, I will describe how SCCM can be used to deploy our providers to Windows machines.  The example I will use will illustrate how to deploy the BridgeWays WMI Provider for Oracle Database.

1) Copy the BridgeWaysWMIProviderForOracleDatabase.msi to an SCCM machine.

There are many different ways SCCM can be configured to deploy packages, but we'll keep it simple for this example.  I've copied the package to my "all-in-one" SCCM box.  For this example, I've copied the package to "C:\SCCM\BridgeWays".  Replace any future references to this path with wherever you've copied your package.

2) Create a Collection

We'll want to create a collection that is scoped to only the Windows Server machines that are running Oracle Database.  We don't want the package to be pushed to machines that don't need it.  I've created a collection named "All Windows Servers Running Oracle Database".  To create a collection, right click the Collections node (found under Computer Management) and select "New Collection".  A collection requires a membership rule to determine which machines belong to the collection.  This rule can be a direct assignment or a query.  Again, for simplicity, I've chosen the direct assignment approach.  When prompted for criteria, specify "System Resource" as the Resource class, "Hostname" as the Attribute name, and "%" as the Value.  This will return a list of all machines for you to select.  For large numbers of machines you will likely want to use a more scoped filter, or take a look at the query membership rule (outside of the scope of this discussion).  Select the machines that are running Oracle Database that you want to target and finish creating the collection. 

3) Create a Package

Under Software Distribution, right click the Packages node and select "New -> Package".  You must first give the package a name.  I've called mine "BridgeWays WMI Provider for Oracle Database".  I've left all other settings on the "General" page empty, but feel free to fill them in.  On the "Data Source" page select the "This package contains source files" checkbox.  Click "Set..." for "Source directory".  On the "Set Source Directory" dialog select "Local drive on site server" and use the "Browse..." button to select the directory you copied the package to in step 1.  I used "C:\SCCM\BridgeWays".  It's worth noting that the entire contents of this folder will be distributed as a package to the target machine once it's requested, so ideally this folder should only contain the BridgeWaysWMIProviderforOracleDatabase.msi.  Select the "Update distribution points on a schedule" checkbox and leave as default schedule (every day), or modify schedule as desired.  All other settings in the wizard can be left at their default values.       

4) Create a Program

Under Packages you should see the "BridgeWays WMI Provider for Oracle Database" package that we just created in step 3.  Expand that node, right click on the Programs node and select "New -> Program".  Provide a name (I used the same name as the package, but feel free to be more creative).  The "Command line" field should be set to "BridgeWaysWMIProviderForOracleDatabase.msi".  On the 'Requirements' tab, I've left all the values at their defaults, but feel free to scope the target platforms if you know Oracle Database is only running on certain platforms.  On the "Environment" tab, I've changed the "Program can run" option to "Whether or not a user is logged on".  You can proceed to the "Windows Installer" tab.  Select "Import..." and navigate to where you've stored the "BridgeWaysWMIProviderForOracleDatabase.msi" package.  You should see the "Windows Installer product code" and "Windows Installer file" options get filled in.  All other options can be left at their default values.

5) Create an Advertisement

Under Packages, right click the Advertisements node and select "New -> Advertisement".  Provide a name.  For the "Package" field, click "Browse..." and select the "BridgeWays WMI Provider for Oracle Database" package we created in step 3.  The "Program" field should automatically get filled in for you as it should be the only program in this package.  For the "Collection" field, click "Browse..." and select the "All Windows Servers Running Oracle Database" collection that we created in step 2.  Click "Yes" when prompted about distribution points not being specified for the package (that's coming in the next step).  On the "Schedule" tab, click the button for "Mandatory assignments" that looks like a yellow star.  On the "Assignment Schedule" dialog, click the "Assign immediately after this event:" option, and leave the setting as "As soon as possible" and click "OK".  Proceed to the "Distribution Points" tab.  Ensure the "Download content from distribution point and run locally" is selected in both places.  All other options can be left at their default values.

6) Create and Update Distribution Point

Under Packages you should see the "BridgeWays WMI Provider for Oracle Database" package that we created in step 3.  Expand that node, right click on the Distribution Points node and select "New Distribution Points".  On the "Copy Package" tab, select your SCCM server that you are using for your distribution point.  This needs to be the SCCM server where you copied the BridgeWaysWMIProviderForOracleDatabase.msi in step 1.  Finish creating the Distribution Point.  Right click the Distribution Points node again and this time select "Update Distribution Points" and select "Yes" when prompted.

Shortly after completing this step you should see the "BridgeWays WMI Provider for Oracle Database" package advertised on the machines listed in the "All Windows Servers Running Oracle Database" collection (as shown below). 

The status of the installed package is reflected in the SCCM Console on the Software Distribution node (as shown below).

 

If you have already imported the BridgeWays Management Packs for Oracle Database into Operations Manager and have discovered your Windows Servers running Oracle Database, monitoring data will start flowing without ever having to touch those machines!  Of course you can modify these steps to deploy any of the BridgeWays WMI Providers whether it's for Oracle Database, Apache, MySQL, JBoss, Apache Tomcat, etc.  Just modify the collection and package details as necessary.  Hopefully this saves you some time when you're faced with deploying the BridgeWays WMI Providers to many Windows machines.

SCOM and Distributed Applications: Service Level Objectives

At this point we've built out a Distributed Application and generated custom dashboards that allow us to view the health and performance of that application.  We'll receive alerts when monitors fire and we're able to view performance information that is scoped specifically to the modeled service. 

So what's next? Reporting of course, I can easily generate custom performance reports but now that I have tied all my components together to make a distributed application I can use Service Level Objectives and the Service Level Dashboard in SCOM to easily show both availability and performance levels of the service.

I have a previous post on how to set up the Service Level Dashboard solution accelerator that you can follow if you have not yet done so.  For this post we'll primarily look at setting up the SLOs that you need.

Service Level Objectives

It all starts in the Authoring tab of SCOM under Management Pack Objects->Service Level Tracking.  Here we are able to define our objectives for the service.

 
To build out the new Service Level Objective:

1. Right Click Service Level Tracking and select Create
2. Give the SLO a name, such as Petstore Objectives
   
3. Click Next
4. Click the Select... button for "Select a class of object to target" and then select your Distributed Application class, in my case it was "Petstore" 
   
5. Click Next
6. Click the Add button and select Monitor state SLO
7. Give the SLO a name of Availability and set the Service level objective goal to 99.99
8. Click OK
   
9. Click Add
10. Select Collection rule SLO
11. Click the Select... button beside Targeted class
12. Select one of the classes you included in the Distributed application, I will select Oracle Instance (Windows)  
13. Click OK
14. Click the Select... button beside Performance collection rule
15. Select the counter you want to monitor, I will select Oracle Database Inactive Sessions
16. Click OK
17. Specify the Service level object goal, in my case I want to ensure there are no more than 4 inactive sessions, so I will set the goal to "Less Than 5".
    
18. Click Next
19. Click Finished

So we have now created a Service Level Objective that checks to ensure that our service as a whole is available 99.99% of the time and that our Oracle component in particular has less than 5 Inactive Sessions on average.

These objectives can be consumed through either Reports, or the Service Level Dashboard.

Reporting

The SLO reporting is quite nice, the reports are all linked so you can look at things like Availability and drill down from the high level to detailed availability reports withing SCOM.  To generate a report:

1. Wait 30 minutes or so for the SLO to go into effect
2. Go to the Reports Tab
3. Run the Service Level Tracking Summary Report
4. Click the Add... button
5. Select the SLO you created, Petstore Objectives in my case
6. Specify the report time frame using the From and To drop downs
7. Click Run

The end result is a high level view on how well the SLO was met and you can drill into each report to get finer grained details.

Service Level Dashboard

With the Service Level Dashboards, you simply edit the page to expose the new SLO (Petstore Objectives) and now anyone who has access to the dashboard can see how healthy the service is.

When it comes to Distributed Applications, you've now been introduced to quite a bit in terms of what you can do with them.  They are a powerful monitoring tool because they allow you put some context around any detected issues because you are looking at services as a holistic object as opposed to individual components.  You need to be able to see how the database is affecting the front end before you can really determine whether the issue is a slow DB, a network bottleneck, or an under allocated connection pool. 

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

SCOM and Distributed Applications: Building Performance Views

  With the last post I showed you how to build a Dashboard using some of the basic view types, now let's go into building performance views.  With performance views you need to know a bit more about the MPs you are using with your distributed applications because you need to know the rule names that you want to see and what object they are associated with.

For anyone not familiar with the terminology, SCOM makes use of Rules to gather performance data like CPU usage, Memory usage, etc.  The data collected is then typically stored in the Data Warehouse so that you can build reports using the information.  Monitors are a different entity, and those are what check the values fo specific metrics, compare those values to defined thresholds and raise alerts if the thresholds are exceeded (or not met depending on the type of comparison being made).  State Views are used to expose the monitors, Performance Views are used to expose the rules and Dashboards are used to pull them all together.

The next question you may have is... why bother building custom performance views when you can simply reference a performance view directly in the tree?  There are two reasons for this:

1. If the performance view you want is in a dashboard and not a single view, you can't directly reference it.
2. If you reference an existing performance view, you can't scope it to show only the objects that are part of the distributed application and any changes to the visible data made is reflected on both views. 

So when it comes to distributed applications, it's best to specifically create any performance views you want so that you can have full control over them.

We're now ready to go ahead and create a performance view, I'll do my example around building a performance view for the Buffer Cache Hit % for Oracle.

In the monitoring pane, find the metric you want to build a view for.  Using Oracle as an example,

 

1. Look at the original MP and locate the dashboard or performance view showing the metric you want to expose.
2. Copy down the rule name and the object name
3. Goto your distributed application in the tree and right click the folder where you want to place the performance view
4. Select New->Performance View
5. Give the view a Name and Description (if you like), then click the ellipses (...) under Show data related to:
6. Select the appropriate Object from the dialog, this will match the Object name you copied down, and you may have to select the radio button for "View all Targets" to see it.
7. Check the "collected by specific rule" check box in Select conditions
8. Click the blue underlined "specific" in Criteria description
9. Select the rule name that you copied down
10. Optionally, you can also scope it to a specific discovered instance.  This isn't absolutely necessary since you will be able to do that through the performance view later as well.
11. Click OK

 
We now have a new performance view and this view can be included in higher level dashboards and more importantly customized, tweaked, and consumed as a distinct part of our distributed application.

 

You now have all the tools necessary to build out customized distributed applications that tie different management packs together into logical entities.  This is something that can help simplify troubleshooting issues because it provides full context around problems that are detected.  Having a full service stack monitored as a single entity gets rid of the distractions from metrics that don't effect the service in question and you can now see an alert in one tier may be causing an alert in another.   

For the next post, we'll look at expanding the distributed application through Service Level Objectives that can be used to build out SLAs around our service.

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

SCOM - BridgeWays Management Pack Videos: Apache HTTP and IBM DB2

And the list of videos continues to grow, you can now watch videos for Apache HTTP and IBM DB2 management packs.

Apache HTTP:

IBM DB2: