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