Recently Microsoft added the ability to gather near real time performance information through OMS (for details look here). Tao dissected how this worked on this blog post here including which management pack is used (Microsoft.IntelligencePack.LogManagement.Collection), the rules which exist in the MP that gather data (shown below from my environment), and the underlying XML which was doing the collection of these counters. Tao’s blog goes on to how to configure your own near-real time performance collection as well so it’s definitely worth checking out. My blog post will focus on how you can integrate a workaround for what systems do and do not perform near real time performance information gathering. This blog post will cover:

  • How settings in OMS translate to rules in Operations Manager
  • A workaround to turn off performance counter collection on specific systems
  • Does this workaround work?

     

How settings in OMS translate to rules in Operations Manager:

For background and comparison to Tao’s environment, my environment shows 9 aggregate rules, 9 collect rules and 2 rules for event gathering.

This matches logically to what I currently have in OMS for event collection and Windows Performance Counter collection:

Windows Performance Counters

 

A workaround to turn off performance counter collection on specific systems:

As mentioned in Tao’s article, the performance counter collection is configured as part of the Microsoft.IntelligencePack.LogManagement.Collection management pack. My management pack information is shown below:

Note: The MP for this is unsealed but the version number is different than what we see in Tao’s environment.

To change the default behavior we need to find the rule from the management pack which we can locate by doing a find on the name of the management pack and scoping the view to Windows Computer as that’s our target. If we look at the collection rule for a specific counter we can see that the rule is disabled but has then been enabled for the members of the Microsoft System Center Advisor Monitoring Server Group (I discuss how to use this to our advantage in my blog post “Targeting OMS solutions to specific systems in Operations Manager” ).

If we want to exclude specific performance counters from being collected from specific systems we can identify the rules which perform this collection and then disable the rule those specific systems. This will stop the performance collection from occurring on the specific servers that you created the override for.

CRITICAL NOTE: When you create an override for a rule in an unsealed management pack you can only reference groups which exist in sealed management packs or groups which exist in the same unsealed management pack. You cannot reference groups which exist in a separate unsealed management pack. This brings a critical problem to the only approach that I’m currently seeing to scope where performance counters are and are not collected by OMS. As soon as I store my override in the unsealed management pack which Microsoft has in place to gather these performance counters I am at risk that the management pack will be overwritten by OMS and the change that I instrumented through the override will be overwritten. Additionally, if I add a counter or event log to gather that will cause OMS to update my management pack.

(For information on how to provide a notification when OMS management packs are updated see: https://www.catapultsystems.com/cfuller/archive/2015/11/18/providing-notification-when-oms-solutions-update-management-packs-in-your-environment/).

 

Does this workaround work?

To test this theory, I create an override which disabled collection of the Free Megabytes (for information on visualizing free disk space in OMS see https://www.catapultsystems.com/cfuller/archive/2015/11/25/visualizing-free-disk-space-information-using-oms/)  on one of my systems (HyperV02). Here’s it gathering before the change (showing 6 hours of data):

Here’s what this looks like after shutting it off the collection via override:

The other performance counters gathered by OMS continued to function as expected even after I made this change.

 

Reference:

 

Summary: The workaround that I have provided here does provide an approach to choose which systems collect specific near time performance counters but it is less than optimal as those alterations can be undone by an update to the OMS management pack or by changes in the OMS console for what near real time performance information or event logs are gathered. I am sure that Microsoft will provide scoping for what systems do and do not receive near real time performance collection gathering, but the workaround provided in this blog will hopefully be helpful in the interim.

Category: infrastructure