I recently wrote about the Windows Server Operating System Management pack version 6.0.6989.0 HERE. In the “known issues” section of that article – I discussed that the MP is solid – except there are no performance collection rules for cluster disks, such as latency, or free space, to leverage in your reports. We now have three different types of common disks in Windows servers (Logical Disks, Cluster Disks, and Cluster Shared Volumes). This means we have to have three different sets of rules targeting each class, for collecting performance data. This article will be a walk through on how to correctly create performance collection rules, to collect performance data from Cluster disks. It can be used as an example on how to collect performance data from any multi-instance object.
I previous wrote on a similar topic here: https://kevinholman.com/2009/11/24/writing-monitors-to-target-logical-or-physical-disks/ That article covered correctly using MONITORS to examine disks (or any multi-instance object) and the caveats around monitors. This article is different, in that there are specific rules that must be obeyed for collection rules in order to have a positive reporting experience.
The wrong way:
Essentially, to collect performance data on these cluster disks, I could simply write a rule, target the “Windows Server Operating System” class, and then collect something like this from perfmon:
That would work fine – in the OpsDB…. and you would see the data in your views in the console. HOWEVER – this breaks in the warehouse. In the warehouse – all the raw data is aggregated NOT based on the counter, but on the RULE that collected it. This means for an hourly aggregation, if we used a rule like above – we would aggregate ALL the collected data together, and then the data would be completely meaningless, as it would average the data from all instances of disks on a Windows Server. You can NOT use “include all instances” when collecting data…. this is a no-no based on how our warehouse is designed.
So what can I do?
Well I am so glad you asked! Read on.
For this exercise – we will be using the SCOM 2007 Authoring Console – which you can download from the resource kit. http://www.microsoft.com/en-us/download/details.aspx?id=18222
You can use this to create MP’s for OpsMgr 2007 or 2012.
Open the authoring console > File > New > Empty Management Pack. Give the MP an ID/Filename.
Give the MP a displayname and an Optional description:
File > Management Pack Properties > References. Add a reference, to the downloaded Microsoft.Windows.Server.ClusterSharedVolumeMonitoring.mp file. This will allow us to use the Cluster Disks as a target class when we author a rule.
At this point – save your MP locally. Then – close and reopen the Authoring console, and open your XML management pack. You may be prompted to find a few more MP’s – these will generally be located in the installation directory of one of your RMS/management servers on SCOM 2007, or on your installation media for SCOM 2012 in the \ManagementPacks directory.
Then, create a new rule:
Rules > New > Collection > Performance Based > Windows Performance Collection
Give your new rule a proper Rule ID by removing the “NewElement” text and putting in a word/words that describe a little about what the rule is for.
Then give the collection rule a display name that makes good sense, and choose the correct target class (if the auth console crashes here – you are missing dependency MP’s that we need to resolve, which is why we closed and reopened the auth console above to resolve all these.)
Next – browse and choose the Logical Disk object in perfmon, %Free Space, and then we have to do something special for the instance.
Since we are targeting the rule at EACH instance of the Cluster Disk class, we need to ensure that we ONLY collect that instances perf data per targeted disk.
Whatever we use for the “Instance” for perf collection in SCOM – it MUST match the instance in perfmon – perfmon is shown below:
So we need to select some *discovered property* of the Cluster Disks class, that equals “K:” or “L:” etc….
Looking at discovered inventory – we see:
Partition name will be perfect!
So we use the “flyout” on the right of instance and choose Partition Name. The flyout shows all properties of the targeted class:
Done! Finish to create the rule!
Now – lets repeat these for Free Space in Megabytes, and Avg Disk Sec per Transfer like so:
This way – we can collect the performance data for a multi-instance object like Logical Disks, or Cluster Disks. We just need a discovered property on the class to match up with Perfmon – something that resolves to the exact instance data shown in perfmon. If a class has multiple instances, and does not have a discovered property we can use for perfmon, you are pretty much screwed. That is why you should always plan for this when writing custom classes that also have performance statistics on a individual level. Most of the time you will only encounter this for Microsoft systems, when you need to collect additional perf counters for multi-instance items, like disks, processors, SQL instances, SQL databases, etc.
For the community – I have attached my Addendum management pack below, so you can use it as a guide or optionally modify it/seal it and use it directly.