Sizing SCOM for the Oracle Management Pack

Sizing SCOM for the Oracle Management Pack

When implementing a new Management Pack in System Center Operations Manager (SCOM) sizing is extremely important if you want to keep your SCOM environment healthy and responsive. For implementing the OpsLogix Oracle Management Pack there are a few sizing scenarios you might want to consider before importing the Management Pack.

There are also 5 main factors that determine the number of instances you can monitor from one monitoring node:

  • Number of tablespace in an Oracle instance
  • Type of SCOM server used
  • Other workflow that are run on the SCOM agent
  • Number of enabled/disabled/custom rules and monitors in the management pack
  • Hardware sizing

This post is based on V1.3.12.130 of the OpsLogix Management Pack for Oracle.

 

Scenario’s for running the Oracle Management Pack on a Monitoring node:

  1. Running the management pack from a SCOM Management server
  2. Running the management pack from a SCOM Gateway Server
  3. Running the management pack from a SCOM Agent machine

 

 

Running the management pack from a SCOM Management server

When running the management pack from a dedicated SCOM Management server you should be able to monitor 20 instances when the following criteria are met:

  • The Management Server does not run any other major workloads
  • The average number of tablespaces per instance should not exceed 20
  • The server has at least 8 GB RAM and 2 CPU’s
  • Only the default monitors and rules in the management pack are enabled

 

 

Running the management pack from a SCOM Gateway Server

When running the management pack from a dedicated SCOM Gateway server you should be able to monitor 20 instances when the following criteria are met:

  • The Gateway Server does not run any other major workloads
  • The average number of tablespaces per instance should not exceed 20
  • The server has at least 4 GB RAM and 2 CPU’s
  • Only the default monitors and rules in the management pack are enabled
  • For the increased workload you will need to configure registry settings and overrides on the Gateway Server as shown in the appendix.

 

Running the management pack from a SCOM Agent machine

When running the management pack from a dedicated SCOM Agent server you should be able to monitor 20 instances when the following criteria are met:

  • The SCOM Agent Server does not run any other major workloads
  • The average number of tablespaces per instance should not exceed 20
  • The server has at least 4 GB RAM and 2 CPU’s
  • Only the default monitors and rules in the management pack are enabled
  • For the increased workload you will need to configure registry settings and overrides on the SCOM Agent Server as shown in the appendix.

Appendix: Adding registry settings and overrides to scom agents:

In order for the SCOM Agent or Gateway to be able to handle the larger workload the following registry settings need to be set on the server:

  • reg add “HKLM\SYSTEM\CurrentControlSet\services\HealthService\Parameters” /v “State Queue Items” /t REG_DWORD /d 20480 /f
  • reg add “HKLM\SYSTEM\CurrentControlSet\services\HealthService\Parameters” /v “Persistence Checkpoint Depth Maximum” /t REG_DWORD /d 104857600 /f

 

 

For the increased workload you will need to set the following overrides on the SCOM Agent or Gateway Server:

Navigate to:

System Center 2012 Operations Manager – Operations Console > Authoring > Management Pack Objects > Monitors

Locate Health Service > Entity Health > Performance> System Center Management Health Service Performance > System Center Management Health Service Memory Utilization > Health Service Private Bytes Threshold

Right-click and select Properties > then from the ‘Health Service Private Bytes Threshold Properties’ select the Overrides tab> click the Override… button and choose ‘For a specific object of class: Health Service

Find the server you are using as a monitoring node, select it and click OK

Check the Override box by ‘Agent Performance Monitor Type – Threshold’ and change the ‘Override Value’ (scroll to the right) to 31457280000

Save the override.

Navigate to:

System Center 2012 Operations Manager – Operations Console > Authoring > Management Pack Objects > Monitors

Locate Health Service > Entity Health > Performance> System Center Management Health Service Performance > System Center Management Health Service Memory Utilization > Health Service Handle Count Threshold

Right-click and select Properties > then from the ‘Health Service Handle Count Threshold Properties’ select the Overrides tab> click the Override… button and choose ‘For a specific object of class: Health Service

Find the server you are using as a monitoring node, select it and click OK

Check the Override box by ‘Health Service Handle Count Threshold – Threshold’ and change the ‘Override Value’ (scroll to the right) to 31457280000

Save the override.

BlackBerry components that need licensing when using the OpsLogix BlackBerry Management Pack

BlackBerry components that need licensing when using the OpsLogix BlackBerry Management Pack

As enterprise grade software, the BlackBerry Enterprise Server software can be installed on a single server, or the BlackBerry Enterprise Server roles/components can be installed on multiple separate servers. When monitoring the BlackBerry roles/components with the OpsLogix Management Pack for BES, the Management Pack is licensed per BlackBerry server. The overview below shows if/when a license is needed for the BES Management Pack, when the BlackBerry Enterprise Server roles/components are installed over multiple servers.

List of possible services (BlackBerry components) that need to be licensed when installed on a BlackBerry server:

  • Attachment Service
  • Enterprise Server (service)
  • MDS Service
  • Router Service

If one of the above services is installed on a BlackBerry server, the BlackBerry server with the service installed always needs to be licensed. If multiple services are combined on one server only one license is needed for that particular server.

List of possible services (BlackBerry components) that DO NOT need to be licensed:

  • Administration Service
  • Collaboration Service
  • BAS (BlackBerry Administration Service)
  • BMS (BlackBerry Monitoring Service)

If one or more of the above services that do not need licensing is installed on a BlackBerry server (and none of the services are installed on the same server that do need licensing), no license is required for the BlackBerry server.

 

Scaling the Ping Management Pack

Scaling the Ping Management Pack

Just a quick word on the scaling/sizing of the free Ping Management Pack.

From all the feedback we have received over the years on the sizing of the Ping Management Pack, the following can be used as a rule of thumb:

  • A physical Windows based machine (Windows 2003/2008/2012) with a SCOM agent (2007 R2 / 2012 SP1/R2) installed, will be able to handle a maximum of about 800 ping targets.
  • The Windows based machine should have 4 GB RAM and at least 1 CPU.
  • When running the Ping Management Pack from a Virtual Windows based machine, depending on its resource configuration, the maximum number of ping targets per Ping Host might far smaller than 800.

Finally, the Ping Management Pack demands resources from SCOM. When only a few Ping targets are configured, SCOM will probably be able to handle the additional workflows with ease. By default the Ping Management Pack only runs two workflows per Ping Target. If you are planning to configure hundreds or even thousands of Ping Targets, you will need to size your SCOM environment to cope with the workload accordingly.

 

As usual the disclaimer: OpsLogix will not be liable for any errors or omissions in this information nor for the availability of this information. The owner will not be liable for any losses, injuries, or damages from the display or use of this information.

Understanding the Ping MP’s “Target Host Ping Check” Monitor parameters

Understanding the Ping MP’s “Target Host Ping Check” Monitor parameters

In the past I have gotten a lot of questions on the overridable parameters for the “Target Host Ping Check” Monitor in the Ping Management Pack, this is reason for the blog entry “Understanding the Ping MP’s “Target Host Ping Check” Monitor parameters”.

By default the monitor pings a target once a minute and turns to critical if it doesn’t get a reply if the target doesn’t reply to the second ping. For various reasons some organizations don’t always want the monitor to turn to critical right after only one ping response was missed.


To influence this behavior there are a couple of parameters you can override:

  • Interval
  • NumberOfNoRepliesAllowed

 


 

For example let’s say that we want to ping a target, but only want the monitor to turn critical after three responses have been missed. In this case we set the NumberOfNoRepliesAllowed
to 3. This setting will result in the monitor only turning to critical after four minutes if three consecutive pings are missed.

Now if four minutes is too long for the monitor to turn critical, you can adjust the Interval
parameter. The Interval parameter controls the amount of time between the pings. If in the same example you would like the monitor to turn to critical after two minutes, you should adjust the Interval parameter to 30. This would mean the following for this example:

  • The monitor pings every 30 seconds
  • The monitor is allowed to miss three consecutive pings and if the fourth ping is missed to it turns to a critical state
  • 30 seconds * 4 = 2 minutes

 


KB0005 – Ping IMP Configuration Dashboard Crashes due to a”blank ping target”

KB0005 – Ping IMP Configuration Dashboard Crashes due to a”blank ping target”

If the Ping IMP Configuration Dashboard crashes unexpectedly, this might be due to a “blank ping target” entry in the OpsMgrDB database.

The “blank ping target” is caused by a bug in the csv import function of the Ping IMP Configuration Dashboard, when you leave a blank line (carriage return) at the end of the csv file. The easiest way to resolve this issue is to export the targets and remove the ping hosts to which the “blank ping target” was added. Wait for an hour or so and re-add the ping host and import the ping targets, making sure you leave no blank line (carriage return) at the end of the csv file.

If you do not want to remove the ping host, an unsupported way of removing the “blank ping target” is by using the SQL statements shown below on the OpsMgr database.

CAUTION: As always make sure you have a current backup of your OpsMgrDB database. Because the method of deleting instances directly from the OpsMgrDB database is not supported by Microsoft, we cannot be held responsible for any damage that might occur as a result of running the SQL statements.

The sql statements below are an adaptation of the SQL statement from the blog post: http://basementjack.com/uncategorized/remove-stubbornstuck-computer-objects-from-ms-scom/

  1. Open SQL Management Studio and connect to the OpMgrDB
  2. First check if there are any blank entries for the source host name by running the following sql statement:

    Select * from basemanagedentity where Path
    like ‘<Source Host name>%’
    and Name is null
    and DisplayName =

  3. Then if you are sure you have the correct instance (source host) run the following:

    Update BaseManagedEntity Set Isdeleted=1 where Path
    like ‘<Source Host name>%’
    and Name is null
    and DisplayName =

After the SQL statements are run, the “blank ping target” should no longer exist in the Ping IMP Configuration Dashboard.