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:
- If the performance view you want is in a dashboard and not a single view, you can't directly reference it.
- 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,
- Look at the original MP and locate the dashboard or performance view showing the metric you want to expose.
- Copy down the rule name and the object name
- Goto your distributed application in the tree and right click the folder where you want to place the performance view
- Select New->Performance View
- Give the view a Name and Description (if you like), then click the ellipses (...) under Show data related to:
- 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.
- Check the "collected by specific rule" check box in Select conditions
- Click the blue underlined "specific" in Criteria description
- Select the rule name that you copied down
- 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.
- 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
Comments