Background Job Monitoring Monitor in CCMS

You can use the monitoring architecture to monitor selected jobs and to display problems as alerts (see Monitoring Jobs with the Alert Monitor). This job monitoring is deactivated by default; activation is described in Activating Monitoring of Jobs with the Alert Monitor.

After activation, the data is available in the context Background, Background Job Monitoring subtree. For the monitoring, it is useful to define your own monitor or to extend a monitor definition of your own to display the data. The monitor definition and the monitor produced from it are described here.

Prerequisites

You can define a rule-based or a static monitor to display data. For basic information about this, see Creating and Changing Monitors. For a rule-based monitor, the definition must contain a rule CCMS_GET_MTE_BY_CLASS with Job_Monitoring as the MTE class:

If you are using a static monitor, choose the context Background ® Background Job Monitoring for the desired system:

Features

With the definition above, the monitor created has the following structure. Here, the job SCHEDULED_JOB1 and all jobs whose names begin with JOB_EXAMPLE are to be monitored. A subtree is created for every name pattern for a monitored job (job chain):

The monitor contains the following monitoring tree elements (MTEs):

MTE Name (MTE Class)	Meaning
Details of Current Job (Job_Monitoring_Details)	Double click this MTE to obtain the following current information about the current job: · Name, number, and class of the job · Date and time scheduled, the last change to and release of the job, and user that performed each of these actions · Last planned start and the actual last start and stop of the job · Server, work process number, and process ID of the last run of the job · Status and target server of the job These values may differ from the values Delay and Runtime below, as the current values are collected here, while Delay and Runtime are collected by the data collection method, which runs every five minutes.
Status (Job_Monitoring_Status)	Last entry in the job log for the job with the relevant name pattern: Name, number, status, and planned and actual execution time of the job. A job is reported in the job log if it has the status active, finished, or canceled. A red alert is generated if the job exceeds its scheduled start time, remains in the Ready status for a long time, or was canceled.
Log of Current Job (Job_Monitoring_Joblog)	In addition to possible error messages, this node displays the start, each step, and the end of each job that matches the relevant name pattern; logs for different jobs are separated by an empty line.
Runtime (Job_Monitoring_Runtime)	Runtime of the current job of a chain of periodic jobs. If the current job has not yet been started, the node is green and the value for the runtime is 0.
Delay (Job_Monitoring_Delay)	Delay of the current job of a chain of periodic jobs; if the planned start time of the current job has been exceeded and the job has not yet started, the node displays the difference between the measurement time point and the planned start time
Delay + Runtime (Job_Monitoring_dplusr)	Total of Delay and Runtime
History (Job_Monitoring_History)	Like the entries in the Status attribute (see above), however, not only the last entry, but a history of previous entries (choose the Display Details button (), to display the history) The entries also contain runtimes and delays. To improve clarity, these values are displayed in the following units: t £ 300 sec. : Displayed in seconds 300 sec. < style=""> Displayed in minutes t ³ 1 day: Displayed in days

Customizing Alert Generation

· Runtime, Delay and Delay + Runtime

Threshold values are already assigned to these performance attributes by default, so that an alert is generated as of a defined runtime or delay. To change the threshold value, select the desired performance attribute and choose Properties (see Changing Properties and Method Assignments). Ensure that you choose Edit ® Properties ® Use for individual MTE so that you do not change the threshold values for the other monitored jobs.

· History and Log of Current Job

By default, these log attributes always have the color green. However, you can also assign a yellow or red alert to particular messages of the attribute. To do this, choose Properties and specify the class and ID of the desired message on the Filter tab page.

To determine this data for a message of the log attribute, follow the procedure below:

i. Select the desired log attribute and choose the Display Details button ().

ii. The Monitoring Attributes - Detail Data screen appears. To do this, select any row from the list of messages and choose Current Display Variant ().

iii. The Change Layout screen appears. Ensure that the fields for message class (MsgKlasse) and the message ID (MsgId) are displayed, and accept the changes.

iv. The class and ID of the message are now displayed in the list.

Monitoring the Database Using the Alert Monitor

Using the alert monitor, you can monitor the following objects:

• SpaceManagement
• Performance
• Health
• Consistency

Procedure

1. To call the alert monitor, choose Tools ®
CCMS ® Control/Monitoring ® Alert Monitor. Alternatively, call transaction RZ20.
2. Expand SAP CCMS Monitor Templates.
3. Choose Entire System.
4. Open the MTE (monitor tree element) Database. The system displays the following monitoring objects:

Monitoring Object	Task:
SpaceManagement	Monitors the space situation in your database. State on Disk (iSeries)
Performance	Monitors database performance. Database Monitor (iSeries)
Health	Monitors ASP usage. In the standard configuration of your SAP System, the database library is located in ASP1.The journal receivers are in ASP2. This separation avoids disk failure. When the ASP2 is filling, the system starts storing journals in ASP1. This is called ASP overflow. ASP overflow is dangerous because it does not ensure possible data recovery.
Consistency	Monitors the database tables and checks for missing unique indexes (it also takes the SAP exception table into account). Monitors consistency between ABAP Dictionary and database. There are no thereshold values to be maintained for this monitoring object. Green: Unique indexes exist for all database tables. Red: At least one unique index for a database table missing. Actions: Create the missing unique indexes in the ABAP Dictionary (transaction SE11) in your SAP System.

To display up-to-date and detailed information about what the alerts mean and how you should react, use the online help in the SAP System.

Result

If you use the alert monitor continually during production operation, you can find out quickly and easily whether your database has problems. The result is a more highly tuned database and reduced downtime.

Monitoring the Operating System Using the Alert Monitor

Using the alert monitor, you can monitor the following objects:

• CPU
• Paging
• OS_Collector
• Lan
• Filesystems
• MainStoragePools

Procedure

1. To call the alert monitor, choose Administration ® CCMS ® Control/Monitoring ® Alert monitor. Alternatively, call Transaction RZ20.
2. Expand SAP CCMS Monitor Templates.
3. Open the MTE (monitor tree element) Operating System. The monitoring objects CPU, Paging, OS_Collector, Lan, Filesystems, and MainStoragePools appear.

Monitoring Object	Task
CPU	Monitors CPU utilization
Paging	Monitors page faults
OS_Collector	Checks whether the operating system collector is running.
Lan	Monitors LAN activity.
Filesystems	Monitors the % ASP (auxiliary storage pool) used.
MainStoragePools	Pools, for example, active to wait

For more information, see the Operating System Monitor.

Result

If you use the alert monitor continually during production operation, you can find out quickly and easily whether there are problems with the operating system.

Monitoring Memory Management Using the Alert Monitor

Using the alert monitorAlert-Monitor, you can monitor the following objects:

• R3AS4RollMgmtResources
• R3AS4EsMgmtFreeResources

Procedure

1. To call the alert monitor, choose CCMS ® Control/Monitoring ® Alert monitor. Alternatively, call Transaction RZ20.
2. Expand the SAP CCMS Monitor Templates.
3. Choose Entire System ® R3BasisSystem.
4. Open the MTE (monitor tree element) MemoryManagement. The monitoring objects R3AS4RollMgmtResources and R3AS4EsMgmtFreeResources appear.

Monitoring Object	Task
R3AS4RollMgmtResources	Monitors roll management resources.
R3AS4EsMgmtFreeResources	Monitors extended memory resources.

Result

If you use the alert monitor continually during production operation, you can find out quickly and easily whether there are problems with memory management.

Method Dispatching Monitor in CCMS

Method dispatchers start data collection and auto-reaction methods. There are four different dispatchers:

· The background dispatcher starts all data collection methods that are executed periodically in the background process (as a job) (see also Defining, Releasing, and Transporting Methods). The associated job SAP_CCMS_MONI_BATCH_DP runs once an hour by default.

· The central system dispatcher is responsible for the central auto-reaction with which alerts from remote systems trigger an auto-reaction in the central monitoring system. The associated job is SAP_CCMS_CENSYS_DISPATCHER.

· The dialog dispatcher starts all data collection methods that are executed periodically in the dialog process (see also Defining, Releasing, and Transporting Methods).

· The agent dispatcher runs on the host of the CCMS agents SAPCCMSR and SAPCM3X. It starts data collection methods there every minute or every ten minutes, the results of which are reported to the central monitoring system.

Use this monitor to monitor the error-free execution of the data collection methods using the method dispatcher messages.

As the monitoring architecture is an infrastructure with a modular structure, problems in certain methods affect only certain monitoring tree elements (MTEs). The majority of the monitoring functions of the monitoring architecture are not affected by method errors.

This monitor starts from the error messages of the dispatcher. An alternative approach would be to start from the individual MTEs and to display errors that occur during data collection or the auto-reaction for the MTEs to which the methods are assigned. To do this, use the Technical View: Status Data Collector and the Technical View: Status Autoreaction.

Integration

This monitor displays a section of the CCMS_Selfmonitoring monitor.

Features

The monitor contains the following MTEs; the MTE class of the attributes is CCMS_Tooldispatching_Messages in each case:

MTE	Meaning	Additional Information
Tooldispatching (central system)	Most critical message of the central system dispatcher during the last 30 minutes (the dispatcher runs centrally system landscape-wide)	CCMS Selfmonitoring Monitor for System-Wide Data
Tooldispatching (long running tasks)	Most critical message of the background dispatcher during the last 30 minutes (the dispatcher runs centrally system-wide)
Tooldispatching (short running tasks)	Most critical message of the dialog dispatcher during the last 30 minutes (the dispatcher runs on all application servers of the monitored systems)	CCMS Selfmonitoring Monitor for Instance-Specific Data
Tooldispatching (CCMS agent)	Most critical message of the agent dispatcher during the last 30 minutes (the dispatcher urns on the hosts on which the CCMS agents SAPCCMSR and SAPCM3X are installed)

To obtain the newest messages of each dispatcher, select the node and choose Display Details (). The system displays the Monitoring Attributes ‑ Detail Data screen with a list of the newest messages of the dispatcher. You can use this list to find out, for example:

· Which methods run when and for how long

· The number of MTEs provided with data by each method

· Which method provides which MTEs with data (for the agent dispatcher)

· Runtime and error messages output by the started methods

Activities

To start the monitor, follow the procedure below:

...

1. Start the Alert Monitor by calling transaction RZ20, or choose CCMS ® Control/Monitoring ® Alert Monitor.

2. On the CCMS Monitor Sets screen, expand the SAP CCMS Technical Expert Monitor set.

3. Start the Method Dispatching monitor from the list by double-clicking it.

Remote Application Server Status Monitor in CCMS

You can use this monitor to check the availability of individual application servers. The monitor therefore has a similar task to the Availability and Performance Overview Monitor, although with two important differences:

· Only the application servers on which the CCMS agent SAPCCM4X is active are displayed in this monitor.

· The monitor displays a more detailed description of the availability for each monitored application server that also includes, for example, the start time of the server of the status of the SAP release.

Prerequisites

The CCMS agent SAPCCM4X must be installed on the application server whose availability you want to monitor with this monitor. This means that you can only monitor application server of SAP systems with an SAP release of 4.0 or above.

Features

There is a separate subtree in the monitor for each application server. Each subtree consists of the following monitoring tree elements (MTEs):

MTE Name (MTE Class)	Description
Description (CsmTaskR3Instance.Text)	Information about the monitored application server: · SAP system to which the server belongs (in figure above: C12) · Name of the server (here Host4_C12_01) · Host name of the application server (here Host4) · SAP release of the server (here 4.6D)
Status (CsmTaskR3Instance.Status)	Information about whether the agent that is monitoring the server is active or inactive, and how long it has been in that state
Log (CsmTaskR3Instance.Log)	Log file in which the agent writes additional information about the application server, such as how long the server has been active
Heartbeat (CsmTaskR3Instance.Heartbeat)	Time since the last test of whether the application server is still active; if the server is inactive, this attribute contains the value 0 sec
Availability (CsmTaskR3Instance.Availability)	Percentage of the time in which the application server is active (by default in the last 15 minutes; you can change the time period in the Properties of the MTE class)

Activities

To start the monitor, follow the procedure below:

...

1. Start the Alert Monitor using transaction RZ20 or choose CCMS ®Control/Monitoring ® Alert Monitor.

2. On the CCMS Monitor Sets screen, expand the SAP CCMS Technical Expert Monitorset.

3. Start the Remote Application Server Status monitor from the list by double-clicking it.

GRMG Self-Monitoring Monitor in CCMS

Use this monitor to monitor the correct functioning and configuration of the Generic Request and Message Generator (GRMG). The monitor consists of two subtrees:

· You can display the status of each GRMG scenario. You can therefore check whether it was possible to perform an availability check correctly or not.

· You can have GRMG Customizing files automatically uploaded into the central monitoring system and started. The prerequisite for this is that the Customizing files are in a specific directory to which a CCMS agent has read authorization, and that the file follows a naming convention (see also SAPCCMSR.INI: Configuration File of the CCMS Agents). If GRMG Customizing files are automatically uploaded, information about the relevant CCMS agent is displayed in this subtree.

If you have set the parameter TRACE = X in the data collection method GRMG_TRIGGER, messages of the method (such as start of scenarios, scenario errors, newly uploaded scenarios…) are also written to the data supplier log. You can find this log in the CCMS Selfmonitoring Monitor, in the subtree MoniInfra_ ®DataSupplier ® Log.

Prerequisites

You have performed the customizing of the GRMG monitoring.

Activities

To display this GRMG self-monitoring data, follow the procedure below:

1. Choose CCMS ® Control/Monitoring ® Alert Monitor, or call transaction RZ20.

2. Open the SAP CCMS Technical Expert Monitors monitor set, and start the GRMG Selfmonitoring monitor.

The status of the GRMG scenarios is also displayed in the normal monitor for availability monitoring. This is the monitor Availability and Performance Overview of the monitor set SAP CCMS Monitor Templates (see Displaying the Availability Monitoring with the GRMG in the Alert Monitor).

Features

Scenario Execution Subtree

You can see here whether the GRMG application was available and returned a valid response. You can obtain the following information from the subtree for a scenario:

· If the subtree is green, the GRMG application was available and returned a valid response. The availability of the component is displayed in the normal associated subtree (see Displaying the Availability Monitoring with the GRMG in the Alert Monitor).

· If the subtree is red, the monitoring architecture could not execute the scenario. In this case, a corresponding error message is displayed in the Run Status/Error Messages monitoring attribute in the subtree.

To obtain additional information about possible errors, select the monitoring attribute Run Status/Error Messages, and choose Display Details. If possible, HTTP headers including return codes and status reasons are displayed.

Note that if a scenario error occurs, the normal subtree is no longer provided with data and the associated values will become obsolete. A scenario error does not necessarily mean that the monitored component is not available.

The following scenario errors can occur, and are listed below with their most probable causes:

HTTP_POST Errors

The error description contains the prefix Reason for HTTP POST Failure.

Error Description	Possible Cause
· HTTP communication failure · Connect failed · Timeout occurred	· The URL specified in Customizing points to a host or port that does not exist. Check that the URL is correct, and whether the application that listens at the port is running. · The HTTP server for the URL is not running. In this case, start the server. Note that the monitored components that are running on the same server will also not be available in this case.
· TCPIP error occurred · Data error occurred	There are problems in the network configuration or the network operation.
· Internal error occurred	There are problems in the HTTP service of the monitoring system; check the status of the service with transaction SMICM.
· System failure occurred	There are problems with the HTTP server that is specified in the URL of the scenario.
· Argument not found · Plugin not active · Internal error · HTTP invalid state	There are problems in the HTTP client functions of the central monitoring system; check the status of your HTTP operation with transaction SMICM.
· Destination not found · Not authorized to use HTTP destination	There are problems with the RFC connection of type HTTP (which you specified in Customizing instead of a URL); the connection does not exist, or the required authorizations for its use are missing.

Scenario Errors

The error description contains the prefix Reason for scenario failure.

Error Description	Cause
· No message returned	This scenario error often occurs, if the response from the URL to the GRMG request is an HTML document rather than an XML document. The XML parser cannot return a specific error message in this case. This is usually because the GRMG application specified in the URL does not exist on the specified host. The Web server returns an HTML page Page not found or another non-XML page, which the parser cannot interpret. You should therefore check that the GRMG application is correctly installed on the target host and is operating correctly.
· No response for any component in request · >	This error message can occur if the response of a GRMG application does not return a status for any of the components specified in the GRMG request. Check whether the components in the GRMG Customizing file match those that are monitored by the GRMG application. You can also compare the GRMG request and the GRMG response directly by temporarily activating the trace (level 3) on the central server of the monitoring system in transaction SMICM.
· Any message about an invalid XML format · >	This error message occurs if there are formal DTD errors, such as tags that are not closed. You can check GRMG response directly by temporarily activating the trace (level 3) on the central server of the monitoring system in transaction SMICM.
· Any message about the CCMS monitoring architecture, such as Invalid TID or Wrong segment	There are problems with the CCMS monitoring architecture. Check the CCMS Selfmonitoring monitor for other alerts, and ensure that you have started the monitoring with the GRMG only on the central server of the monitoring system.

Customizing File Pickup Subtree

This subtree displays information about the automatic uploading of GRMG Customizing files. In general, these files are automatically uploaded to the central monitoring system and the associated GRMG scenario is started if the Customizing file is in the directory and has the prefix :

MTE Name (MTE Class)	Meaning
Upload Log (GRMG_UPLOAD_LOG)	Log for automatic uploading of Customizing files
Upload Agent (GRMG_UPLOAD_AGENT_NAME)	CCMS agent that loads the files of the directory below into the central monitoring system
Last data supplier run (GRMG_UPLOAD_DSRUN)	Last run of the data collection method that loads the Customizing files into the central monitoring system; by default, this is done once an hour If you want to start the data collection method immediately, use transaction SE38 on the central instance to run the program SAPMSSYT.
Upload Directory (GRMG_UPLOAD_DIRECTORY_NAME)	Directory in which the system searched for the Customizing file that the above CCMS agent loaded into the central monitoring system.
File specification (GRMG_UPLOAD_DIRECTORY_NAME)	Naming convention that the Customizing file must follow for the above CCMS agent to upload it into the central monitoring system.
Most recent file timestamp (GRMG_UPLOAD_FILE_TIMESTAMP)	Timestamp of the last change to the GRMG Customizing file that was uploaded to the central monitoring system using this agent

Monitoring with the Generic Request and Message Generator start page

CCMS Selfmonitoring Monitor for System-Wide Data in CCMS

The SAP CCMS Technical Expert Monitors monitor set contains the predefined CCMS Selfmonitoring monitor, which displays the status of the monitoring architecture and of the Alert Monitor. The monitor displays, among other things, whether the Alert Monitor was able to perform the following actions:

· Start the data collection methods for which it is responsible

· Assign and access the shared memory

· Set up the RFC connections to remote systems and components

Both the CCMS agents and individual Alert Monitor methods (data collection methods and auto-reaction methods) can display problems and their status in the Selfmonitoring tree.

The monitor consists of multiple subtrees; on the one hand, the system-wide subtree with the title CCMS Selfmonitoring below the relevant system (in the example above, the system CEN), on the other hand, the instance-specific subtrees for the monitored servers and active CCMS agents (see CCMS Selfmonitoring Monitor for instance-specific data). This section provides an introduction to the monitoring tree elements (MTEs) of the system-wide subtree.

Features

The subtree consists of the following monitoring objects:

· Tooldispatching (longrunning tasks) (MTE class CCMS_Tooldispatching)

Methods can run in dialog or in background processing. The latter are started in the monitoring architecture by the background dispatcher (SAP_CCMS_BATCH_DISPATCHER), which runs periodically.

The dispatcher runs once system-wide, rather than on each individual instance, which is why the associated monitoring object is in the system-wide subtree. The dispatcher messages are displayed under Messages.

As the monitoring architecture is an infrastructure with a modular structure, problems in certain methods affect only certain MTEs. The majority of the monitoring functions of the monitoring architecture are not affected by method errors.

· Startuptools once per system (MTE class CCMS_Tooldispatching)

You can also have methods that run in background processing started by the background dispatcher for startup methods (SAP_CCMS_STARTUP_TOOL_BATCH_DP), which runs the methods immediately after the start of a monitoring segment

Methods that are started by this dispatcher can add their own status MTEs in this subtree, meaning that you can also find runtime and error messages here.

· Runtime (MTE class CCMSSelfMoniRunTime)

- AlertsInDB (MTE class CCMSSelfMoni-AlertsInDB)

This performance attribute displays the total number of alerts in the alert database. When you complete an alert, it is stored in the database. If the system generates an alert here, the monitoring architecture starts an auto-reaction method that reorganizes the completed alerts and deletes older alerts. You can use the threshold value for this alert to control how many completed alerts are retained.

You can reorganize the completed alerts at any time using the analysis method assigned to this MTE, irrespective of alerts. When doing so, you can specify the date before which all completed alerts are to be deleted.

- SalcCache (MTE class CCMSSelfMoniSalcCache)

The monitoring architecture includes various caches in which the assignment of MTEs to MTE classes is stored. These caches accelerate the creation of the monitors and minimize the number of RFC calls required.

- AlertsWithGUID (MTE class CCMSSelfMoni-AlertsWithGUID)

This node contains the number of alerts in the table ALALRTGUID. Alerts are stored there for the MTEs to which the sending of alerts to the central alert framework is assigned as an auto-reaction method (see Forwarding Alerts to Alert Management (ALM)). The alert data of table ALALRTGUID is required to allow communication between the CCMS and the Alert Framework when sending the alerts.

The table ALALRTGUID is regularly automatically reorganized. Automatic reorganization is assigned to this node as an auto-reaction method, and manual reorganization is assigned as the analysis method.

- RouteCache (MTE class CCMSSelfMoniRouteCache)

Contexts and segments of remote monitored systems are stored in this cache. You can also check this in the Topology Browser of the monitoring architecture.

· Central Performance History (MTE class CPH_SELFMONITORING)

The Central Performance History (CPH) allows you to save performance values of the monitoring architecture long-term, and to output these values in reports to compare the current performance data with its earlier development.

This subtree contains the nodes for the self-monitoring of the CPH. For a detailed description of this subtree, see Selfmonitoring of the Central Performance History.

· XML_Selfmonitoring (MTE class XML_SelfMonitoring)

You can transfer data to the monitoring architecture using XML documents with the XMW interface. This data is displayed like all other data in the alert monitor. This subtree contains the nodes for the self-monitoring of the XMW interface. For a detailed description of this subtree, see Selfmonitoring Monitor for the XMW Interface.

· SAPMSSYT (MTE class CCMSSelfMoniSapmssyT)

SAPMSSYT is a data collection method of the monitoring architecture that runs as a job on the monitored systems. During its runtime, the job occupies a work process on the monitored system. SAPMSSYT runs once an hour.

The main tasks of SAPMSSYT are:

- Distribution of the method assignments to MTE classes on remote systems in the context of the central auto-reaction; it also determines data for the self-monitoring of all CCMS agents.

- Checking the CCMS agents

You can find SAPMSSYT messages under Messages (MTE class CCMSSelfMoniSapmssyTMessages); SapmssyT_Runtime (MTE class CCMSSelfMoniSapmssyTRuntime) gives the runtime of the job.

· Tooldispatching (central system) (MTE class CCMS_Tooldispatching)

This subtree displays messages from the central method dispatcher (RSAL_CENSYS_TOOL_DISPATCHING) under Messages. This dispatcher makes central auto-reactions possible when alerts are triggered on remote systems. The process of this is as follows:

a. An alert occurs in the monitored system to which a central auto-reaction method is assigned.

b. A CCMS agent recognizes the alert and sends the MTE and the alert data to the central system using RFC.

c. In the central system, the event SAP_CSM_TRIGGER_CENSYS_DISPATCH is triggered, which starts the dispatcher RSAL_CENSYS_TOOL_DISPATCHING. This job calls the corresponding central auto-reaction method in the central system and transfers the information about the MTE and the alert to it. It also adjusts the method runtime status in the monitored system using the agent.

For more information about central auto-reactions, see SAP Note 0429265.

· CCMS Agents (MTE class CCMSSelfMoniAgents)

This subtree corresponds to the Selfmonitoring CCMS Agents monitor.

· GRMG_Self-Monitoring (MTE class GRMG_SelfMonitoring)

You can use the Generic Request and Message Generator (GRMG) to monitor the availability of technical components or steps in business processes. For a detailed description of this subtree, see GRMG Selfmonitoring Monitor.

· System Component Repository (MTE class CCMS_SCR_SelfMoni)

This subtree contains the version of the CCMS System Component Repository.

Activities

To start the monitor, follow the procedure below:

...

1. Start the Alert Monitor using transaction RZ20 or choose CCMS ® Control/Monitoring ® Alert Monitor.

2. On the CCMS Monitor Sets screen, expand the SAP CCMS Technical Expert Monitor set.

3. Start the CCMS Selfmonitoring monitor from the list by double-clicking it.