Blogg

Operations Manager is good at monitoring performance of separate software components.It also has an interface to bundle them together into groups in order to be able to understand what the health state of the whole as a group is.

In SCOM context this is called a Distributed Application. At Approved we treat this (with addition of Live Maps Unity from Savision) as an interface for managing IT Services.

As in most cases after getting data into SCOM and then into SCOM Data Warehouse, some day we want to extract and analyze this data or, better yet, use it as a base to predict future outcomes and deal with issues before users even notice them.

And, as in most cases, extracting and querying SCOM DW Distributed Application data is not really straightforward. Lets start with finding the 'services' themselves.

In previous blog post we looked at custom SLO reporting solution for SCOM. Now we will take a closer look at what can be done with all the alert-related data that is stored in SCOM Data warehouse.

Understanding Alert Nature

At first it might seem that all we want to see about alerts is just sitting and waiting for us in the alert view (Alert.vAlert). But by now we all know that nothing is as easy as it seems in System Center data warehouses.

There are three main points that complicate matters when it comes to alert querying.

First of all comes the fact that alerts can be generated either by Rules or by Monitors. And both alert sets end up in one fact table, making it a little more complicated to figure out the exact entity which generated each row.

Second thing that might happen is that your query might return results generated by Managed Entities which are no longer available in SCOM (deleted old stuff etc.). And we don’t want those to be cluttering our reports either.

Finally, figuring out the current (latest) resolution state is a bit of a painful task (both for the DB server and us analysts) because all of those states reside in a separate table and there are quite a few of them to choose from!

Service Level Agreements allow IT organizations and their clients to have a common view upon service delivery quality. Service Level Objectives are defined within every SLA in order to obtain specific and measurable metrics which help evaluate and improve the delivery of IT services.

Therefore monitoring SLO targets and outcomes is obviously a very important task. Especially within organizations working by (or starting to implement) ITIL framework. The whole of Microsoft Systems Center product family is designed to support ITIL processes. Measuring uptime and managing SLO values is no exception.

In this article we will look at 3 ways to track SLO performance based on data gathered by Systems Center Operations Manager.