Best Procedure for Central Monitoring with CCMS

Planning the Instances of the Central Monitoring System (CEN)

For small to medium-sized landscapes that you want to monitor centrally, we basically recommend that you operate the central monitoring systme (CEN) with a single instance. This recommendation applies for system landscapes of up to approximately 100 systems. In this case, you avoid potential problems that could arise from distributing the workload across different instances.

If you want to monitor larger system landscapes, design your CEN with multiple instances. We recommend that you assign each instance one or both of the following tasks:

• The instance acts as a communication partner for CCMS agents, that is, you fix the registration of the CCMS agents to this instance. You do this by specifying this instance during the registration and not activating load balancing using logon groups (more information: Dialog-Free Registration of CCMS Agents).

  On these agent instances, activate the central data cache (more information: Setting Up the Central Data Cache).

  Fix the context CCMS_Selfmonitoring to one of these instances (refer to the command Fixing on in Monitoring Contexts in the Topology Display).

• The instance is used to monitor availability, that is, you fix the corresponding contexts to one of the instances. This affects the Availability contexts and the contexts for availability monitoring with GRMG. You can obtain a list of GRMG contexts in the corresponding table column if you call transaction GRMG in CEN.

  Fix the specified contexts to one of these instances (refer to the command Fixing on in Monitoring Contexts in the Topology Display).

Once you have assigned the tasks above to instances of CEN, you should also check the workload of the instances, and, if necessary, move contexts between the two groups until you achieve an equal distribution of the workload.

Optimization of the Instances with which CCMS Agents Are Registered

The instances that are used for communication with CCMS agets, as described above, require a larger roll buffer so that the required data can be read directly from working memory when communicating with the agents, and so that no read and write operations on the disk are necessary.

To achieve this, increase the instance parameter rdisp/ROLL_SHM. The default value of the parameter is 32768, which corresponds to a roll buffer size of 32768 * 8 KB = 262,144 KB. This value is not sufficient for the instances in question.

In a tuned system, the roll area hit rate should be over 95%; you can check this hit rate in transaction ST02 of the relevant instance. There is no general specification for the value to which you need to increase the instance parameter rdisp/ROLL_SHM. However, as an initial guideline, we recommend an increase by a factor of five (163840).