MP authoring and rules for performance collection in OpsMgr 2007

Article
09/22/2011

Hi everyone, Eddy Pacay here once again with some useful knowledge on MP Authoring and rules for performance collection in System Center Operations Manager 2007 (SCOM 2007). I have recently come across a very unique scenario where a single performance collection rule was created and used to collect multiple counters. Let me give you an example of what I mean.

So let’s say that you author an MP because you create a rule to collect multiple counter values such as shown below.

This seems like a good idea right? In reality this is not something that we recommend you do. The reason is that SCOM is not able make this association because by design we apply a single counter per rule. Meaning, when a counter is collected, we apply a 1:1 relationship with the counter to the rule. This does not mean that we are limited to a single rule collecting a specific counter, as we can have many rules collecting the same counter, it just means that a rule is limited to one counter only.

This is not a big deal when you see it in the Operations Console in a performance view such as shown above. Things become a little convoluted when you try to run a report for the collected data values. What you encounter when you try to add the counters to the report is that the counter is missing. This has to do with the way SCOM is designed and how the data is entered in the Data Warehouse.

You may ask yourself “Why can I see the correct data in the console view?”

This is because of differences with the OpsDb and the OpsDW. One of the differences is data aggregation. With Data aggregation we simply run a maintenance workflow against the Data warehouse. When we do so, the workflow is expecting to find one counter per rule.

So in case you have ever thought about doing such a thing you will find this behavior is by design.

Here is how you can see the behavior in practice.

This query shows the last counter added to the DW in my lab the name of my MP and the name of the rules as well as the counters have the keyword “test” somewhere.

select * from PerformanceRule where CounterName like '%test%'

=====

RuleRowId ObjectName CounterName MultiInstanceInd LastReceivedDateTime

490 Testing_Object Testing Counter 1 0 2011-08-19 00:54:00
491 Testing_Object Testing Counter 2 0 2011-08-19 00:51:00
1086 Testing_Object Testing Counter 1 0 2011-08-19 00:54:00

We only see testing counter 1 and testing counter 2. Testing counter 3 is missing.

This is the same in SCOM 2007 R2 CU4 as in the SCOM 2012 Beta

We then look for the instances in the perfruleinstance table:

select * from PerformanceRuleInstance where InstanceName like '%Testing%'
order by InstanceName

=====

PerformanceRuleInstanceRowId RuleRowId InstanceName LastReceivedDateTime

136 490 Testing Instance 1 2011-08-19 00:51:00
137 491 Testing Instance 1 2011-08-18 01:51:00
341 1086 Testing Instance 1 2011-08-19 00:51:00

This gives us the PerformanceRuleInstanceRowId for the location of the Perf Rule.

We then Plug in PerformanceRuleInstanceRowId from above query to see collected counters (notice the data is making it to the PerRaw tables, this is before Data Aggregation)

select * from perf.vPerfRaw where PerformanceRuleInstanceRowId = '137'
order by [DateTime] desc

The results show the following:

Date Time PerformanceRuleInstanceRowId ManagedEntityRowId SampleValue

2011-08-19     19:46:00.140    137                                               55                                      1
2011-08-19     19:46:00.140    137                                               55                                      2
2011-08-19     19:46:00.140    137                                               55                                      3
2011-08-19     19:46:00.137    137                                               56                                      1
2011-08-19     19:46:00.137    137                                               56                                      2
2011-08-19     19:46:00.137    137                                               56                                      3

This shows that the values are being collected as expected.

We can also check the Perf Raw tables to confirm that the data is making it to the DW by using the same:

PerformanceRuleInstanceRowId

Select* from Perf.PerfRaw_7FD35E95DF324C119870120B12B9CF41 where PerformanceRuleInstanceRowId = '137'

The results are

PerfRawRowId DateTime PerformanceRuleInstanceRowId ManagedEntityRowId SampleValue

1280304 2011-08-09 17:22:00.093 137 57 1
1280305 2011-08-09 17:22:00.093 137 57 2
1280306 2011-08-09 17:22:00.093 137 57 3
1280382 2011-08-09 17:22:00.077 137 56 1
1280383 2011-08-09 17:22:00.093 137 56 2
1280384 2011-08-09 17:22:00.093 137 56 3

This is expected behavior as the three counters are all tied to the one performance rule.

As stated above, this is due to the way we store data in the DW… we tie each counter collected to one rule, so the last counter added will change the performancerule name… you’ll never see all three counter names show up in the DW because of this.

The formula for this practice is the following

"Use dedicated rule per each DataItem generated by DataSourceA"

In conclusion, although things are still working and doing what they should do, do not be alarmed that you are unable to find missing values in the Datawarehouse, this is expected and by design. Following best practices for MP authoring and rule creation should be followed, follow the dedicate rule per each DataItem generated by DataSource A. formula.

Eddy Pacay | System Center Support Engineer

MP authoring and rules for performance collection in OpsMgr 2007

Additional resources