The core of system monitoring lies in providing you with an understanding of how well your system is performing. Of course, to implement effective monitoring, you need the system to be able to understand all the elements involved. Using the Computing Center Management System (CCMS), you can do just that. By setting up the proper monitoring elements, you can be sure that the alerts in your system are acting properly. For instance, with critical batch job monitoring, when a critical job fails, an automated process is triggered that informs the responsible person.

If you look at a basic SAP ABAP system and try to understand what makes it tick, it simplifies the task of setting up the monitors. There are six basic areas:

1. Operating system
2. Database
3. R/3 online tasks (referring to all online tasks in the ABAP stack)
4. R/3 batch tasks (referring to all batch tasks in the ABAP stack)
5. Printing and emailing
6. Interfaces

I’ll show you how to set up a monitoring environment based on these six elements so that for each defined system you can quickly see where faults may lie. In this article, I’ll focus on the method of how to monitor and in part 2 I’ll cover what to monitor. This article is intended for system administrators and technical managers, and requires no prerequisites beyond using an SAP Solution Manager system prior to 7.1.

Here are the steps to setting up base monitoring:

1. Understand your landscape and determine which systems require monitoring
2. Build a spreadsheet of your base monitors and decide on the thresholds
3. Ensure all your agents are correctly installed, updated, stable, and running
4. Create your monitor sets based on the spreadsheet and set the permissions for them
5. Expand on each monitor set, creating rule nodes and virtual nodes to accurately describe the monitors
6. Create your automatic reaction methods for alerting
7. Use alert management to allow flexibility for sending out alerts
8. Use the Generic Request and Message Generator (GRMG) for Java monitoring

I’ll discuss the first four steps in this article.

1. Understand Your Landscape and Determine Which Systems Require Monitoring

This step may seem pretty obvious, but it is often neglected. It pays to spend some time going over your landscape identifying each system and understanding its purpose before you begin monitoring. Use transaction SMSY to start with, provided it has been configured correctly. Failing this, speak to your system architect.

Each system has its own range for capacity that should be factored in when setting alerting thresholds. For instance, a development system is neither as large nor as important as a production system. It is not necessary for you to be as strict with defining your alert settings for development or user testing systems as you would be when defining settings for production systems.

2. Build a Spreadsheet of Your Base Monitors and Decide on the Thresholds

Using the heading shown in Table 1, begin to build your monitor sets under the following broad headings: operating system, database, SAP online processing, SAP background processing, printing and emailing, and interfaces. Don’t forget to include system availability, which falls into its own unique category for monitoring. Table 1 shows just an excerpt of what should be included in this spreadsheet; I’ll show a more detailed version in part 2. 

Table 1

Example of spreadsheet used to define base monitors of the landscape

The headings are also contained in the group MTE for Entire System Monitoring. You can find the details of these monitoring tree elements here. You do not need to use exactly the same MTEs as I do, but if you are struggling to identify which ones work for you and which ones do not, then use mine as a guide. The MTE technical names are outside the scope of this article, but there is a lot of work you can do to set up the structure of monitoring your environment before, as explained in step 4.

3. Ensure All Your Agents Are Correctly Installed, Updated, Stable, and Running

CCMS agents are installed on all your satellite systems and registered with the central monitoring system (CEN). The CEN does not necessarily need to be the SAP Solution Manager system, although it makes sense that it is. In brief, CCMS agents can be either sapccm4x agents (for ABAP systems) or sapccmsr agents (for everything else, including Java).

The first monitor that you should create is the one that monitors the CCMS agents themselves. It makes sense to monitor the agents and be informed if they go down, because if they are down they cannot inform you of a fault.

Using transaction RZ20, create a monitoring node called CCMS Agent Monitoring. Expand and select the MTE for CCMS_Selfmonitoring, CCMS Agents. Doing this quickly informs you if your agents are registered correctly and if they are working.

4. Create Your Monitor Sets Based on the Spreadsheet and Set the Permissions for Them

The look and feel of the created monitor sets in transaction RZ20 must reflect the SAP landscape. A technician should be able to quickly and easily navigate to the system that requires attention — and not waste a lot of time expanding a vast number of trees searching for the monitor element in question. To ensure that your monitor sets reflect the SAP landscape, set up a combination of virtual nodes and rules nodes in transaction RZ20. This procedure involves five steps:

Step 1. Create a monitor set for SAP NetWeaver BW. You could call it Acme — BW Systems, for example. To create a monitor set, use transaction RZ20. Highlight the link My Favorites under the CCMS monitor sets. Go to Monitor (set), which is in the top left corner and then select Create. Name the monitor set (e.g., Acme — BW — BWD/BWQ/BWP — ABAP) and then save.

Step 2. Create another monitor subtree below that monitor set for each SAP system in the SAP NetWeaver BW landscape. An example would be Acme — BW Development System.

Step 3. In each subtree, create a rule node for just the SAP system itself. Define in the rule node the system ID of the system concerned. In this way, all downstream rules within downstream virtual nodes in the tree pick up this system ID. An example rule note could be CCMS_DEFINE_R3_SYSTEM, R3System = BWD.

Step 4. Within this system ID rule node, create a virtual node of one of the six basic elements, such as Operating System, including a specific virtual node for the type of system. Example virtual nodes could include:

• Operating System
• Database
• R3 Online Services
• R3 Batch Services
• R3 Print Services
• Interfaces
• Process chains

Step 5. Create a rule node under the virtual node using the rule CCMS_GET_MTE_BY_CLASS to define the monitor that you want to monitor. Note that this rule node now picks up the system ID defined in the header rule node for the system. For example, under the virtual node for Operating System, define the rule node for CCMS_GET_MTE_BY_CLASS to be CPU_Utilization.

The format of the CCMS monitoring tree should be as follows:

CCMS monitor sets

• My Favorites

<Company Name> – <System Type> – <SID1/SID2/SID3> – ABAP or Java

A specific example could be:

• Acme – BW – BWD/BWQ/BWP – ABAP
  • BW 1 – BWD – <BWSERVERNAMEDEV>
  • BW 2 – BWQ – <BWSERVERNAMEQA>
  • BW 3 – BWP – <BWSERVERNAMEPRD>

Then under each monitor, split the monitor up into the following categories by creating the following virtual rules. (Make sure you have already created a header rule node for the system ID.) Schematically, it would look like this:

Monitor name: BW 1 – BWD – <BWSERVERNAMEDEV>

• Rule node: CCMS_DEFINE_R3_SYSTEM, R3System = BWD
  • Virtual node: Operating System
  • Virtual node: Database
  • Virtual node: R3 Online Services
  • Virtual node: R3 Batch Services
  • Virtual node: R3 Print Services
  • Virtual node: Interfaces
  • Virtual node: Process chains

Now create under each of the virtual nodes a rule node for the monitoring element described in the spreadsheet. (I’ll discuss this topic in detail in part 2). Note that the legend displays a gray cross if the node is a virtual node because a virtual node has no meaning except to help categorize your configured monitors.

Figure 1 shows a screenprint from a test system of what the setup should look like in change mode.

Figure 1

The setup in change mode

For example, for Operating System, set up the following rules node using the CCMS_GET_MTE_BY_CLASS rule. Note that the system ID is always the default in this because it is ruled by the header class already defined in CCMS_DEFINE_R3_SYSTEM.

Operating System

• CPU_Utilization
• 5minLoadAverage
• Idle
• Paging
• Commit_Charge
• Filesystems
• CPU_IO_Wait
• MemoryFree
• MemoryVirtCIMvm (if you have a virtual environment)

In real-time mode (i.e., when you display the values of the monitor set), you should see what is shown in Figure 2, except in this case I display an example of R3 Online Services. It is quick and helpful to be able to view at a glance all the important metrics that control the operation of an SAP R/3 ABAP system.

Figure 2

Screen output from transaction RZ20

Jim Baxter

Jim Baxter is an independent SAP Basis consultant with a wide variety of experience in SAP Solution Manager setup and functionality. He is certified in the Implementation Tool and Root Cause Analysis and has worked on Service Desk setup for SAP value-added resellers.

You may contact the author at jim.baxter@ulapha.co.za.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.