OpsMgr by Example: CPU Percentage Utilization Monitors in OpsMgr 2007

In many of our OpsMgr by Example articles, we recommend you install the Windows Server management pack to be able to get access to underlying operating system performance data for applications including SQL Server, Exchange, and IIS. However, per KB article 948097 (http://support.microsoft.com/kb/948097), the CPU percentage utilization monitors do not work on Windows 2003 Server!
 
These monitors are targeted to the Windows Server 2003 processor class – but by default, there is no available Windows Server 2003 processor class instance, since the corresponding discovery rule (Discover Windows CPUs) is disabled by default. To enable the rule, perform the following steps:
  1. In the Operations console, navigate to the Authoring space. Open Authoring -> Management Pack Objects -> Objects Discoveries.
  2. Narrow your scope, then search for the "Discover Windows CPUs" discovery rule.
  3. In the Properties window of the rule, go to Overrides. Set overrides on all Windows Server 2003 Operations System role type objects. Check "override" on the "Enable" parameter.
  4. Save the override setting to an unsealed management pack, preferably not the Default management pack.

Once the Processor class is functional, the CPU percentage utilization monitors will also start working.

 
Advertisements
This entry was posted in Tuning and Configuration. Bookmark the permalink.

One Response to OpsMgr by Example: CPU Percentage Utilization Monitors in OpsMgr 2007

  1. Jay says:

    The one other configuration I\’m looking at is having the RMS and the operational DB on the same server (4 dual-core opterons, 64 GB RAM) to attempt to eliminate the OS network stack latency in all of the SQL queries that the console makes.  With 64 GB RAM, the DB should be pretty well cached in RAM.  In this case, the "thread execution latency" is the limiting factor, and I\’m not sure if the interactive responsiveness of the console would be better in this case, or in the case where the RMS and DB are on separate servers.  In comes down to — what\’s worse in an interactive responsiveness scenario —  having SCOM RMS functions competing with MSSQL for CPU and RAM resources, or go with 2 servers and incur network stack overhead on all of those SQL queries generated by the console.
     
    The would be a couple other management servers, so the RMS wouldn\’t be handling the agent load.
     
    The reporting server is planned as another large server with DBS, SRS, and SCOM reporting all on one server.  This could be "scaled out" to a DB server and another server with SRS and SCOM reporting, if that offered better performance.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s