Wednesday, January 27, 2010

OpsMgr R2 and Service Level Tracking (SLT): Targeting explained.

27-01-2010 Update:
The part of this posting where an example of a SLT is built has been updated since it wasn’t spot on.

Out of the field I do get a lot of questions about setting up SLT and more specific how to get the Service Level Objectives (SLOs) with the Collection Rules (Collection rule SLO) functional.
image

Many times the SCOM Administrators end up with an empty Performance Collection Rule screen, like this:
image

And soon they say: ‘Duh! SCOM is broken!’. But wait! That’s not the case. It is all about targeting.

When that isn’t done properly, one ends up with an empty screen like the one above. And before targeting can be done properly one needs to get a better understanding about HOW SCOM operates and HOW Classes relate to each other.

Sure, you can click till you drop and hope that on a certain moment you have selected the correct Class at random, but wouldn’t it be nice to approach it in a more intelligent way?
image

So it is back to the drawing board AND to RTFM the related MP guide(s) as well.

Why RTFM the related MP guides you ask? Good question!

Lets take a look at the Server OS MP Guide for instance. Like every MP Guide it contains a section Understanding Management Pack Operations. This section contains much worthwhile information, like the subsection Classes. A table shows all available Classes in the related MP and describes every Class. So What?

By just looking at the table you get a better understanding of what a certain Class might or might not contain:
image

I have highlighted some Classes since the Description tells me these Classes do contain other instances as well. Perhaps even some Performance Counters (aka Performance Collection Rules)?

For this we need to go back to the SCOM R2 Console to investigate it further. Lets start the SCOM Console, log on as a SCOM Administrator and select the Wunderbar Authoring and go to Authoring > Management Pack Objects > Rules.

Whenever a collection happens and is to be found back in a Report it is done by a Rule. So this is the place to be. Lets apply some filtering and use the two highlighted Classes we found earlier. Click on the Change Scope link displayed on the top right in the midsection of the SCOM Console. The Scope Management Pack Object screen is shown: 
image

Select the option View All targets and select the two Classes (Windows Server 2008 Full Computer and Windows Server 2008 Full Operating System) and click OK. Now all related Rules for these Classes are shown:
image

Whoa! That’s a difference! The first Class shows only 6 rules many of which are contained within the MOM 2005 Backward Compatibility MP which isn’t interesting at all for our quest for Collection Rules.

The second Class shows 44 Rules! That’s more like it! But not EVERY Rule is a Collection Rule. And we need Collection Rules. Lets take a clearer look at these Collection Rules related to this Class:
image

Thirteen I have counted. So now we know what Class to select for the SLT in order to get a filled Collection rule SLO. Lets make one!

Go to Authoring > Management Pack Objects > Distributed Application > right click > Create a New Distributed Application. Give it a name like WebApp and use as a Template the Line of Business Web Application. DO NOT USE THE Default MP but create a new one instead and click OK.
image

Now you are in the Distributed Application Designer window. In this example I have added the SCOM Web Console as the Web Site and the OpsMgr DB as SQL Database. Also I have added an additional Component and selected the Component Operating System > Windows Operating System and added the RMS to that Component.
image

Now the Distributed Application model looks like this:
image

Save this DA.

Go to Authoring > Management Pack Objects > Service Level Tracking > right click > Create > give it a name > Next > hit the button Select for the option Targeted Class, leave the Search Result Filter as it is (Distributed Application) and select the DA we just created (WebApp) and click OK.
image 

Now we are back in the main screen. The earlier created MP is automatically selected and can’t be changed. This is because the selected DA is contained within that MP and any unsealed MP cannot be referenced by any other MP. Click Next.
image

Click Add > Collection Rule SLO. Now the Service Level Objective (Collection Rule) screen is opened. Give it a logical name. Change the Targeted class to Windows Server 2008 R2 Full Operating System
image

Click on the Select button of the Performance Collection Rule box and the Select a Rule screen is opened. Tada! There are the thirteen Performance Collection Rules: 
image

Select the the Collection Rule Processor % Processor Time Total 2008 and click OK. Adjust the Aggregation Method and the Service Level Objective Goal as needed and click OK.
image

While we’re at it, we add a Monitor State SLO to it as well, a bit like this:
image

Click OK > Next > Finish > Close
image

Now the SLT is built.

Go to the Reporting Wunderbar > Reporting > Microsoft > Service Level Report Library > Service Level Tracking Summary Report. Open this report. Add the earlier built SLT, select a proper start date:
image

Run the Report:
image

5 comments:

John Bradshaw said...

Nice one! Thankyou Marnix.
JB

Brian said...

How can I print/export the report with the details "expanded" out? I want to show the "bars" and to do so need to expand the plus sign next to each Service Level.

Each report I export doesn't include the expanded details.

Thanks,
Brian

Marnix Wolf said...

Hi Brian.

This is a known issue when the reports are exported.

Airat_S said...

is it possible to calculate SLO as an average value, not the worst?

thanks in advance

Airat_S said...

is it possible to calculate SLA as an average value, not the worst of all instances?
For example, i've created an availability monitor on the group of computers. One of them has 50% uptime and all others have 100%.
SCOM says that the goal is not completed because availability is 50%.

thanks in advance