DB Monitor

12/20/2019
Alert Monitor
Generated on: 2019-12-20
SAP NetWeaver 7.5 | SPS16
PUBLIC
Original content: https://help.sap.com/viewer/984899fe989d4efab0409b818433f892/7.5.16/en-US
Warning
This document has been generated from the SAP Help Portal and is an incomplete version of the official SAP product documentation.
The information included in custom documentation may not re ect the arrangement of topics in the SAP Help Portal, and may be
missing important aspects and/or correlations to other topics. For this reason, it is not for productive use.
For more information, please visit the https://help.sap.com/viewer/disclaimer.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22000174&topics=4907442b4cab209ce10000000a… 1/103
12/20/2019
Alert Monitor
Use
The monitoring architecture, a solution within SAP NetWeaver, centrally monitors any IT environments - from individual systems
through networked NetWeaver solutions, to complex IT landscapes incorporating several hundred systems. It is provided in SAP
NetWeaver and can be used immediately after installation. You can easily extend the architecture to include SAP and non-SAP
components.
Alerts form a central element of monitoring. They quickly and reliably report errors - such as values exceeding or falling below a
particular threshold value or that an IT component has been inactive for a de ned period of time. These alerts are displayed in the Alert
Monitor; this reduces the workload for the system administration, since they now only need to watch the error messages, instead of
endless system data.
The Alert Monitor is therefore the central tool with which you can efficiently administer and monitor distributed SAP NetWeaver
solutions or client/server systems. The Alert Monitor displays problems quickly and reliably.
Implementation Considerations
If you want to use the Alert Monitor for central monitoring (that is, you want to monitor the systems of your IT landscape from a central
monitoring system), you must perform various con guration steps yourself. These are described under Con guring the Monitoring
Architecture.
Features
The Alert Monitor provides the following functions:
You can use the Alert Monitor to perform complete and detailed monitoring of all SAP and non-SAP systems, the host systems,
and the database.
All errors generate alerts, which are displayed in a tree structure.
The alerts contain a status indicator with a color and a numerical value. Yellow means a warning, red means a problem, and the
numerical value shows the severity of the reported error. In the tree structure, the most severe alerts are passed upward in the
display hierarchy. If a tree node is not displaying an alert, there is also no error in the entire branch below it.
You can assign certain analysis and auto-reaction methods to the alerts, which contribute to faster processing of the error. If
you double-click an alert, the monitoring architecture starts the assigned analysis method (such as the job administration
transaction for a prematurely terminated job). An auto-reaction method, on the other hand, starts automatically as soon as the
alert occurs. This includes executing operating system commands and sending an e-mail or an SMS message to the system
administration.
The Alert Monitor contains various view in which either the current or the open (that is, the unanalyzed) problem messages are
displayed. Alerts are also archived.
Threshold values, methods, and detailed help for many monitoring attributes and three extensive monitor sets with monitors
for all aspects of system management are prede ned on the basis of Best Practices in the monitoring architecture and are
available in every SAP system.
You can adjust all settings individually, and con gure your own monitors.
You can also use the performance data from the alert monitor for reporting within the SAP Solution Manager.
As of SAP NetWeaver 7.0 EhP2, the Consistency Check of the CCMS Monitoring Infrastructure is available to you. The
associated transactions RZ50, RZ521, and RZ52 provide a variety of functions to check the con guration and runtime of the
CCMS monitoring infrastructure, to display errors, and to correct these automatically. The checks are called from the central
monitoring system (CEN) and include both the CEN itself and the monitored systems.
12/20/2019
More Information
Concept of the Monitoring Architecture
Operating the Alert Monitor
Customizing the Alert Monitor
Concept of the Monitoring Architecture

Purpose
The alerts are displayed in a tree structure in the alert monitor, and assigned a severity and a color (yellow for a warning, red for a
problem). You can see the current status of your system and process alerts here. The alert monitor is based on the monitoring
architecture, which was introduced in SAP R/3 4.0:
The CCMS monitoring architecture is not a monolithic monitoring and administration program. Rather, it offers a exible framework
into which extensive monitoring and administration functions can easily be added.
The elements of the monitoring architecture function largely independently of each other and can, particularly, be further developed
and adjusted independently of each other.
Data Supplier
A data supplier is a program that delivers data to the monitoring architecture. It belongs to one of the individual system
components and creates monitoring objects that report values to the monitoring architecture. The monitoring architecture is
delivered with the data suppliers for the most important components of your SAP system and its environment and can
therefore be immediately used.
12/20/2019
Data suppliers pass their information to the monitoring architecture. The monitoring architecture provides an infrastructure for
gathering and managing system information. The monitoring architecture therefore constantly compares the values reported
by the data suppliers for the monitored objects with threshold values and displays an alert if a value exceeds or falls below a
threshold value.
Data Consumers
A data consumer is a program that reads data from the monitoring architecture; it displays the information transferred to the
monitoring architecture by the data suppliers. SAP delivers both the standard data consumer and other special monitors that
all use the data delivered by the monitoring architecture.
Monitoring Objects and Attributes
A monitoring object describes an object that is to be monitored. A monitoring attribute represents a type of information that is
to be reported for a monitoring object. Monitoring objects include, for example, the CPU in your host system, the database, and
SAP services, such as background processing. Monitoring attributes for a CPU object could be CPU utilization and the average
CPU workload for the last ve minutes.
The alert monitor also provides the administration methods that you need to monitor the system. In this way, you can set threshold
values for alerts and add or adjust auto-reaction and analysis methods: if an alert is triggered, auto-reaction methods react
automatically, and you can use an analysis method to investigate the cause of an alert without leaving the alert monitor. The
monitoring architecture also contains tools for administering and archiving the alerts.
Technical Basics: Data Supplier

Data suppliers deliver all of the values that are displayed in the Alert Monitor. They each belong to the individual system components
and create monitoring objects that report values to the monitoring architecture. These values are displayed in the monitor sets.
The monitoring architecture is delivered with the data suppliers for the most important components of your SAP system and its
environment and can therefore be immediately used. When starting the Alert Monitor, you can see that the data suppliers for reporting
for the following components are already active:
The host systems on which your SAP system is running
The database
SAP instances (application servers) and their services and components
Components outside the system
You do not need to prepare or activate the monitoring architecture. The data suppliers in your system are either started automatically
when the system is started, or are started as they are required. There are two different types of data suppliers:
Passive Data Suppliers are started by the monitoring architecture, which is why they must be de ned there. "Passive" describes the
behavior of the data supplier in relation to the monitoring architecture: it does not start itself, but rather must be started by the
monitoring architecture. Passive data suppliers are also known as data collection methods.
Active Data Suppliers are started by the monitored application rather than the monitoring architecture. These data suppliers are active
in their start behavior in relation to the monitoring architecture.
A data supplier writes the values for the monitored objects in a segment of the shared memory known as the monitoring segment. This
monitoring data can be transferred to the monitoring architecture in two ways:
Using a de ned ABAP interface, in the case of an SAP instance - a free work process is required for this
Using a NetWeaver management agent, for any server; the transfer is performed using a Remote Function Call (RFC)
12/20/2019
Note
Since the connection method using an agent does not require a free work process, the access method is therefore independent of
error states of the SAP instance and therefore more robust. If the central monitoring system is running SAP Web Application
Server 6.10 or above, the CCMS agents also use push technology with which the agents report alerts automatically. This helps to
ensure a good performance, as the central monitoring system then no longer needs to periodically query the agents for alerts. We
therefore recommend that you use agents when connecting remote systems to the central monitoring system.
See also:
Methods
Changing Properties and Method Assignments
Alerts
De nition
The Alert Monitor generates alerts in the monitored systems using threshold values and rules, if the status of the systems deviates
from the norm. These alerts attract your attention to critical situations so that you do not have to search for them yourself. Auto-
reaction methods can inform you about a problem, or react to it in some other way, even if you are not currently working in the Alert
Monitor.
For the system administrator, an alert is an error report or a service request. You should react to every alert. Use the Alert Browser and
the analysis method contained in the Alert Monitor to investigate the alert. If you have solved the problem, or are sure that you can
safely ignore it, set the alert to complete. The system then removes this alert from the display and saves it to the alert database.
12/20/2019
The alert monitor reports alerts up through the monitoring tree. This means that the color indicator for a node is always the color of the
highest alert in all elements of its branch. If, for example, a host system has a red indicator, one or more components in the monitoring
tree for the host system are displaying red alerts.
An alert is uniquely assigned to one monitoring tree element (MTE) in the monitoring tree. The alert is generated when values are sent
from a data supplier to an MTE. The alert monitor evaluates this incoming information against alert thresholds. If the incoming data
exceeds or violates a threshold, then the alert monitor triggers an alert. The alert monitor generates an alert for every abnormal status
and keeps track of every alert until it is set to status complete.
Note
You can also use a heartbeat alert to con gure an MTE in such a way that an alert is generated if a data supplier fails to report
values (see Triggering a Heartbeat Alert if No Values Are Reported).
Alert Threshold Values and Assignment to Attribute Groups
Reliable values for threshold values and the severity of alerts are prede ned for all monitoring attributes. These settings are based on
our extensive experience with SAP production systems.
Monitoring attributes are combined into attribute groups. An attribute group contains the threshold values that have common
associated monitoring attributes. In this way, all instance-speci c occurrences of the Response Time monitoring attribute belong by
default to one attribute group. This means that the same threshold values are set for the response time in all instances of a system. If
you want to change threshold values, you only need to change the value for the corresponding attribute group.
Alert Colors and their Meanings
Color Meaning
red Problem or Error
yellow Warning
green Everything OK
gray No information available
Note
By default, no alert is generated in the case of a green message. However, you can activate the generation of "green alerts" for
selected nodes (see Working with All-Clears (Green Alerts)).

De nition
A monitoring object represents a component of the IT environment that is to be monitored, such as the CPU of a server, the dialog
system, or background processing. Monitoring attributes are values, statuses, or texts that are reported to this object, such as the CPU
utilization, or the average response time in the dialog system. A monitoring attribute can be assigned an alert. The selection of the
monitoring objects is performed using the data suppliers that exist for all areas of system management.
12/20/2019
Structure
Monitoring objects and their attributes are displayed in the alert monitoring tree as individual nodes in a hierarchical tree. If the data
reported to the monitoring architecture exceeds or falls below the de ned alert threshold values, an alert is triggered in the
corresponding monitoring tree element.
There are ve different types of monitoring attributes:
Attribute Type Description
Performance Attribute Collects reported performance values and calculates the average
Status Attribute Reports error message texts and alert status
Heartbeat Attribute Checks whether components of the SAP system are active; if no values
are reported for a monitoring attribute for a long time, it triggers an
alert
Log Attribute Checks log and trace les (these attributes can use an existing log
mechanism, such as the SAP system log, or they can be used by an
application for the implementation of a separate log)
Text Attribute Allows a data supplier to report information that is not evaluated for
alerts; the text can be updated as required
You can assign methods to monitoring attributes. A method can be a report, a function module, an SAP transaction, or a URL that is to
executed as a reaction to an alert. You can execute these methods within the Alert Monitor. If you double click, for example, the MTE for
prematurely terminated jobs, the monitoring architecture automatically starts the job management transaction, in which the job
reported in the MTE is already selected.
See also:
Properties of Log Attributes
Properties of Performance Attributes
Properties of Status Attributes
MTE Classes and Attribute Groups

De nition
The alert monitoring tree consists of individual monitoring tree elements (MTEs). They are either components of your IT landscape
that are to be monitored (monitoring objects), or values, statuses, or texts that are reported for these objects (see Monitoring Objects
and Attributes). These MTEs are assigned to MTE classes and attribute groups in the monitoring architecture:
An MTE class describes the general properties and method assignments that are common to a particular group of monitoring
tree elements.
An attribute group describes the common threshold values for alerts for a particular attribute type.
Use
MTE classes and attribute groups simplify the Customizing of the Alert Monitor, since you do not need to change threshold values,
properties, or methods individually for every MTE, but only for the corresponding attribute group or MTE class.
MTE classes also simplify the creation of your own rule-based monitors, since you do not need to specify every MTE individually when
constructing the alert monitoring tree, but rather only the corresponding MTE classes.
12/20/2019
The classi cation of the MTEs to MTE classes and attribute groups is already fully prede ned. You do not need to make any changes to
be able to use this classi cation.
Note
If you want to change the properties, methods, or threshold values, the system displays a message informing you whether the
change refers only to an individual MTE or to the corresponding MTE class or attribute group. You can change this default value (see
Changing Properties and Method Assignments).
Examples
MTE Class:
The Space Management monitoring object and the Free Space monitoring attribute both belong to the MTE class
CCMS_DB_Freespace_MT. This means that both MTEs have the same general properties and method assignments.
Attribute Group:
All instance-speci c occurrences of the Response Timemonitoring attribute belong by default to a single attribute group. This
means that the same threshold values are set in all of the instances of a system and that changes to the threshold values apply
to all instances.
Methods
Use
You can assign methods to monitoring attributes, and access the method de nitions using the Customizing transaction for the Alert
Monitor, RZ21. A method can be a report, a function module, an SAP transaction, or a URL that is to be executed as a reaction to an
alert. You can execute these methods within the Alert Monitor. If you double click, for example, the monitoring tree element (MTE) for
prematurely terminated jobs, the monitoring infrastructure automatically starts the job management transaction, in which the job
reported in the MTE is already selected.
All methods required for standard monitoring functions are prede ned. You only need to change the method assignments if you add a
new method or if you want to replace one of the SAP standard methods with a method of your own. You can transport method
de nitions to other SAP systems. However, this is only necessary for your own method de nitions; the methods delivered by SAP
already exist in all systems with the same SAP release.
Monitoring tree elements are assigned to MTE classes. An MTE class describes the general properties and method assignments that
are common to a particular group of monitoring tree elements. The MTE class is also used in rule-based monitor de nitions.
Example
For example, the Space Management monitoring object and the Free Space monitoring attribute both belong to the
CCMS_DB_Freespace_MT MTE class. This means that the two MTEs share general properties and method assignments.
You can also group methods assigned to MTE classes in properties variants. This has the advantage that you can run different methods
in different properties variants, making the monitoring of SAP systems more exible. Another advantage is that long-running methods
can be run in the background.
The following methods exist:
Data Collection Method
12/20/2019
These methods allow the collection of information about the SAP system and its environment that is then reported to the
monitoring infrastructure. The method starts automatically or is automatically started by the Alert Monitor at speci ed time
intervals. A data collection method is, for example, an ABAP program that is responsible for the collection of information about
an MTE.
For the monitoring infrastructure to be able to start a passive data collection method, the corresponding node to which this
method is assigned must exist. However, this is not always the case when the system is started, since the monitoring contexts
with the nodes must rst be created. It is therefore possible to call the methods when the system is started so that the
corresponding nodes can be created with the rst run of the method. To ensure this, in the properties of the method, on the
Control tab page, activate the Execute method immediately after monitoring segment start indicator. Methods for which this
indicator is activated are known as Start-Up Methods.
Note
You cannot change the assignment of data collection methods in the alert monitor, since this would affect the correct
execution of the data supplier. Even if you are creating your own data supplier, the assignment of the data collection
methods must be performed using the data supplier and not by making changes in the Alert Monitor.
Auto-Reaction Method
These methods start automatically when an alert is triggered. Almost no assignments are made in the standard SAP system;
however, there are several prede ned auto-reaction methods in the monitoring infrastructure that you can assign to any MTE
classes:
· Sending an e-mail
· Executing an operating system command
· Executing an auto-reaction in the central monitoring system
Analysis Method
This method allows a detailed analysis of error situations without leaving the Alert Monitor. You start an analysis method
manually when you want to display information or investigate an alert.
An analysis method is, for example, an ABAP program for displaying information about a node in the monitoring tree and for
collecting information about the problem that triggered an alert in this node.
Note
You can display the current method assignments of the MTEs of a monitor and the status of the assigned data collection and
auto-reaction methods in an overview screen. To do this, display the technical views of the Alert Monitor.
More Information

Purpose
The following section contains a short overview of the operation of the Alert Monitor. For more information, see the Tutorial for the
Alert Monitor.
Process Flow
12/20/2019
To perform a a periodic check of your monitored systems, follow the procedure below:
1. Start the alert monitor by calling transaction RZ20.
The system displays the CCMS Monitor Sets screen. Every monitor set contains monitors that deliver information for a particular
system management topic. Expand a monitor set and choose the required monitor by double clicking it.
You can copy, change, and create new monitor sets and monitors. The icons after the monitor sets display whether a monitor set was
delivered by SAP ( ) or created by the customer ( ), and whether you are authorized to change the set ( ) or not ( ).
1. The system displays the tree structure of the desired monitor. The system is displaying the Current Status view in which you
can monitor the current values of your monitoring attributes. If you want to analyze an alert, choose the corresponding
monitoring tree element (MTE) by double clicking it.
2. You can then check what has happened since the last check in the system. Use the Open Alerts monitoring view to see if there
have been yellow or red alerts (warnings or problems). If you choose an alert in this view by double clicking it, the system
displays the Alert-Browser. This displays all alerts that have not yet been analyzed in a at hierarchy.
3. After you have analyzed an alert and taken the necessary action, set it to Completed to remove it from the display of open
alerts.
See Also:
Change Views: Current Status/Open Alerts
Tutorial for the Alert Monitor

Use
The following section provides a detailed guide to using the Alert Monitor.
Procedure
1. Choose CCMS → Control/Monitoring → Alert Monitor, or call transaction RZ20.
The system displays the CCMS Monitor Sets.
2. Expand one of the monitor sets by placing the cursor on the CCMS monitor sets and then choose Edit → Expand Tree.
SAP delivers various standard monitor sets, such as SAP CCMS Monitor Templates or SAP CCMS Technical Expert Monitors.
These monitor sets are always available.
3. Display the Entire System monitor of the SAP CCMS Monitor Templates monitor set by placing the cursor on the monitor and
choosing Start Monitor.
The monitor displays the tree in the last-used format. The monitoring tree is a hierarchical display of monitoring objects
(system components) and monitoring attributes (information types for objects) in the system.
For this tutorial, expand the alert monitoring tree, if the entire hierarchy is not displayed. Place the cursor on the Entire System
line and choose Edit → Tree → Expand Tree → Expand Subtree.
Note
In addition to the Entire Systemmonitor, there are also prede ned monitors for particular purposes. For example, if you are a
database administrator, you can open the Database monitor instead of the Entire System monitor.
Another special monitor is the CCMS Selfmonitoring monitor in the SAP CCMS Technical Expert Monitors monitor set. This
monitor displays possible problems in the alert monitor and the monitoring architecture. Check in this monitor whether all of
the data collection methods started by the Alert Monitor are running correctly.
4. Check the current status of your system.
a. Display the current system status in your monitor.
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=22000174&topics=4907442b4cab209ce10000000… 10/103
12/20/2019
Choose the Current Status view, if it is not already selected. In the Current Status view, you can see the performance
values and status messages that have been most recently reported to the Alert Monitor.
Note
Older alerts that are still open (that is, not yet completed) are no longer labeled with colors.
b. Check the color indicators in the monitoring tree.
The colors of the nodes in the tree mean the following:
Green: The component is running correctly.
Yellow: The system is issuing a warning.
Red: The system is reporting a problem or a critical state.
Gray: No data is being delivered for the node.
Note
To display a legend for the colors and icons used in the Alert Monitor, choose Extras → Legend.
The alert monitor passes the highest alert level up the monitoring tree. For example, if the monitoring tree element
(MTE) with the name of your system is green, this means that all components in the monitoring tree for the system have
this status. There are therefore no warnings or problems.
Choose an MTE by double-clicking it to start the associated analysis method. The analysis method displays more detailed
information about the current status of the MTE.
You can optionally specify an automatic refresh of the display. Choose Extras →Display options, and switch to the Generaltab. In
the Refresh display box, select the option Yes, interval and enter the interval for the refresh. The default value is 300 seconds or
longer. If the automatic refresh is deactivated, the alert monitor displays the data that was available when the alert monitor was
started.
5. Check what has happened recently in the Open Alerts view
Caution
The color indicators in this view do not show the current status of the system (see Changing Views: Current Status/Open
Alerts).
At the start of your working day or after your lunch break, you can use the Open Alerts view to check what has happened in the
system during your absence. The monitor stores the alerts for you, even if the status that triggered the alert has improved in the
meantime.
6. React to an alert.
In the monitoring tree, yellow entries mean warnings and red entries mean errors.
Proceed as follows:
Ensure that you are in the Open Alerts view.
The monitor is now displaying how many alerts exist for each MTE. It is also displaying the most important of the waiting alert
messages.
Place the cursor on a yellow or red MTE and choose Display Alerts.
The system opens the Alert Browser and displays the open alerts for the relevant MTE. The Alert Browser displays all alerts in
the branch of the tree that you selected. Move the cursor further up the monitoring tree to display a wider range of alerts. Select
an MTE on the lowest level to display only the alerts for this MTE.
Analyze an alert.
12/20/2019
Each line in the Alert Browser provides overview information for an alert, including the alert message.
The browser also provides two additional information sources. Select an alert and choose one of the following buttons:
Start Analysis MethodBy choosing this button, you start the transaction for problem analysis or the analysis method for an alert. New
analysis methods are constantly being added to the system. Not all MTEs already have an analysis method (see Starting Methods).
For problems with buffers, for example, you can start the Buffer Tuning Summary from the Alert Monitor.
Display Details You can use this function to display the details for the monitoring tree element. These include the current values or
status messages, the alert threshold values, and the performance data for the last measurement period (only for performance MTEs).
You can display the performance data graphically by selecting the relevant line and choosing Display Performance Values Graphically.
1. If the alert is resolved, set it to Complete.
Once you have analyzed the problem and have either resolved it or ensured that you can safely ignore it, you can set the
problem to Complete.
Select the alert and choose Complete Alert. The Alert Monitor deletes the alert from the list of open alerts (see Completing
Alerts).
Start and Change Monitors

Start and Change Monitors
Use
A monitor provides monitoring objects and attributes for a system administration topic. These monitors are grouped into monitor sets
that each contain several monitors.
To be able to quickly check all relevant monitoring objects (for example, during a periodic check of your monitored systems), it can be
useful to switch between monitors quickly and without intermediate steps.
Start a Monitor
2. Expand the monitor set that contains the monitor that you require, choose Start Monitor, or choose the desired monitor by
double clicking it.
Switch Between Monitors
You can switch between monitors in a monitor set without rst closing the monitor that you have open.
2. Expand the monitor set that contains the monitors that you require and choose Start Monitor.
3. To switch to the next monitor in the monitor set, choose Goto → Previous Monitor ( ) or Next Monitor ( ).
Actions in the Alert Monitoring Tree

12/20/2019
Use
The alert monitoring tree provides you with an overview of the system status of monitored systems. There are various options for
displaying and checking the alerts that have occurred. The most important commands that you can use in the alert monitoring tree are
described here.
Activities
Choose Expand Tree ( ) or the folder icon ( ) directly in front of the relevant branch in the Alert Monitor to expand the
individual branches of the alert monitoring tree.
Choose Compress Tree ( ) or the folder icon ( ) directly in front of the relevant branch in the Alert Monitor to compress the
individual branches of the alert monitoring tree.
Select an element in the monitoring tree and choose F1 to display a description of the element.
If the central data cache is active in the display of the alert monitoring tree (this sentence is then displayed at the top of the
monitoring tree), you can delete the entries of the central data cache and regenerate the monitor. To do this, choose Refresh
and Invalidate Data Cache ( ).
This command is useful if you want to ensure that the alert monitoring tree is correctly displayed after making changes to individual
monitoring tree elements or entire subtrees (see Setting Up the Central Data Cache).
In the Current Status display, choose an element by double clicking it to start the analysis method assigned to this element. You
can use this to analyze and complete any alerts that exist (see Starting Methods).
In the Open Alerts display, choose an element by double clicking it to start the Alert Browser. This displays all alerts that have
not yet been analyzed.
Choose Display Details ( ) to display the detail data for this element. This includes, above all, the values reported for this
element during the last 24 hours (see Display Detail Data and Tailor Display).
Choose Properties to display the Properties and Methods assigned to the element. These include, above all, the threshold
values for warnings and problems (yellow and red alerts) and the associated analysis and auto-reaction methods.
Choose Extras → Activate Maintenance Function to be able to make changes to monitors. The Change Monitor pushbutton ( )
then appears in addition on the toolbar.
To switch between different monitors or monitor sets, choose Previous Monitor ( ) and Next Monitor ( ).
See also:
Selecting Nodes in the Alert Monitoring Tree
Tutorial for the Alert Monitor

Use
You can only access many functions for monitoring tree elements (MTEs) in the alert monitoring tree once you have selected the
relevant MTEs. This is simplest for individual MTEs, which you can select by selecting the indicator in front of the MTE. There are also
various commands with which you can quickly select a larger number of MTEs.
Procedure
Selecting MTEs in the Tree
To call the individual functions in the table, choose CCMS → Control/Monitoring → Alert Monitor, or call transaction RZ20. Now select
the required monitor and choose Edit → Selections → Select and one of the following options:
Menu Path Function

12/20/2019
Node (MTE) Select the currently selected node
Subtree Select the currently selected node with the complete subtree below
the selected node
All Nodes (MTE) Select all nodes in the current monitor
Objects Only Select all monitoring objects (see Monitoring Objects and Attributes)
below the selected node (including the selected node)
Attributes Only Select all monitoring attributes (see Monitoring Objects and
Attributes) below the selected node (including the selected node)
Nodes (MTE) of a Class Select all MTEs that belong to the same MTE class as the selected
MTE
Deleting Selection of MTEs in the Tree
To call the individual functions in the table, choose CCMS → Control/Monitoring → Alert Monitor, or call transaction RZ20. Now select
the required monitor and choose Edit → Selections → Delete Selections and one of the following options:
Menu Path Function
Node (MTE) Delete the selection of the currently selected node without the
subordinate subtrees
Subtree Delete the selection of the currently selected node with the complete
subtree below the selected node
All Nodes (MTE) Delete the selection of all nodes in the current monitor
Objects Only Delete the selection of all monitoring objects (see Monitoring Objects
and Attributes) below the selected node (including the selected node)
Attributes Only Delete the selection of all monitoring attributes (see Monitoring
Objects and Attributes) below the selected node (including the
selected node)
Nodes (MTE) of a Class Delete the selection of all MTEs that belong to the same MTE class as
the selected MTE
Display Overview of All Selected MTEs in the Monitoring Tree
3. Select the desired MTEs.
4. Choose Edit → Selections → Show selections.
Set Selection Behavior
3. Select Edit → Selections → Selection Behavior.
4. In the Selections by Operation group box select one of the radio buttons Hold or Delete. By doing so, you decide whether the
selection is retained after an operation (such as Display Details).
See Also:
12/20/2019
Elements of the Alert Monitor

The following section describes the most important elements of the Alert Monitor and their relationships to each other.
Purpose
When you start transaction RZ20, the system rst displays the monitor sets available to you. These monitor sets group the monitors.
A monitor set usually consists of different monitors. A monitor is a collection of monitoring tree elements (MTEs) in a hierarchical
structure that deliver information for a particular aspect of system management.
The hierarchical structure of a monitor is the alert monitoring tree. In this tree, you can check the status of your IT system landscape.
The MTEs are nodes of this tree, where the root node also has the name of the monitor.
Different MTEs are Elements of the Alert Monitoring Tree: monitoring summary nodes, monitoring objects, and monitoring attributes.
Monitoring summary nodes (summary MTEs) provide a better overview in the tree, without performing a monitoring function
themselves.
A monitoring object represents a component of your IT environment that you want to monitor (such as the CPU of a server or
background processing), while a monitoring attribute displays a value, status, or text that is reported for this object (for example, the
CPU utilization during the last 15 minutes).
If a value that deviates from the norm is reported for a monitoring attribute, the Alert Monitor generates an alert. The conditions under
which an alert is generated, the criticality of the alert, or which message is assigned to an MTE - all of these are properties of an MTE.
In addition to its properties, an MTE has methods: the data collection method allows the collection of information about the MTE, the
auto-reaction method and analysis method are executed as a reaction to an alert.
To simplify Customizing, the properties and methods do not need to be edited for each MTE individually: There are attribute groups for
attributes, and MTE classes for objects.
Operation and Customizing of the Elements of the Alert Monitor
Element Operation Customizing
Monitor set Creating and Editing Monitor Sets
Transporting Monitor Sets and Monitor

De nitions
Monitor Starting and Changing Monitors Copying, Renaming, and Deleting Monitors
Creating and Changing Monitors
Alert Monitoring Tree Actions in the Alert Monitoring Tree
Methods Starting Methods De ning, Releasing, and Transporting

Methods
Selected Alert Monitor Methods
Properties Properties of Performance Attributes
Alerts Handling Alerts
MTE Classes and Attribute Groups Rule Node: Rule Description and Use
12/20/2019
Monitor Sets
De nition
As a system administrator, you can conveniently monitor your system with monitor sets. A monitor set contains several monitors. In
turn these monitors consist of subtrees of all available objects. You can group the monitors according to task, by setting up several
monitor sets in parallel.
You can either create the monitor sets temporarily, in order to solve a problem and then delete them, or you can store them
permanently in the system.
Use
The SAP System contains three prede ned standard monitor sets:
SAP CCMS Monitor Templates
The monitors in the SAP CCMS Monitor Templates monitor set display the monitoring objects and attributes that are crucial for
the monitoring of your SAP systems and which are used for normal system administration.
SAP CCMS Technical Expert Monitors
Use the monitors in the SAP CCMS Technical Expert Monitors monitor set to monitor the monitoring architecture itself and to
analyze problems in this area.
For example, you can use the CCMS Selfmonitoring monitor for internal monitoring or All Monitoring Contexts to view all
available contexts in your systems.
SAP CCMS Monitors for Optional Components
Use the monitors in this set to monitor components that are not part of the standard SAP system.
See also:
Creating and Editing Monitor Sets
Transporting Monitor Sets and Monitor De nitions
Monitors
Monitors
De nition
A monitor is a set of monitoring tree elements (MTEs) that are arranged in a hierarchical structure (the Alert Monitoring Tree). As
monitors are organized by topic, you can quickly check all of the important objects for this topic. Monitors are combined in monitor
sets.
Use
12/20/2019
The quick collection of information and warning messages for speci c areas of the system is normally part of the daily system
administration work. For most problem situations, only a fraction of the information available in the monitor is required. For database
problems, for example, you only need to work with the monitoring tree elements for the monitoring of the database.
There are therefore different monitors for the Alert Monitor, that each display information for an aspect of system management. These
monitors are grouped into monitor sets. Within the monitoring architecture, you can create, copy, and edit monitors yourself, and
transport monitors to other systems. In this way, you can create monitors that contain precisely the information that you need for your
daily work. You can save and reuse all of your own monitors.
As the de nition process is quick and easy, you can use a monitor of your own not only as a long-term, specialized work center, but also
for short-term problem analysis or special monitoring. If, for example, you want to monitor the response time of a particular server, you
can de ne a temporary monitor that monitors the response time, CPU utilization, and other relevant parameters for this server.
During the de nition of monitors, you can use not only the existing nodes, but also virtual nodes and rule nodes. A virtual node
structures the monitor; it is a heading or a description for the nodes created below it. A virtual node does not have a monitoring
function itself.
A rule node speci es a rule that de nes what should be included in the new monitor. The monitoring architecture interprets the rule
and includes in the monitor the nodes that ful ll the selection criteria in the rule. The rules are regularly reinterpreted, so that your own
monitor automatically corresponds to the current system landscape. A monitor de ned with rules will, for example, automatically
include a newly started SAP application server.
SAP deliver a range of prede ned standard monitor sets with the SAP system. The standard monitors contained in these sets provide
system administrators with a complete overview of the system and ready-to-use views for special tasks such as monitoring the
database, background processing, the operating system, the system log, and the spool system. There is even a monitor for monitoring
the monitoring architecture (CCMS Selfmonitoring).
Alert Monitoring Tree

The monitoring tree is the component hierarchy displayed by the Alert Monitor. If problems occur in your system, they are displayed as
alerts in the monitoring tree. The system displays a schematic representation of the monitoring tree:
12/20/2019
To give a better overview, alerts are assigned certain colors - yellow for a warning and red for a problem - and a numerical value for the
severity of the error. The alert with the highest severity appears at the top of the monitor that displays the monitored IT components
(such as the CPU of a server) including their attributes (such as CPU usage) in a tree structure. In accordance with this, a node of the
tree structure displays the most severe alert of the whole branch below it. If a node is not displaying an alert, there is no error in the
whole branch below it. The system administrator can choose between different Views of the Alert Monitor, and display the current or
open (that is, those that have not been analyzed) problem messages.
See Also:
The Monitoring Architecture: Concept
Components of the Alert Monitor
Elements of the Alert Monitoring Tree

Use
The monitoring architecture displays a tree in theAlert Monitor that contains all monitoring tree elements (MTEs) for your monitored
systems. The elements are clearly structured and arranged in the tree. There are three types of MTEs:
12/20/2019
Summary MTEs (Monitoring Summary Nodes)
These act as titles or headings in the alert monitor and do not have any monitoring functions themselves. No alerts can be
triggered for summary MTEs. However, alert statuses and messages can be displayed.
There are two kinds of monitoring summary node:
Real monitoring summary nodes: are stored in the monitoring segment
Virtual monitoring summary nodes ( ): are not stored in the monitoring segment, but exist only to provide a clearer
display of real MTEs in a monitor
Monitoring objects ( )
Monitoring objects are particular components of your systems that the monitoring architecture monitors (such as
SpaceManagement or CPU). They are created by thedata suppliers. The objects combine various monitoring attributes that
belong to the same component or the same attribute of a system.
Monitoring attributes
Monitoring attributes are data types that can be reported for a particular monitoring object. The monitoring object CPU, for
example, has the attributes CPU utilization and 5MinuteLoadAverage. A data supplier reports data for these attributes, and the
alert monitor triggers alerts for the attributes if the data violates the de ned alert thresholds.
See also:
Properties of Monitoring Objects and

Attributes
De nition
Monitoring objects and attributes are assigned various properties. These include:
· An explanatory text
· When and under which conditions Alerts are generated
· The criticality that an alert is assigned
· The maximum number of alerts that are to be stored for an attribute
The properties therefore provide settings options for the alert that can be assigned to a monitoring attribute, and also more detailed
information through the assigned message. In the same way as the properties, methods are assigned to a monitoring attribute.
The properties for most monitoring objects and attributes in the monitoring architecture are already prede ned and are available in
every SAP system. However, you can also change the settings in accordance with your wishes. Your changes to the properties and
methods are grouped in properties variants, which prevents an accidental reset of your adjustments when the SAP prede ned settings
are updated (for example, during an update).
Structure
The properties are divided into two groups:
· General Properties
This includes the assigned message that contains more detailed information about the monitoring object or attribute. As the
properties contain the class and the number of the message, you can also make your own changes here.
12/20/2019
Setting options for the alerts are also general properties. For a monitoring object, these properties are only valid for the
attributes that belong to this object.
· Properties of the Individual Monitoring Attributes
There are ve different attribute types in the monitoring architecture, each of which have their own special properties. In this
way, you can, for example, de ne the threshold value only for performance attributes. These properties only exist for monitoring
attributes, not for monitoring objects.
See also:
You can edit properties both from the alert monitoring tree and from the Customizing transaction RZ21 (see Changing Properties and
Method Assignments).
General Properties of Monitoring Tree

Elements
De nition
Every monitoring tree element (MTE) has properties that contain more detailed information about the element. The properties are
divided into two groups:
· Properties that depend on the type of the MTE; these are:
· Properties that are independent of the type of the MTE. These are called general properties.
The general properties of an MTE include a message class and message number; these contain a short description of the MTE. The
general properties also contain information about possible alerts. However, as alerts can only be generated for monitoring attributes,
the following properties apply only for the attributes that belong to the object:
· Criticality and severity of the alert that is associated with the MTE
· Maximum number of alerts to be stored for this MTE
· Conditions under which no alert is to be generated
By default, the properties for the different MTEs in an MTE class are identical, however, you can change the properties individually for
single MTEs (see Changing Properties and Maintaining Methods).
Use
The general properties determine, above all, the handling of alerts. If alerts for particular MTE classes or individual MTEs are especially
important for the monitoring of your IT landscape, you can ensure that these alerts are, for example, reported further up the alert
monitoring tree, or that a large number of these alerts is stored in the monitoring segment, by changing the general properties.
12/20/2019
Structure
The general properties are as follows:
Property Description
Message Class and Message Number Message ID that contains a description of the MTE. You can change
this is you have created your own message text
Severity of Alerts to be Triggered Meaning of an alert; if two alerts have the same color, the alert with the
higher severity is displayed further up in the alert monitoring tree
(CCMS only uses values up to 50 here, so that you can ensure that this
alert is displayed further up the alert monitoring tree by entering a
higher severity)
Maximum Number of Alerts Kept Limit of the number of alerts that are to be retained in the monitoring
segment of shared memory
Which alerts should be kept? all: Additional alerts for this MTE are stored as long as there is still free
storage space in the monitoring segment, irrespective of the
maximum number of alerts kept. If there is no more free storage
space, half of the supernumerary alerts (that is, the alerts over the
maximum number) are deleted.
Tip
The maximum number of alerts kept is 10, but there are 50 alerts
for the MTE in the monitoring segment. If the segment is now full,
the monitoring architecture reduces the number of alerts from 50
to 30, as half of the supernumerary 40 alerts are deleted.
the oldest: If the maximum number of alerts keptis reached, no more

alerts are stored for this MTE until alerts have been completed.
the newest: If the maximum number of alerts kept is reached, the

oldest existing alert is deleted for each new alert. We recommend this
setting.
Do not trigger alerts within the rst … Avoids the generation of alerts after the application server is started,
while there are no meaningful values for many MTEs (such as for the
buffer quality)
In the absence of values deactivate after … Number of seconds after which the MTE is assigned the color status
gray with the message "Value is obsolete"; this provides the possibility
of identifying inactive nodes
Also Trigger Heartbeat Alert Option to generate an alert if no values are reported (see Triggering a
Heartbeat Alert if No Values Are Reported)
Caution
The number and selection of alerts that are to be stored have a critical importance for the function of the monitoring architecture:
incorrect settings can cause the monitoring segment in which the alerts are stored to become full. We therefore recommend:
§ You should store the newest alerts. You can use the report RSAL_KEEPALTYPE_MODIFY to change all occurrences of
All alerts should be kept to the newest alerts should be kept. Execute the report once for each affected SAP system and after
every upgrade of the monitoring architecture.
§ You should complete alerts regularly to gain available storage area in the monitoring segment. With a large number of
MTEs, it is useful to de ne conditions under which the system should automatically complete alerts.
§ Observe the Space subtree of the CCMS Selfmonitoring monitor. If there is insufficient free storage space in the
monitoring segment, a corresponding alert is generated there.
12/20/2019

Use
Log attributes (icon ) are monitoring attributes that capture messages in their context. This means that the data collection method
does not just write isolated messages in the Alert Monitor, but also the content of a log or trace.
Features
Log attributes have a number of special features in the display of properties and methods. These are described here. If you want to
display the properties of a log attribute, select the attribute in the alert monitoring tree and choose Properties.
Display "Current Value" like Group Box
If there are multiple messages in the selected log attribute, you can choose which message should be displayed:
Always display only the newest message (Last incoming message)
The message with the severest alert, irrespective of its age (Highest alert)
The message with the severest alert that is not longer than a speci ed time (Maximum value from the last)
Alert Settings Group Box
You can select whether and how the messages for this log attribute should trigger alerts. Every message is assigned a color and a
severity level. You can set as of which color and which level of severity an alert is to be triggered (From value), whether all messages
should trigger the alert that is assigned to them (evaluation of Reported like), or whether no messages should trigger alerts (Never).
Internal Storage of Message Lines Group Box
The messages are stored in an internal message log. You can decide how many messages are stored (Maximum number of lines to be
saved). If you select the radio button As much as possible, the system will store messages as long as there is enough space available in
the monitoring segment of the shared memory.
See Also:
Detail Display for Log Attributes

Use
Performance attributes (symbol ) are monitoring attributes that collect certain reported performance data and calculate the
average.
Features
In the display of the properties and methods, performance attributes have a number of special characteristics that are described here.
To display the properties of a performance attribute, choose the attribute in the alert monitoring tree and choose Properties.
Comparison Value
12/20/2019
In the Comparison Value group box, you de ne how the value of the performance attribute is to be calculated from the reported values.
You have the choice between the last reported value (last reported), the average value of the last minute, last ve minutes, or last
fteen minutes (Smoothing) and the average value of the last full quarter of an hour or hour (Average).
Threshold values
In this group box, you can edit the threshold values with which an alert is triggered if the reported value exceeds or falls below the
appropriate value. Note when doing so that the change applies not only to the concrete monitoring tree element (MTE), but for the
whole MTE class. This is displayed at the top of the screen.
You have the option to assign different threshold values for a Change from GREEN to YELLOW and the Reset from YELLOW to GREEN
(the same also applies for the Change from YELLOW to RED and the Reset from RED to YELLOW). This prevents a constant switching
between the alert levels, if the attribute is wavering around the threshold value, which would generate a new alert every time.
The display of a rule of this type would look as shown in the graphic below. To nd out the alert level, start from any value for the
performance attribute and move upwards until you meet the curve. If the value is climbing from a lower alert level, the lower part of the
curve is valid for determining the alert; if the value is falling from a higher alert level, the upper part of the curve is used.
The unit of the threshold value is determined using the data supplier.
Explanation for an Alert
If an alert is triggered, it is displayed in the Alert Browser. A short explanatory text for the alert is displayed there in the Alert Text
column. Choose the relevant line of an alert and choose F1 to display a more detailed text about the alert. The system displays its short
text and the associated message class and number here. You can use these to adjust the delivered message texts.

12/20/2019
Use
Status attributes (symbol ) are monitoring attributes that report error message texts and alert status.
Features
Status attributes have a number of special characteristics in the display of properties and methods. To display the properties of a
status attribute, choose the attribute in the alert monitoring tree and choose Properties.
When should a message trigger an alert?
Always (at every message): The Alert Monitor triggers a alert with the corresponding message value for every message.
Message value (color) has changed: The Alert Monitor only triggers an alert if the alert color of a reported message changes. For
example, an alert is triggered if a red message follows a yellow message.
The message sent has changed: The Alert Monitor only triggers an alert if the color or severity of a message changes or if a new
message is sent.
Never: The Alert Monitor does not trigger any alerts.
Changing the value for alert generation
You can control the generation of alerts by in uencing the criticality reported with every status message. Note that each setting only
applies to the selected monitoring attribute and not to the associated MTE class.
You have the following options:
Accept value unchanged: Choose this option to use the value reported by the application for a message. The default value for
the message remains unchanged. This is the default option for the Alert Monitor.
Red is transferred as yellow: Choose this option to display all reported red messages as yellow alerts. This means that the Alert
Monitor displays only yellow alerts. No red alert messages are logged.
Yellow is transferred as red: Choose this option to display all reported yellow messages as red alerts. This means that the Alert
Monitor displays only red alerts. All reported yellow messages are logged as red alerts.
Red is transferred as yellow and yellow is transferred as green: Choose this option to reduce the weighting of the reported
messages. The Alert Monitor displays incoming red messages as yellow alerts and incoming yellow messages as green alerts.
Display Types and Views of the Alert Monitor

Purpose
The Alert Monitor provides two system views (Current Status and Open Alerts), with which you can display the status of your
monitored systems. In addition, there are also the display types Alert Browser and Detail Data for displaying more detailed information
about open alerts or selected monitoring tree elements (MTEs).
Current Status
This system view displays the current data for every MTE. When you begin to check the system, you begin with this view:
Caution
Heartbeat alerts are not displayed in this view (see Triggering a Heartbeat Alert if no Values Are Reported).
12/20/2019
Open Alerts
The following image shows the Open Alerts view. This view shows where alerts exist that have not yet been analyzed and set to
complete. The color indicator for alerts is set in accordance with the most serious alert that has not yet been processed. Switch to this
view to see whether problems have occurred since the last time you used the Alert Monitor.
Caution
This view does not necessarily correspond to the current status of the system.
12/20/2019
Alert Browser
A third display type is the Alert Browser, which you start through the Alert Monitor. The Alert Browser displays a list of the open alerts
in a at hierarchy. To do this, select the MTEs for which you want to display the alerts that have not yet been completed. The Alert
Browser tool is therefore well suited to systematically processing all alerts that have not yet been completed.
Technical Views
The Technical Views should be considered separately from the above display types. In technical views, the displayed information is not
current values or alerts for nodes, but rather information about properties and methods of the nodes. You can also display this
information for individual nodes by choosing the Properties pushbutton, however you can see the relevant information for all nodes of a
monitor in the technical views. There are the following technical views:
· Technical View: Info on MTE
· Technical View: Method Allocation
· Technical View: Status Data Collector
· Technical View: Status Autoreaction
· Displaying the Technical View: Threshold Values
· Technical View: Central Performance History
Displaying Detail Data
12/20/2019
You can display the detail data for one or more MTEs from both system views of the Alert Monitor. The display of the detail data shows
you:
· The most serious alert that has not yet been processed (if one exists)
· For performance attributes, the current performance data, the associated alert threshold values and the combined,
smoothed data for the last 30 minutes and 24 hours
· For status and log attributes, the last message
· The general properties of the selected MTEs
Changing Views: Current Status/Open Alerts

Use
The Alert Monitor provides two system views:
· The Current Status view displays the current data reported for every monitoring tree element (MTE). The color indicators
of the alerts and the text of the alert message re ect this data. They display the most severe current problem.
· The Open Alerts view shows where alerts exist that have not yet been analyzed and set to completed. The color indicator of
a monitoring attribute corresponds to the most sever alert for this attribute that you have not yet processed. This view does not
necessarily re ect the current status of the system.
You can use both of these views to obtain a complete overview of the system status: When you check the system, start with the Current
Status view sot hat you see the current status of the system; then change to the Open Alerts view to see whether problems have
occurred since you last used the Alert Monitor.
Procedure
1. 1. Choose CCMS → Control/Monitoring → Alert Monitor, or call transaction RZ20.
2. 2. Expand the monitor set that contains the monitor that you require, and choose Load Monitor.
3. 3. The system displays the monitor in the Current Status view. To change the view, choose Open Alerts. You can see which
view is currently active in the title of the alert monitoring tree.
See also:
Alert Browser: Processing Alerts
Triggering a Heartbeat Alert if No Values Are Reported
Displaying Technical Views of the Alert Monitor

Purpose
The most important tool for processing alerts is the Alert Browser, which you start using the Alert Monitor. The Alert Browser displays
a list of the open alerts in a at hierarchy. Select the monitoring tree elements (MTEs) for which you want to display the incomplete
alerts.
12/20/2019
Process Flow
1. To start the Alert Browser, choose the Open Alerts view in the Alert Monitor. Select the MTEs for which you want to display the
alerts (see also Selecting Nodes in the Alert Monitoring Tree).
2. Now start the Alert Browser, and choose Display Alerts. The Alert Browser displays all alerts for the selected MTEs including all
subordinate subtrees. To display all open alerts for a monitor, you must have selected the root node of the monitoring tree.
3. Analyze an alert Does the problem signi ed by the alert refer to a temporary problem, and has it already been resolved? If not,
what triggered the alert and what can be done to solve the problem?
For the analysis of an alert, you must collect the data for the alert. In the Alert Browser, you can display the detail data collected
by the Alert Monitor.
You can also start the analysis method ( ), that is assigned to the alert and the MTE. With this method, you can check the
current status of the component affected by the alert and collect data about the component.
To obtain a description of the alert, selected the desired alert, and choose F1.
1. When you have solved the problem, or have determine that it was temporary or can be ignored without concern, select the alert,
and choose Complete Alerts. The Alert Monitor stores the alert in the alert database, until you delete the alert during a
reorganization of the alert database (see Reorganizing Completed Alerts).
Displaying Detail Data and Tailoring the

Display
Use
You can display detail data both in the Alert Monitor (in the Current Status and Open Alerts views) and in the Alert Browser.
The detail data display contains the data that was collected in the Alert Monitor for one or more monitoring tree elements (MTEs).
Alternatively, you can start the analysis method assigned to an MTE. With this method, you can collect the data yourself.
The detail data display shows:
· The most serious alert that has not yet been processed (if one exists)
· Alert threshold values, the current performance data and the combined, smoothed data for the last 30 minutes and 24
hours (for performance attributes).
· The messages in the log attribute (for log attributes)
· The last status message (for status attributes)
You can mix data from several MTEs. For example, you can display CPU utilization and the dialog response time together. This is useful
if you want to graphically display the data from MTEs for related subjects.
Procedure
3. 3. Select one or more MTEs in the Alert Monitor or one or more alerts in the Alert Browser (see Selecting Nodes in the Alert
Monitoring Tree).
Note
In the Alert Monitor, select only MTEs of monitoring attributes. These are the end nodes of the monitoring tree in the Alert
Monitor. In the Alert Browser, you can display detail data for every alert.
4. 4. Choose Display Details. The Alert Monitor displays the detail data for the selected MTEs.
5. 5. Choose Current Display Variant. With this dialog box, you can
12/20/2019
· Add elds to the display or delete elds from the display
· Use two or three lines for each entry instead of line printers
· Change the sequence and the width of elds
· Sort the entries in ascending or descending order
See also:
Detailed Display of Log Attributes

Use
Log attributes (symbol ) are monitoring attributes that record messages in their context. This means that the data collection
method does not record isolated messages in the Alert Monitor, but also the contents of a log or trace.
Activities
You can perform the following actions with log attributes:
Display Log Attributes
1. To do this, choose CCMS → Control/Monitoring → Alert Monitor, or call transaction RZ20.
2. Expand the desired monitor set, choose a monitor and choose Load Monitor.
3. To start the detail display, select one or more nodes that contain log attributes and choose Display Details ( ). The system
displays the Log Attributes - Detail Data screen.
Adjust Time Period for Display
The period for the messages displayed in a log attribute is independent of the usual settings in the Alert Monitor. You can adjust the
period by choosing Time Interval. You can display the messages for the last few minutes or for a particular period.
Merge Log Attributes
When you display detail data for multiple log attributes, you can mix the contents of log attributes with each other. This means that
messages of the log attributes are not displayed sorted by attributes, but by message time. This is especially useful if the messages
from multiple log attributes have a mutual connection.
To do this, choose Merge on the Monitoring Attributes: Detail Data screen. To display the various selected attributes in separate tables,
choose Individual Display.
See also:
12/20/2019
Displaying Performance Data Graphically in

the Alert Monitor
Use
You can display the performance data that you have called on the detailed data for monitoring attributes screen graphically. You can
use this data, for example, to compare the individual response times for multiple application servers at a glance and to analyze possible
tendencies within your SAP system.
Each value in the graphical display is expressed as a value between 0 and 1, so that you can compare different values with each other.
For example, you can easily compare the CPU performance with the number of users logged on to an application server, although these
are expressed in different units.
SAP R/3 4.6A provided new functions for displaying the curve. You can use the Fitfunction to test the relationship between different
curves. If you choose this function, the highest value in the curve is assigned the value 1 in the graphical display, and the lowest value is
assigned the value 0. In this way, you can see the relationship between the two curves clearly.
There are two other display options: you can display an extract from the performance data curve, and you can change the scaling of the
display, so that you can see differences in the reported values more clearly.
The new graphical display can also show up "gaps" in your measurement data. If, for example, the system was not active for a time,
there is a gap in the display, to show that no values were recorded during this time.
You can also choose how you want to graphically display the performance data. You can choose between a variety of options (bar chart,
pie chart, or table).
Procedure
1. Choose Administration → CCMS →Control/Monitoring →Alert Monitor, or call transaction RZ20.
2. Expand the monitor set that contains the monitor that you require, and choose Start Monitor.
3. Select the desired performance MTEs (if you are not familiar with the icons used in the alert monitor, display the Legend), and
choose Display Details.
4. Check the indicators for data lines that you want to include in the graphical display. You can combine data from several lines
that belong to different MTEs.
5. Choose Display Performance Values Graphically. The alert monitor displays the selected data.
6. If you want to change the legend or the scale of the graphic, choose Settings →Legend.
Displaying Technical Views of the Alert

Monitor
Use
The system normally displays the values and alert status of monitoring tree elements (MTEs) in the alert monitoring tree. However,
there are also a large number of other general and speci c properties for the MTEs, which you can display for an MTE by choosing
Properties or Display Details ( ) (see Properties of Monitoring Objects and Attributes and Methods).
If you require these properties not only for a few MTEs, but rather for all MTEs of a monitor, the above method is very time-consuming.
The technical views exist for this reason. Each of the technical views displays an aspect of the properties and methods that are
12/20/2019
assigned to the individual MTEs in the alert monitoring tree. There are the following views:
· Displaying the Technical View: Info on MTE
· Displaying the Technical View: Method Allocation
· Displaying the Technical View: Status Data Collector
· Displaying the Technical View: Status Autoreaction
· Displaying the Technical View: Threshold Values
· Displaying the Technical View: Central Performance History
Procedure
To activate the technical views, follow the procedure below:
3. 3. Choose the Views menu and the required view.
Displaying the Technical View: Info on MTE

Use
MTE classes and attribute groups group nodes of the alert monitoring tree by topic and therefore simplify Customizing, as you no
longer need to adjust the properties of all affected monitoring tree elements (MTEs), but rather only of the corresponding MTE class or
attribute group. You can nd out the assigned MTE class and attribute group by selecting an MTE and choosing Properties. This
method is very time-consuming for obtaining an overview of the assigned MTE classes and attribute groups of the MTEs of an entire
monitor. The technical view Info on MTE exists as an alternative for this purpose. This view displays the following information for the
MTEs of the entire monitor:
· MTE class to which the MTE belongs
· Attribute group to which the MTE belongs (for performance, status, and log attributes)
· Short text that is assigned to the MTE class as help (usually activated using the F1 key)
To additionally display the long help text for an MTE, choose the relevant MTE by double clicking it.
Note
· The nodes are always colored green in the technical view Info on MTE; as it contains no alert information.
· If the corresponding general or speci c properties of the MTE are not determined by an MTE class or attribute group, but
rather individually for this MTE, no class or group is displayed in this view.
Procedure
To activate the Info on MTE technical view, follow the procedure below:
3. 3. Choose Views → Info on MTE. The alert tree now no longer displays the alert status and reported values, but information
about the MTEs of the monitor.
12/20/2019
Displaying the Technical View: Method

Allocation
Use
The individual monitoring tree elements (MTEs) of the Alert Monitor are assigned methods. These methods determine the data
collection of the MTEs (data collection methods) and the possible reactions to an alert in the MTE (auto-reaction and analysis
methods). You can nd out the assigned methods by selecting an MTE and choosing Properties. This method is very time-consuming
for obtaining an overview of the assigned methods for the MTEs of an entire monitor. The technical view Method Allocation exists as an
alternative for this purpose. This view displays the method assignments for the MTEs of the entire monitor:
· Assigned data collection method: If the MTE is assigned an active data supplier, the system will display <no method> in the
corresponding column, as the active data suppliers are not de ned in the monitoring architecture
· Assigned auto-reaction method
· Assigned analysis method
Note
· The nodes are always colored green in the technical view Method Allocation; as it contains no alert information.
· Summary nodes or monitoring objects can always be assigned methods; these assignments only take effect for the
subordinate monitoring attributes, which can inherit their method assignment from the superordinate nodes.
· If no analysis or auto-reaction method is assigned to the MTE, <no method> is displayed in the corresponding column
here.
Procedure
12/20/2019
To activate the Central Method Allocation technical view, follow the procedure below:
3. 3. Choose Views → Method Allocation. The alert tree now no longer displays the alert status and reported values, but
information about the methods assigned to the MTEs of the monitor.
Displaying the Technical View: Status Data

Collector
Use
Data suppliers deliver values that are displayed in the Alert Monitor. They each belong to the individual system components and create
monitoring objects that report values to the monitoring architecture. These values are displayed in the monitor sets.
It can be useful to check the status of the data collection methods if problems occur in the monitoring architecture. You can nd out
the most important information about the assigned data collection methods on one hand by choosing Properties, if you choose the
data collection method in the Methods tab page by double clicking it. On the other hand, you can nd out the de nition and runtime
status of the data collection method of an MTE by choosing Display Details ( )
This method is very time-consuming for obtaining an overview of the data collection methods and their status for the MTEs of an entire
monitor. The technical view Status Data Collector exists as an alternative for this purpose.
In this technical view, you can also manually start the data collection method for any MTE to which a data collection method is
assigned. To do this, choose the relevant MTE by double-clicking it. This is useful, for example during test phases or for MTEs for which
you require the current value, even if it is not yet time for the next start of the method.
12/20/2019
Note
Note that when you start a data collection method manually, it runs under your user name and therefore also under your
authorizations. As the method runs under the SAPSYS user when it is started automatically, and this user has only very few
authorizations, you can assume from a successful test with a manual start that the method will also run without problems during
normal operation.
Procedure
To activate the Status Data Collector technical view, proceed as follows:
3. Choose Views → Status Data Collector. The alert tree now no longer displays the alert status and reported values, but
information about the data collection methods of the MTEs of the monitor.
Result
The view displays the following information about the data collection methods that are assigned to the individual MTEs of the monitor:
Assigned data collection method: If the MTE is assigned an active data supplier, the system will display <no method> in the
corresponding column, as the active data suppliers are not de ned in the monitoring architecture
Type of the data collection method; depending on the de nition of the method, the following types are possible:
Type Meaning
[Running in agent] The method is periodically executed in an agent
[Running in Autoabap] The method is executed periodically in the dialog process.
12/20/2019
Type Meaning
[Running in Background] The method is periodically executed in the background process as

a job.
[Kernel function] The method is automatically executed in the C kernel.
[???] The method type is not yet known; this type is only displayed for a
short type after the method is created.
De nition status of the method:
Type Meaning
PRESET The method has just been created; the properties of the method are
still determined by the settings in the data supplier. After a maximum
of ve minutes, the system reads the current settings of the method
from the active properties variant and changes the de nition status.
DBSET WPSET The settings of the active properties variant are already included in the
properties of the method in this status. However, as it is not in the
CHECKED de nition status, you should check whether the method is
released as a data collection method.
CHECKED The method is released and can therefore be executed.
CEN_CHECKED The method is executed in a CCMS agent; as all settings for the
method are set in the agent, do not change these settings manually.
Runtime status of the method:
Type Meaning
Ready The method is ready for the next execution; however, this is not yet
due.
Run required The method is to be executed, however the responsible dispatcher has
not yet started the method.
Running The method is currently running; the color of the corresponding

attribute is yellow.
Error Fatal Error An error occurred during the last run of the method. The difference
between the two statuses is that a method in the status Error is
started again at the next scheduled run, a method in the status Fatal
Error is not. The color of the corresponding attribute is red.
Note
To restart the method, reset the method status. To do this, select
the relevant MTE, choose Display Details ( ), and on the next
screen, choose Edit → Method Status → Reset → Data Collection
Method.
Note
The time speci cation after the runtime status shows the time since which the method has been in this status.
Frequency of the method call in seconds (Cycle):
Note
12/20/2019
The color of the nodes is not passed upward in the alert monitoring tree. Monitoring objects and summary nodes therefore
always have the color Green.
Displaying the Technical View: Status

Autoreaction
Use
In the monitoring architecture, you can react automatically to an alert using auto-reaction methods. These methods are automatically
started in the case of an alert and by default are executed in the system in which the alert occurs. Almost no assignments are made in
the standard SAP system; however, there are several prede ned auto-reaction methods in the monitoring architecture that you can
assign to any MTE classes.
As of SAP Web Application Server 6.10, you can also de ne central auto-reaction methods. The auto-reaction methods are not started
in the system, in which the alert occurs, but rather in the central monitoring system. In this way, it is possible for reactions to events
that occur in monitored components to be performed immediately in a central location.
If problems occur during the execution of auto-reaction methods, it can be useful to check the status of the auto-reaction methods.
You can nd out the de nition and runtime status of an MTE by choosing Display Details ( ). This method is very time-consuming for
obtaining an overview of the auto-reaction methods for the MTEs of an entire monitor. The technical view Status Autoreaction exists as
an alternative for this purpose.
In this technical view, you can also manually start the auto-reaction method for any MTE to which an auto-reaction method is assigned.
To do this, choose the relevant MTE by double-clicking it. This is especially useful during test phases.
Note
Note that when you start an auto-reaction method manually, it runs under your user name and therefore also under your
authorizations. As the method runs under the SAPSYS user when it is started automatically, and this user has only very few
authorizations, you can assume from a successful test with a manual start that the method will also run without problems during
normal operation.
Procedure
To activate the Status Autoreaction technical view, follow the procedure below:
3. Choose Views → Status Autoreaction. The alert tree now no longer displays the alert status and reported values, but
information about the auto-reaction methods of the MTEs of the monitor.
12/20/2019
Result
The view displays the following information for the active monitor about the auto-reaction methods that are assigned to the individual
MTEs:
Assigned auto-reaction method
Type of the auto-reaction method; depending on the de nition of the method, the following types are possible:
Type Meaning
[Central Autoreaction] The method is de ned as a central auto-reaction method.
[Running in Autoabap] The method is executed in the dialog process.
[Running in Background] The method is executed in the background process as a job.
[???] The method type is not yet known; this type is only displayed for a
short type after the method is created.
De nition status of the method:
Type Meaning
PRESET The method has just been created; the properties of the method are
still determined by the settings in the data supplier. After a maximum
of ve minutes, the system reads the current settings of the method
from the active properties variant and the de nition status is changed.
DBSET CEN_SET WPSET The settings of the active properties variant are already included in the
properties of the method in this status. However, as it is not in the
CHECKED de nition status, you should check whether the method is
released as an auto-reaction method.
12/20/2019
Type Meaning
CHECKED The method is released and can therefore be executed as a local auto-
reaction method.
CEN_CHECKED The method is released as a central auto-reaction method.
Runtime status of the method:
Type Meaning
Ready The method is ready for the next execution; however, this is not yet
due.
Run required The method is to be executed, however the responsible dispatcher has
not yet started the method.
Running The method is currently running; the color of the corresponding

attribute is yellow.
Error Fatal Error An error occurred during the last run of the method. The difference
between the two statuses is that a method in the status Error is
started again at the next scheduled run, a method in the status Fatal
Error is not. The color of the corresponding attribute is red.
Note
To restart the method, reset the method status. To do this, select
the relevant MTE, choose Display Details ( ), and on the next
screen, choose Edit → Method Status → Reset → Data Collection
Method.
Note
The time speci cation after the runtime status shows the time since which the method has been in this status.
The color of the nodes is not passed upward in the alert monitoring tree. Monitoring objects and summary nodes therefore always
have the color Green.
Displaying the Technical View: Threshold

Values
Threshold values dictate which reported values generate an alert for the node for performance attributes (see Properties of
Performance Attributes). To display these threshold values, select the corresponding node and choose Properties. This method is very
time-consuming for obtaining an overview of the threshold values for the MTEs of an entire monitor. The technical view Threshold
Values exists as an alternative for this purpose. This view displays the following information for the MTEs of the entire monitor:
· Attribute group to which the MTE belongs
· Threshold values of the MTE for which a yellow and a red alert are generated; also the threshold values at which the alert
level is lowered again.
· Unit of the reported performance values

12/20/2019
· Comparison value that speci es how the value of the performance attribute is calculated from the reported value, such as
the last reported value, the average of the last few minutes (smoothing), or the average of the last full quarter hour/hour
(average).
· Information, about whether an alert is to be generated when the value of the performance attribute falls below the
threshold value or when the value exceeds the threshold value
To additionally display the long help text for an MTE, choose the relevant MTE by double clicking it.
Note
· The nodes are always colored green in the technical view Threshold Values; as it contains no alert information.
· If the properties of the MTE are not speci ed by the attribute group, but are de ned individually for this MTE, the view displays
<TID specific> instead of the attribute group.
Procedure
To activate the Threshold Values technical view, follow the procedure below:
3. 3. Choose Views → Threshold Values. The alert tree now no longer displays the alert status and reported values, but the
threshold values for the MTEs of the monitor.
Displaying the Technical View: Central

Performance History
12/20/2019
Use
The Central Performance History of the monitoring architecture 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.
The system only collects values for the MTE classes that you have selected for this purpose. You do this by assigning MTE classes to
Collection and Reorganization Schemata. These schemata contain information about how long, and in which resolution, performance
values should be collected. To obtain an overview of this type of which data is collected in the Central Performance History, you
required the collection and reorganization schemata that are assigned to the individual nodes.
The view displays the following information:
· Assigned collection and reorganization schema
· Resolution of the collected performance values
· Collection method (see Collecting and Reorganizing Performance Values)
· Time zone of the data collection (if explicitly speci ed)
Procedure
To activate the Central Performance History technical view, follow the procedure below:
3. 3. Choose Views → Collect./Reorg.Schema Assignment, or choose Display Assignments of the Central Performance History (
). The alert tree now no longer displays the alert status and reported values, but the assigned Collection and Performance
Schemata.
Processing Alerts
12/20/2019
Purpose
Alerts are assigned methods using the associated monitoring tree elements (MTEs). A method can be a report, a function module, an
SAP transaction, or a URL that is to executed as a reaction to an alert. You should differentiate between auto-reaction methods that the
system automatically executes as a reaction to an alert (see also Selected Methods of the Alert Monitor, such as an Automatic Alert
Noti cation), and analysis methods that you start manually when analyzing an alert (see Starting Methods).
After you have analyzed an alert and corrected its cause, you no longer need to display the alert in the Alert Monitor: you can complete
the alert. This means that it is deleted from the Alert Monitor and saved to an Alert Database. You can display completed alerts from
the Alert Database. The Alert Database is also monitored using the Alert Monitor: if the size of the database reaches a de ned limit, an
alert is triggered. To limit the size of the database, you can reorganize completed alerts.
Note
By default, an alert represents a problem message. You can, however, activate the generation of "green alerts" for selected nodes,
that is, an alert of this type for an all-clear or for an explicit message that an action was successful (see Working with All-Clears
(Green Alerts)).
See also:
Starting Methods
Use
Monitoring tree elements (MTEs) in the Alert Monitor and alerts in the Alert Browser are assigned methods. You can call these
methods to investigate the status of an alert. For example, you could analyze a component of the SAP system with an analysis method,
integrate additional monitoring functions into the monitoring architecture with data collection methods, and use auto-reaction
methods if you want the system to react automatically to an alert.
Prerequisites
To be able to start all three method types from the monitor display, you must rst activate the maintenance functions. If the
maintenance functions are deactivated, you can only start analysis methods. The reason for this is that the manual start of an analysis
method is part of the everyday work of an administrator, while the manual start of other methods is only necessary more rarely.
Possible scenarios are:
To obtain the current measured value for an attribute immediately, start the associated data collection method manually. This
can be especially useful if the method is only called infrequently (for example, if it is called as a job).
To test an auto-reaction method, start the associated auto-reaction method manually.
Procedures
You can start the methods from the alert monitoring tree, from the Technical Views or the Alert Browser.
Caution
Data collection and auto-reaction methods run in the monitoring architecture either in dialog under the SAPSYS user (which has
only very restricted authorizations) or in the background under the user that created the corresponding job. If you start methods
manually, these methods run in dialog under your user. The method could therefore behave differently to the way it behaves when
12/20/2019
started automatically by the monitoring architecture. Therefore, if you want to, for example, test new methods, do not rely solely on
the results that you obtain from manual starts of the methods.
Starting a Method from the Alert Monitoring Tree
1. Choose CCMS →Control/Monitoring →Alert Monitor, or call transaction RZ20.
2. Choose a monitor from the monitor sets.
3. Choose Extras → Activate Maintenance Functions.
4. Select an MTE in the monitor.
5. Choose Edit → Node (MTE) → Start Method →Start Analysis Methodor Start Data Collection Methodor Start Auto-Reaction
Method. You can also start the analysis method by double clicking the node.
Starting a Method from the Technical Views
2. Choose a monitor from the monitor sets.
4. To start a data collection method manually, choose Views → Status Data Collector. Choose the node for which you want to start
the associated data collection method by double-clicking it, and con rm the following dialog window (see also Displaying the
Technical View: Status Data Collector).
5. To start an auto-reaction method manually, choose Views → Status Data Autoreaction. Choose the node for which you want to
start the associated auto-reaction method by double-clicking it, and con rm the following dialog window (see also Displaying
the Technical View: Status Autoreaction).
Starting a Method from the Alert Browser
2. Start a monitor from the monitor sets.
3. Select an MTE in the monitor display.
4. Choose Open Alerts and then Display Alerts.
5. Select and alert, and choose Edit → Node (MTE) → Start Method → Start Analysis Method orStart Auto-Reaction Method. You
can also start the analysis method by double clicking the node.
See also:
De ning, Releasing, and Transporting Methods
Completing Alerts
Completing Alerts
Use
When you set an alert to completed status, it is removed from the active alerts that are displayed in the Alert Monitor and the Alert
Browser. Set alerts to completed as soon as you have solved the underlying problem or have determined that the alert was triggered by
a temporary problem and can be ignored.
When you set an alert to completed, it is saved in the Alert Database. The alert is retained there until you delete it by reorganizing
completed alerts.
12/20/2019
Procedure
3. Call the Open Alerts view for this monitor.
4. Start the Alert Browser by selecting a node in the monitor and choosing Display Alerts.
5. In the Alert Browser, select the Alerts that you want to set to completed.
6. Choose Complete Alerts.
See Also:
Automatically Complete Alerts
Automatically Complete Alerts

Use
An alert is rst stored in the monitoring segment of the shared memory. When you complete the alert, the alert is deleted from the
monitoring segment and stored in the alert database. In this way, you can ensure that there is always enough place in the monitoring
segment. This is especially true for complex IT landscapes with a large number of monitoring tree elements (MTEs). In the
Spacesubtree of the CCMS Selfmonitoring monitor, you can check whether there is still enough free space in the monitoring segment.
Note
If there is no more space in the monitoring segment for additional alerts, alerts are automatically completed, using several levels:
First, the alerts that are beyond the maximum number of alerts to be stored of the MTE responsible are automatically completed
(see General Properties of Monitoring Tree Elements).
If this is not sufficient, alerts of all MTEs of the monitoring segment are automatically completed, starting with those that are above
the maximum number of alerts to be stored; if necessary, an increasing percentage of alerts within this number is also
automatically completed.
To simplify this task, you can automatically complete alerts. You can select the conditions under which alerts should be automatically
completed:
You can automatically complete alerts which are older than a certain number of days.
You can automatically complete alerts when the free storage space in the monitoring segment falls below the threshold value
for a yellow alert. Beginning with the oldest alerts, the system completes the required number of alerts so that the performance
attribute for the free storage space is assigned the color green again. You can nd the attribute (FreeAlertSlots) in the Space
subtree of the CCMS Selfmonitoring sapurl_limonitor.
Note
You can also ensure that there is enough free storage space in the monitoring segment by reducing the number of reported
alerts for each MTE (see General Properties of Monitoring Tree Elements).
Procedure
To automatically complete alerts, you must set the parameters of the CCMS_Space_Collect method. This method is responsible for
determining the free storage space in the monitoring segment. Follow the procedure below:
1. Choose CCMS → Con guration →Alert Monitor, or call transaction RZ21.
12/20/2019
2. The system displays the Monitoring: Properties and Methods screen. In the Methods group box, select Method De nitions and
choose Display Overview.
3. The system displays a list of method de nitions. Choose the method CCMS_Segment_Space_Collect.
4. The system displays the Monitoring: Methods screen. Choose the Parameters tab page. The parameters have the following
meaning:
Parameter Possible Values Description
CMPL_ALERT_AFTER_DAY <Number> If a value higher than zero is entered here,

alerts that are older than <number> days
are automatically completed.
CMPL_ALERT_IF_QUOTA <space> or X If the value X is entered here, alerts are

completed if the free storage space in the
monitoring segment falls below the
threshold value for a yellow alert.
5. Choose change mode using the Display «Change ( ) pushbutton. Enter the desired parameter values and save your entries.
Result
From now on, alerts are automatically completed in accordance with your settings.
Display Completed Alerts

Display Completed Alerts
Use
In the Alert Browser, you can display completed alerts. Completed alerts are alerts that have already been removed from the Alert
Browser and stored in the alert database.
Procedure
3. Call the Open Alerts view for this monitor.
4. Start the Alert Browser by choosing Display Alerts and choose Show alert history. Completed alerts are added to the Alert
Browser.
See Also:
Complete Alerts
Reorganizing Completed Alerts

Reorganizing Completed Alerts
Use
12/20/2019
When you complete an alert, the Alert Monitor saves it in the alert database. You can call up completed alerts by showing the alert
history.
To avoid the completed alerts occupying too much space in the database, the Alert Monitor monitors the occupied space. If threshold
values are exceeded, the Alert Monitor triggers an alert. The relevant object is called AlertsInDB and is in the SAP CCMS Technical
Expert Monitors monitor set, in the CCMS Selfmonitoring monitor.
Procedure
You can reorganize the completed alerts using the analysis method for AlertsInDB. The method deletes older alerts that match your
speci cations and reduced the space occupied in the database. To do this, proceed as follows:
2. Expand the SAP CCMS Technical Expert Monitors monitor set, place the cursor on the CCMS Selfmonitoring monitor, and
choose Start Monitor.
3. Expand the alert monitoring tree. You will nd the monitoring object for which you are looking under CCMS_Selfmonitoring →
Runtime → AlertsInDB. Select the object and choose Start Analysis Method.
4. Specify the date and time from which completed alerts are to be deleted.
See Also:
Complete Alerts
Resetting MTEs and Alerts

Resetting MTEs and Alerts
Use
By resetting a monitoring tree element, you delete open alerts and data collected for the MTE. You can also reset multiple selected
MTEs, or also all MTEs in a particular hierarchy in the monitoring tree. Resetting an MTE deletes alerts and performance data.
Resetting an MTE is intended solely as an emergency measure: Only reset an MTE if it is clear that the collected data and alerts for the
MTE are incorrect and retention it therefore pointless.
Prerequisites
To be able to reset MTEs and alerts, you must rst activate the maintenance functions.
Procedure
1. Choose CCMS → Control/Monitoring → Alert Monitor in the SAP Easy Access menu, or call transaction RZ20.
3. Choose Extras → Activate Maintenance Function.
4. Select the MTEs that you want to reset and choose Edit → Node (MTE) → Reset.
After you have con rmed the Alert Monitor warning, the MTEs are reset to their status at the time of the system start or their insertion
into the Alert Monitor. The Alert Monitor continues to collect data and trigger alerts for the MTEs.
Customizing the Alert Monitor

Use
12/20/2019
You can set the Alert Monitor in such a way that it triggers alerts in a way that meets your operating requirements. You can also de ne
and modify methods, their assignments, and con guration.
You can change the following properties for monitoring tree elements (MTEs):
General properties of the MTE classes
Attribute groups (Properties of the performance, status, and log attributes)
Elements of individual MTEs
The Customizing in the Alert Monitor has been designed to be simple. You can access it directly from the MTE, and you can, for
example, de ne the threshold values for MTE classes or individual MTEs, for which an alert is generated, if a reported value falls below
these values.
If you make changes to the properties of MTEs in the Alert Monitor, these are permanently stored in the database. Even if a data
collection method attempts to reset the changes to the original values, your changes are retained and are therefore active in the Alert
Monitor.
The general settings in Customizing apply for all monitoring tree elements. However, you can only make type-speci c settings for
monitoring attributes (more information: Properties of Monitoring Objects and Attributes).
Grouping several monitoring attributes saves you administration duties. To avoid having to maintain the same customizing settings for
many monitoring attributes and then save them in the database, the monitoring attributes are assigned to attribute groups. You then
only have to maintain the attribute group. All of the monitoring attributes assigned to this group then automatically receive the new or
changed settings (more information: MTE Classes and Attribute Groups.
Note
As of SAP NetWeaver 7.0 EhP2, the Consistency Check of the CCMS Monitoring Infrastructure is available to you. The associated
transactions RZ50, RZ521, and RZ52 provide a variety of functions to check the con guration and runtime of the CCMS monitoring
infrastructure, to display errors, and to correct these automatically. The checks are called from the central monitoring system
(CEN) and include both the CEN itself and the monitored systems.
Properties Variants
You can assign all of these changes to properties variants. Some or all of the Customizing settings are saved in properties variants of
this type. By creating multiple properties variants, you can have different strategies for administering your IT landscape.
For example, to use different alert thresholds for the response time in the test and production systems, you can de ne separate
properties values for these settings. One Alert Monitor in the production system could run with the properties variant for the response
time in the production system and another with the properties variant for the test system.
See also:
Editing Monitors and Monitor Sets
Changing Properties and Method

Assignments
Use
Monitoring objects and attributes are assigned various properties and methods. There are default settings in the standard SAP System
(which is delivered with the properties variant SAP_DEFAULT) for most nodes for properties and methods, meaning that you can
12/20/2019
already work with these settings.
Note
Auto-reactions are an example. There are very few assignments of these in the standard SAP System. You can make your own
assignments of these (see also: Selected Methods of the Alert Monitor).
If the standard settings do not meet your requirements, you can change the properties and method assignments at any time. You can
make the changes both in the Alert Monitor and in the Customizing transaction RZ21. You can either make changes for the individual
node itself or for the MTE class or attribute group, to which the node belongs (we recommend the latter).
Features
The following cases occur most often in practice:
Desired Change Procedure
Change the General Properties of the node or of the MTE class ad

· the descriptive text for the node
described in Changing the Properties in the Alert Monitoring Tree and
· Severity and maximum number of alerts for the node in Changing Properties in the Customizing Transaction RZ21
Trigger an alert if no value is reported for the node (heartbeat alert) Change the general properties of the node or of the MTE class as
described in Triggering a Heartbeat Alert if no Values Are Reported
Frequency of the data collection method of the node Change the general properties of the node or of the MTE class as
described in Changing the Frequency of the Method Execution
Change the Speci c Properties of the node or of the MTE class ad

· Threshold value of the node (performance attribute)
described in Changing the Properties in the Alert Monitoring Tree and
· Conditions for messages for which alerts are to be in Changing Properties in the Customizing Transaction RZ21
triggered (status and log attributes)
Assigning an auto-reaction method (especially Automatic Alert Change the method assignment of the node or of the MTE class as
Noti cation) described in Assigning Methods to MTE Classes or Individual MTEs
Changing Properties in the Alert Monitoring

Tree
Use
You can change the properties (such as threshold values) assigned to monitoring objects directly in the Alert Monitor. The properties of
a node can come from two sources in this situation:
· The properties come from the assigned MTE class or the attribute group of the MTE. MTE classes and attribute groups
group MTEs in the same way, where MTE classes contain the general properties of the associated MTEs, while attributes
contain the speci c properties of performance attributes, log attributes, or status attributes.
· The properties are assigned to the speci c node itself.
In most cases, it is useful to change the properties of all of the MTEs in an MTE class or an attribute group (such as the dialog response
times for all application servers) at the same time. Therefore, the properties of an MTE are also determined, by default, by its
associated MTE class/attribute group.
12/20/2019
Properties are grouped in properties variants. If you have created your own properties variant, you can specify when changing a
property, the properties variant for which this change applies.
Note
If you want to obtain an overview of the speci c properties of the performance attributes of a monitor, display the threshold values
technical view .
Procedure
2. 2. Choose a monitor from the monitor sets.
3. 3. Select one or more nodes in the Alert Monitor and choose Properties.
4. 4. If you have selected multiple nodes, you can switch between the properties of the selected MTEs using the Previous
select.Obj. ( ) and Next select. Obj. ( ) pushbuttons.
Note
· If the general properties come from an MTE class the system displays the message Use the properties of the MTE class
assigned in the General tab page.
· If the speci c properties are taken from an attribute group, the name of the attribute group is displayed at the top of
the relevant tab page (performance attribute, log attribute, or status attribute)
5. 5. Choose change mode with the Display «Change ( ) pushbutton.
6. 6. If you want to change the speci cation for whether your changes apply only to this MTE or to the entire MTE class or
attribute group, choose Edit → Properties → Use for MTE Class/Group or Edit → Properties → Use Only for MTE.
7. 7. Make the required changes.
8. 8. Save your changes. Only if you have created your own properties variant does a screen appear in which you can choose the
variant in which the changes are made. By default, the active variant is preselected.
Note
The variants in which you have made a change are proposed as the default setting when you next change properties. This
applies until you leave the Alert Monitor.
See also:
Changing Properties in Customizing Transaction RZ21
Changing Properties in Customizing

Transaction RZ21
Use
You can change the properties (such as threshold values) assigned to monitoring objects in the Customizing transaction for the Alert
Monitor (transaction RZ21). The properties of a node can come from two sources in this situation:
· The properties come from the assigned MTE class or the attribute group of the MTE. MTE classes and attribute groups
group MTEs in the same way, where MTE classes contain the general properties of the associated MTEs, while attributes
contain the speci c properties of performance attributes, log attributes, or status attributes.
12/20/2019
· The properties are assigned to the speci c node itself.
In most cases, it is useful to change the properties of all of the MTEs in an MTE class or an attribute group (such as the dialog response
times for all application servers) at the same time.
Properties are grouped in properties variants. There is a variant for every property (whether it is an MTE class, attribute group, or a
speci c MTE), to which the property belongs.
Procedure
1. 1. Choose CCMS → Con guration → Alert Monitor, or call transaction RZ21.
2. 2. From the Monitoring: Properties and Methods screen, you can display an overview of the properties assigned to the MTE
classes and attribute groups.
3. 3. You can choose your desired functions as follows:
Radio Button Function
Properties Assigned to MTE Classes Change properties of an MTE class (general properties)
Properties Assigned to Customizing Groups Change properties for an attribute group (special properties for
performance, status, or log attributes)
MTE-Speci c Properties Change properties for an individual MTE (four tables with general
properties and special properties for performance, status, or log
attributes)
4. 4. Choose Display Overview.
5. 5. In the overview, select the entry that you want to change and choose Edit Data.
6. 6. Choose change mode with the Display «Change pushbutton ( ), and make the required changes.
7. 7. Save your changes.
See also:
Changing Properties in the Alert Monitoring Tree
Triggering a Heartbeat Alert if No Values Are

Reported
Use
By default, if no value is reported, the associated monitoring attribute is set to inactive, and assigned the message
Value is obsolete. This means that, by default, failure to report a value does not lead to an alert.
This setting is often not sensible, especially for components for which values are reported to the Monitoring Architecture by active data
suppliers. This means that if a problem occurs in this component that is so serious that the active data supplier no longer supplies
values, it can also no longer report an alert - values would simply not be reported, and the associated component would eventually be
set to inactive.
You can therefore de ne in the general properties of a monitoring attribute, that a heartbeat alert is additionally triggered if the
reporting of values fails for the monitoring attribute.
12/20/2019
Note
A heartbeat alert is triggered because no value has been reported, and not because the currently reported value has exceeded a
threshold value. Heartbeat alerts are therefore not displayed in the Current Status view, but only in the Open Alerts view and in the
Alert-Browser (see Display Types and Views of the Alert Monitor).
Procedure
3. 3. Select the desired monitoring attribute and choose Properties.
4. 4. The Monitoring: Properties and Methods screen appears. Choose the General tab page and activate the Also trigger
heartbeat alert indicator in the If No Values Are Reported group box.
5. 5. If necessary, you can also change the period after which the heartbeat alert is triggered if no values are reported in the
input eld "Value obsolete" and set to inactive.
6. 6. Save your changes. Only if you have created your own properties variant, does a screen appear in which you can choose the
Result
If no values are reported any more for the desired monitoring attribute (for example, if the associated data supplier is no longer
functioning), a heartbeat alert is generated and is displayed in the Open Alerts view and in the Alert Browser. The heartbeat alert is
always a red alert and has the following text: Heartbeat Alert: value older than <number> seconds.
Exactly one alert is triggered when the con gured time period is exceeded. The measurement is restarted after a new value is reported.
This ensures that only one alert occurs for each time the threshold value is exceeded, and that an alert is generated each time that the
threshold value is exceeded.
Note
Note that other properties of the monitoring attribute must not prevent the generation of a heartbeat alert:
§ For a status attribute, in the When Should a Message Trigger an Alert? group box, the Never checkbox must not be
activated.
§ For a log attribute, in the group box Alert Settings, the checkbox Never must not be selected. If you have activated, in
the Display Current Value as group box, the checkbox highest value of the last, this period should correspond to the setting
for Value Obsolete and Set Inactive.
Example
Using the heartbeat alert for a log attribute (Workload Collector Monitor)
12/20/2019
Scenario: The Collector Is No Longer Running
Without activation of a heartbeat alert, no alert is generated:
With the activation of a heartbeat alert, an alert is generated, and displayed in the Open Alerts view:
Changing the Frequency of Method Execution

Use
MTE classes are assigned to data suppliers that ensure that the relevant values of the monitoring attributes are reported in the
monitoring architecture. These data suppliers are divided into two groups:
Type of Data Supplier Description
Active The data supplier automatically reports values that exceed threshold
values for the monitored monitoring attributes to the monitoring
architecture.
Passive The monitoring architecture regularly queries the data supplier and
reports when threshold values are exceeded in the Alert Monitor.
Passive data suppliers are called data collection methods. You can
change the frequency of the queries.
12/20/2019
Note
To obtain a quick overview of the frequency of the method execution for the nodes of a monitor, use the Technical View: Status Data
Collector.
Procedure
To change the frequency of the method execution for an MTE class, follow the procedure below:
2. Start a monitor from the monitor sets.
3. Select a node in the Alert Monitor and choose Properties.
4. Switch to change mode by choosing Display « Change ( ) and correct the value in the input eld Start the data collection
method every on the Methods tab page.
5. Save your changes. Only if you have created your own properties variant, does a screen appear in which you can choose the
Note
The maximum frequency of the data collection methods depends on whether the underlying program is an ABAP program
or a C program. For ABAP programs, the maximum frequency is ve minutes (you must therefore enter at least 300 seconds
in the input eld Start the data collection method every). For C programs, on the other hand, the maximum frequency is one
minute (you must therefore enter at least 60 seconds in the input eld Start the data collection method every).
See also:
Starting Methods
De ning, Releasing, and Transporting

Methods
Use
Before you can use a new method, you must de ne it and release it in the Alert Monitor. You can then Assign the Method to an MTE.
You can also transport method de nitions to other SAP systems.
Note
The methods created by SAP already exist in all systems with the same SAP release. This means that you only need to transport
your own method de nitions.
Procedure
1. Choose CCMS →Con guration →Alert Monitor, or call transaction RZ21.
2. The Monitoring: Properties and Methods screen appears. Choose Methods → Create New Method.
3. The Monitoring: Methods screen appears. Enter the name and description of the method.
4. Choose the Executiontab page and select the desired radio button in the To Be Executedgroup box. If, for example, you want to
execute transaction ST04 as a method, choose the Transactionradio button and enter CallST04 in the eld.
5. In the Execute Method On group box, determine the server on which the method is to be executed.
12/20/2019
6. If you want to run a function module as a method, you can specify the method parameters on the Parameters tab page.
7. Choose the Control tab page to specify the task type in which the method is to be executed. The method can automatically be
executed in a dialog process or as a job, or you can specify that the method is to be manually executed.
Note
We recommend that you run long-running methods as background jobs. If you choose this option, the SAP System assigns
the method to available background processes. You do not need to schedule the background job manually; however, you can
use transaction SM37 to check its status.
8. You must release the method that you have de ned so that it can be used in the monitoring architecture. To do this, choose the
Release tab page. Specify whether your method is to be used as a data collection, auto-reaction, or analysis method, and
choose Enter.
9. After you have saved your method de nition, you can transport it to another system by choosing Transport.
See also:
Starting Methods
Assigning Methods to MTE Classes or

Individual MTEs
Use
You can assignmethods to MTE classes for data collection, analysis, and auto-reactions. The assignment is initially made in the coding
of thedata supplier itself. If you have also created your own auto-reaction or analysis methods (seeDe ning, Releasing, and
Transporting Methods), you can assign these methods to MTE classes.
You cannot change the assignment of data collection methods, as this would affect the correct execution of the data supplier. Even if
you are creating your own data supplier, the assignment of the data collection methods must be performed using the data supplier and
not by making changes in the Alert Monitor.
Note
As of SAP R/3 4.6A, you can also assignmonitoring properties variants to MTE classes. This has the advantage that you can execute
different methods in different properties variants, increasing your exibility when monitoring your system.
You can perform the assignment both directly in the alert monitoring tree using transaction RZ20 and in the Customizing transaction
for the Alert Monitor (RZ21).
Assignment of the Method in the Alert Monitoring Tree

1. Start the Alert Monitor using transaction RZ20 or choose CCMS →Control/Monitoring →Alert Monitor.
2. Start the desired monitor from the list by double-clicking it.
3. Select the desired node and choose Properties.
4. The Monitoring: Properties and Methods screen appears. The rest of the procedure depends on whether you want to assign the
analysis method only to this node or to the entire MTE class.
Assign a Method to the Selected MTE Class
In most cases, it is useful to assign a method to the entire MTE class.
12/20/2019
1. Choose the name of the MTE class in the header data of the screen by double-clicking it, and then choose the change mode
with the Display «Change ( ) button.
2. In the Auto-Reaction Method orAnalysis Method group box, choose Method Nameand, in the associated eld, enter the name of
the desired method de nition.
3. The method assignment applies for the properties variant displayed in the For Variant eld. If you want to change the
assignment for a different variant, choose Edit →Assignment in other →To variant. You can now specify the variant in the For
variant eld at the top of the screen.
4. Save your entries.
Assign Method to Only this MTE
Only in rare cases is it useful to assign a method to a single MTE.
1. Choose the Methods tab page and then choose the Method Assignment button.
2. The Monitoring: Methods screen appears. Choose change mode with the Display «Change ( ) pushbutton, and choose the
Auto-Reactionor Analysis tab page.
3. In the Method Assignmentgroup box, choose Method Nameand, in the associated eld, enter the name of the desired method
de nition.
Note
The method assignment applies to the active properties variant. To nd out what the active properties variant is, choose the
Additional Info tab page; the active variant is displayed in the eld Effectively-assigned method for active variant.
Assignment of the Method in Transaction RZ21

Choose CCMS →Con guration →Alert Monitor, or call transaction RZ21.
If you want to assign the method to an MTE class, select Methods Assigned to MTE Classes in the Methods group box, and then choose
Display Overview.
If you want to assign the method to an individual MTE, select Methods Assigned to Speci c MTEs in the Methods group box, and then
choose Display Overview.
The system displays the Monitoring: Properties and Methods screen. Select the desired MTE or MTE class by double clicking it. When
doing so, note the Values for Variant column. You can change the method assignment for any properties variant, not just for the
currently active variant.
The Monitoring: Methods screen appears. Choose change mode with the Display «Change ( ) button. In the Auto-Reaction Method
group box, choose Method Name and, in the associated eld, enter the name of the desired method de nition.
Save your entries.
Note
You do not need to assign a method to every MTE class in the monitoring architecture. If you have not speci ed a method for an
MTE class, the system uses, by default, the method assigned to the superordinate MTE.
Editing Monitors and Monitor Sets

Purpose
12/20/2019
Amonitor is a set of monitoring tree elements (MTEs) that are arranged in a hierarchical structure (theAlert Monitoring Tree). These
monitors are combined in monitor sets.
You can create, copy, edit, and delete both monitors and monitor sets, and transport them into other systems. All of these processes
are deliberately kept simple, so that the creation of a monitor or a monitor set is not only useful for setting up your own, specialized
work center, but also as the central control position for concrete problems.
Note
You cannot change the default monitor sets delivered by SAP (symbol ) or any of the monitors contained in these monitor sets.
To be able to edit default monitor sets (for example, as a template for your own monitors), you must rst copy it into your own
monitor set.
When creating monitors, you can also userule-based monitoring tree elements (rule MTEs). The nodes that meet the selection criteria
de ned in the rule are then included in the monitor. The rules are regularly reinterpreted, so that your own monitor automatically
corresponds to the current system landscape.
See also:
Transporting Monitor Sets and Monitor De nitions
Copying, Renaming, and Deleting Monitors

Use
Monitor sets simplify system administration, as they combinemonitors. Every system already contains the standard monitor sets
delivered by SAP. These sets can only be changed by SAP. You can also create, edit, copy, and delete your own monitor sets. To be able
to edit standard monitor sets, you must rst copy them to your own monitor sets.
With your own monitor sets, you can use the attributes of the set to determine who may edit the set and whether the set is to be visible
to all users. You can alsotransport your own monitor sets and monitor de nitions.
Prerequisites
To be able to edit a monitor set or a monitor de nition, you must rst activate the maintenance functions.
Procedure
To call the individual functions in the table, choose CCMS → Control/Monitoring → Alert Monitor, or call transaction RZ20. Choose
Extras → Activate Maintenance Functions.
Function Menu Path
Create Monitor Set Choose Monitor (set) → Create( ); choose Create Monitor Set;
de ne the name and the attributes of the set on the Create Monitor
Setscreen.
Change Monitor Set Select the desired monitor set; choose Monitor (set) → Change ( );
on the Edit Attributes of a Monitor Setscreen, change the desired
12/20/2019
attributes.
Copy Monitor Set Select the desired monitor set; choose Monitor (set) → Copy( ); on
the Copy Monitor Setscreen, enter the name of the copy of the set.
Delete Monitor Set Select the desired monitor set; choose Monitor (set) → Delete ( );
con rm the command.
Transporting Monitor Sets and Monitor

De nitions
Use
You can transport monitor sets to other systems in your transport landscape. This is only necessary for the monitor sets that you
create yourself, as the monitor sets provided by SAP are already available in all SAP systems.
If you want to use the de nitions of individual monitors in other SAP systems, we recommend that you export them as an XML le and
then import them. To do this, you must store the monitor de nition in a le in XML format in the source system; this is then imported
into the target system. This exchange is faster, as no SAP transports must be created. You can also distribute existing monitor
de nitions quickly over the Internet or a le server in XML format.
Prerequisites
To transport a monitor set or a monitor de nition, you must rst activate the maintenance functions.
Procedure
Transport a Monitor Set
The transport of monitor sets uses the SAP transport mechanism.
1. Choose CCMS → Control/Monitoring → Alert Monitor, or call transaction RZ20. The CCMS Monitor Sets screen appears.
3. Choose the monitor set that you want to transport, and choose Transport Monitor Set ( ).
4. Enter a Workbench request with the desired target system.
Transport a Monitor De nition
The transport of a monitor de nition uses the export and import of the de nition in XML format.
1. Choose CCMS → Control/Monitoring → Alert Monitor, or call transaction RZ20. The CCMS Monitor Sets screen appears.
3. Choose the monitor for which you want to export the de nition and then choose Monitor → Display Monitor De nition.
4. The system displays the Display Monitor De nition screen. Choose Monitor De nition → Export. Enter a le name and path to
which you have access from the target system.
Switch to the target system, and choose CCMS → Control/Monitoring → Alert Monitor, or call transaction RZ20. The CCMS Monitor
Sets screen appears.
2. Create a new monitor. To do this, select the desired monitor set and choose Create ( ).
3. Choose Monitor De nition → Import and specify the le name and path entered above.
12/20/2019
Caution
If the monitor de nition already exists, this is overwritten by the import of a de nition.
More information:
Copying, Renaming, and Deleting Monitors

Use
You can create your ownmonitors that contain exactly the information that you require for your daily system administration work. You
can edit, copy, and delete these monitors as you require. You can also save and reuse all of your own monitors.
Prerequisites
To be able to change a monitor, you must rst activate the maintenance functions.
Procedures
Deleting a Monitor
1. Choose CCMS → Control/Monitoring →Alert Monitor, or call transaction RZ20. The CCMS Monitor Sets screen appears.
2. Choose Extras →Activate Maintenance Functions.
3. Expand the monitor set that contains the monitor that you want to delete. Select the monitor and choose Monitor (set) →Delete
( ). Con rm the command.
Renaming a Monitor
1. Choose CCMS →Control/Monitoring →Alert Monitor, or call transaction RZ20. The CCMS monitor sets appear.
3. Expand the monitor set that contains the monitor, and select the desired monitor by double-clicking it.
4. Choose Monitoring → Change Name, and enter the desired name. Con rm the name change by choosing the (Copy) button.
Copying a Monitor
1. Choose CCMS →Control/Monitoring →Alert Monitor, or call transaction RZ20. The CCMS monitor sets screen appears.
3. Expand the monitor set that contains the monitor that you want to copy. Select the monitor and choose Monitor (set) →Copy (
).
4. The Copy Monitor screen appears. Enter the name of the monitor set to which the monitor is to be copied and a name for the
copy.
See also:
12/20/2019

Use
You can quickly and easily create your own monitors that meet your own speci c requirements. If, for example, you want to monitor the
relationship between your CPUs, operating system paging, and the dialog response time of your SAP systems, you can create an alert
monitor that contains only these monitoring tree elements (MTEs). You can decide whether this monitor covers one or more systems.
To be able to create a monitor, rst create a tree structure. You have the following options for the individual nodes:
Static MTE Selection
You can explicitly select MTEs for your monitor. Only the selected MTEs are added to the monitor, and the selection of the MTEs
is not updated.
Rule-Based MTE Selection
You can also use rule-based MTE selection (dynamic selection) to create your monitor. In this case, the alert monitor includes all
MTEs that ful ll a certain rule in your monitor. If the MTEs that meet this rule change, the system automatically updates your
monitor. In this way, your monitor is automatically updated if a new system is added to the alert monitor.
Note
You can combine both static and rule-based MTE selection in the same monitor.
Virtual MTEs
You can de ne virtual MTEs to structure your monitor. Virtual nodes are used as titles or labels in the alert monitor. They have
no function other than to group monitoring tree elements visually. For example, you can create virtual MTEs as titles for
different groups of real MTEs in your monitor.
Prerequisites
To be able to create or change a monitor, you must rst activate the maintenance functions.
Procedure
3. Choose one of the functions from the table:
Function Menu Path
Create monitor Choose the monitor set in which you want to create the monitor;
ensure that it is a monitor set that you can modify ( ); choose
Monitor (set) → Create ( ).
Change monitor Expand the monitor set and choose the monitor that you want to
change. Choose Monitor (set) → Change ( ).
You can also change a monitor that has already been started by
choosing Monitor → Change ( ).
4. The alert monitor displays the complete monitoring tree. The system displays the name of the monitor in the top line of the tree.
You can now either add MTEs to your monitor or display the properties of existing MTEs. To do this, choose one of the functions
from the table:
12/20/2019
Function Procedure
Insert static MTE selection Select the desired MTEs from the list of Selectable MTEs . Only
the selected MTEs will be visible in the completed monitor. The
system displays the list at every point in the monitoring tree where
you can insert statically created MTEs.
Insert rule-based MTE selection Choose the node under which you want to insert a rule-based
node; choose Edit → Create Node ( ) and, on the Create Node
screen, choose the Rule Node radio button (see Rule Nodes: Rule
Description and Use).
Insert a virtual MTE Choose the node under which you want to insert a virtual node;
choose Edit → Create Node ( ) and, on the Create Node screen,
choose the Virtual Node radio button.Enter a name for the node.
Change node Select the relevant node; choose Edit → Change Node ( ). You
can change different properties, depending on the type of the
node.
Display node Select the relevant node; choose Edit → Display Node ( ). The
system displays different properties, depending on the type of the
node.
Delete node Select the relevant node; choose Edit → Delete Node ( ). The
node is deleted, along with its subnodes.
Note
The following rules apply to the sequence of nodes in the monitoring tree:
12/20/2019
The root node (top node) of a monitor is always a virtual node. Its name is the name of the monitor.
You can create as many layers of virtual MTEs as you wish. A virtual node can only be placed under a rule node or
another virtual node in the tree hierarchy.
A rule node can only be placed under a virtual node or another rule node in the tree hierarchy.
A static node can only be placed under a virtual node.
5. Save your monitor by choosing Monitor De nition → Save or Generate Monitor ( ). If you are creating a new monitor, the
system prompts you to enter a name for your monitor.
Example
The following sections contain examples of monitor de nitions:
De ning Monitors with the DEFINE_R3_SYSTEMS/GET_MTE_BY_CLASS Rules
De ning Monitors with the GET_MTE_BY_CLASS_AND_OPTIONS Rule
De ning Monitors with the GET_MTE_BY_CLASS_AS_VIRTUAL Rule
Rule Node: Rule Description and Use

De nition
A rule node or rule monitoring tree element speci es a rule that de nes which nodes are to be included in a monitor. The monitoring
architecture interprets the rule and includes in the monitor the monitoring tree elements (MTEs) that ful ll the selection criteria in the
rule. The rules are regularly reinterpreted, so that your own monitor automatically corresponds to the current system landscape. A
monitor de ned with rules will, for example, automatically include a newly started SAP application server. This means that a monitor
that consists of rule MTEs has the following properties:
The monitor automatically contains various MTEs
The monitor retains an up-to-date status if you make changes to your system landscape
Rules allow the dynamic selection of MTEs using selection criteria. On the other hand, with static selection, you explicitly select
individual MTEs. These are not updated if you make changes to the system landscapes.
Use
When creating a rule MTE, you select a prede ned rule for selecting MTEs for your new monitor. The alert monitor interprets this rule
and selects the MTEs that ful ll the speci ed selection criteria.
The following rules are available:
CCMS_DEFINE_R3_SYSTEMS
This rule creates virtual MTEs for systems that have been added to the monitor. Use this rule to set up rule-based monitoring of
one or more systems. Rule MTEs that you add under this MTE are created for every selected system. You can add monitoring
functions by creating virtual and rule MTEs under this MTE.
The parameter R3Systemis the name of the system that is to be monitored in the relevant monitor. Additional selection options
are: <ALL> (all available systems), <CURRENT> (system of the alert monitor) and all system groups that you have de ned in
your system landscape.
CCMS_GET_MTE_BY_CLASS
12/20/2019
This rule adds MTE classes as real nodes in the monitor. Since all monitoring objects and monitoring attributes are assigned
MTE classes, you can use this rule to monitor certain types of monitoring objects and monitoring attributes. For example, the
monitoring attribute ResponseTimeis assigned to the MTE class R3DialogResponseTime, and AbortedJobs is assigned to the
MTE class R3BPServerSpecAbortedJobs.
Since all copies of a particular MTE belong to the same MTE class, even beyond system boundaries, you can use the rule to
select monitoring objects in all SAP instances and systems.
Caution
All subordinate MTEs are also added with the MTE class (for example, with the MTE class CPU, the subordinate MTEs
CPU_Utilization and 5minLoadAverage are also added, although these MTEs are assigned to other MTE classes).
Note
You can use the input help to display the available MTE classes. Since the help does not show where an MTE class is
displayed in the monitoring tree, it can be difficult to nd the desired MTE class. To nd the required MTE class, open a
standard monitor to the MTE that you want to add into the monitor. Then display the MTE class of the MTE by choosing
Properties.
CCMS_GET_MTE_BY_CLASS_AS_VIRTUAL and CCMS_GET_MTE_BY_CLASS_UNDER_CLASS
Use these two rules together. In this way, you receive the same results as you would with the rule CCMS_GET_MTE_BY_CLASS;
however, the information that you have requested is displayed in a clearly structured format.
If you choose the rule CCMS_GET_MTE_BY_CLASS_AS_VIRTUAL, use the parameter MTEClass to include the MTE class as a
virtual node in the tree. Then choose the rule CCMS_GET_MTE_BY_CLASS_UNDER_CLASS. Specify the MTE classes in the
parameter ChildMTEClass that you want to monitor as real nodes in your monitor.
The rule adopts the parameters MTEClass and R3System from the higher-level rule
(CCMS_GET_MTE_BY_CLASS_AS_VIRTUAL).
CCMS_GET_MTE_BY_CLASS_AND_OPTIONS
We recommend that you use this rule as an alternative to the rules CCMS_GET_MTE_BY_CLASS and
CCMS_GET_MTE_BY_CLASS_AS_VIRTUAL described above, since the performance has been signi cantly improved, in
particular in comparison to the second rule.
You can also use the wildcard characters question mark (?) and asterisk (*) when specifying the MTE class and use the Options
parameter to specify details about the desired MTE classes.
In detail:
To use the rule as an alternative to CCMS_GET_MTE_BY_CLASS_AS_VIRTUAL, specify under MTEClass the MTE class
that you want to include in the tree as a virtual node. The parameter 2ndMTEClass is reserved for later use; do not enter
any values here. Enter the value VirtualMTE for the Options parameter. The rest of the use is identical to the rule
CCMS_GET_MTE_BY_CLASS_AS_VIRTUAL (see above).
To use the rule as an alternative to CCMS_GET_MTE_BY_CLASS, enter the desired MTE class in the parameter
MTEClass.
Many MTE classes always come from the segment of an application server (for example, all classes with the pre x R3) or
of an agent(such as all classes in the Operating System area). If you want to know, when creating a monitor de nition,
whether the MTE class comes from the monitoring segment of an application server or from a CCMS agent (but only
then), you can additionally specify the value OnlyAgent or NoAgent in the Options parameter. This will also improve the
performance of the monitor.
You can restrict the selection of MTE classes to monitoring contexts. Use the option OnlyContext to do this. If this option
is set, only the monitoring contexts of the speci ed MTE class (parameter MTEClass) are selected.
Tip
Set MTEClass=*GRMG* and set the option OnlyContext. All monitoring contexts whose MTE class contains the
character string GRMG will be displayed in the monitor.
CCMS_GET_MTE_BY_CLASS _AND_CLIENT
12/20/2019
This rule is largely similar to CCMS_GET_MTE_BY_CLASS; however, you can also restrict the monitoring to speci c clients.
CCMS_GET_MONITORING_SEGMENT_NAMES and CCMS_GET_MONITORING_CONTEXT_NAMES
These rules are only for internal SAP purposes. Although you can experiment with them, we recommend that you do not use
them in your own monitor de nitions.
CCMS_GET_AVAILABILITY_FOR_SYSTEM
This rule is reserved by SAP for later use. We recommend that you do not use it in your own monitor de nitions.
Display Options for MTE Nodes
When de ning your own monitors, you can determine how the names of the monitoring tree elements are created when constructing
the alert monitoring tree. An MTE is characterized by four name parts:
System: the system to which the associated monitoring attribute refers
Context: the monitoring context (the root node of a monitoring tree)
Object : the monitoring object
Short Name: the short name of the MTE
Tip
CEN\Host1_CEN_01\...\Dialog\ ResponseTime is the long name of the dialog response time; the monitoring object is
Dialog,and the short name of the MTE is ReponseTime. When creating or editing a rule node, you can either display the long
MTE name or any of the four parts of which the long name consists, which are listed above.
Display Options for Virtual Nodes
When de ning your rule MTEs, you can de ne whether the monitor is to display virtual nodes, which originate from this rule. The
indicator Display Virtual Summary Nodes in the Monitoron the Edit Rule Nodes screen is used for this purpose.
Tip
The top node of most SAP monitor de nitions is a rule node with the rule CCMS_DEFINE_R3_SYSTEMS. This rule creates virtual
summary nodes for the monitored systems. SAP recommends the following setting, depending on your system landscape:
If you are only monitoring one system (R3System = <CURRENT> or <systemname>), another level with the system name
does not provide any new information, but rather makes the monitor less clear. You should therefore deactivate the indicator
Display Virtual Summary Nodes in the Monitor.
If you are monitoring multiple systems (R3System = <ALL> or <system group>), the monitored systems should create the
next level of the monitor so that the application servers of the various systems are grouped in a clearer way. You should
therefore activate the indicator Display Virtual Summary Nodes in the Monitor.
Restrictions
You cannot organize multiple copies of a rule MTE hierarchically. The alert monitor displays an error message if you attempt to create a
rule MTE CCMS_DEFINE_R3_SYSTEMS under another MTE CCMS_DEFINE_R3_SYSTEMS.
See also:
12/20/2019
De ning Monitors with the

DEFINE_R3_SYSTEMS/GET_MTE_BY_CLASS
Rules
You can use these two rules to quickly and simply create monitors if you rst answer these two questions:
From which systems is monitoring data to be displayed?
What MTE classes does the monitoring data to be displayed have?
You can determine the MTE class of the desired data by calling a monitor that contains the desired nodes, switching to the
Technical View: Info on MTE, or by selecting the desired node and choosing Properties.
Monitor De nition
To create a monitor, proceed as described in Creating and Changing Monitors. The gure below shows a simple rule-based monitor
de nition using the above rule (for information about the possible rules and display options, see Rule MTEs: Rule Descriptions and
Use):
Note the following for the CCMS_DEFINE_R3_SYSTEMS rule:
You usually use the rule as the root node of the monitor.
You de ne the systems to be displayed in the parameter R3System. You can enter the following values when doing so:
Entry Meaning
<CURRENT> Local system
12/20/2019
Entry Meaning
<ALL> All systems that are known to the monitoring architecture as

monitored systems (see Registering SAP NetWeaver Components
and Hosts in CEN)
<any name> System group; you can de ne a system group yourself that
contains the desired systems (see Maintaining System Groups)
In the display options for the rule, you should activate the indicator Display virtual summary nodes in the monitor if, and only if,
you want to display multiple systems. If you are only monitoring one system, another level with the system name does not
provide any new information, but rather makes the monitor less clear.
Note the following for the rule CCMS_GET_MTE_BY_CLASS:
If (as in this example) there is a CCMS_DEFINE_R3_SYSTEMS rule above this rule, the rule inherits the system, otherwise, you
usually de ne the systems yourself.
It is usually not necessary to select Display long MTE name in the display options. You should instead select only the parts of
the MTE name that are necessary to understand the monitor display. In this example, this is the context (which speci es the
instance for most nodes).
Monitor Display
If you choose Generate Monitor ( ) for the above monitor de nition, the following monitor is generated:
12/20/2019
De ning Monitors with the Rule

GET_MTE_BY_CLASS_AND_OPTIONS
Use this rule primarily in the following cases:
You want to display multiple MTE classes that have a common naming convention in the monitor, especially if you do not yet
have the names of all of the MTE classes to be displayed when you are creating the monitor de nition (see example 1).
You want to restrict the search for MTE classes at runtime when creating the monitor to certain segment types to improve
performance or clarity (see example 2).
Example 1: Monitor De nition

Use):
The MTE classes to be displayed for the availability of the GRMG scenarios have the naming convention GRMG_ScenAvail_<scenario
name> (see Monitoring with the Generic Request and Message Generator). If you wanted to display the availability of all scenarios, you
would need to enter all MTE classes without this rule. However, the names of these MTE classes are not currently available to you.
Example 1: Monitor Display

If you choose Generate Monitor ( ) for this monitor de nition, the following monitor is generated:
12/20/2019
Example 2: Monitor De nition

In this case, you are using the options of the rule CCMS_GET_MTE_BY_CLASS_AND_OPTIONS. Among other things, you can use the
options OnlyAgent and NoAgent to de ne whether the MTE class must be in an agent segment or must not be in an agent segment.
The Java nodes, for example, always belong to the monitoring segment of a SAPCCMSR CCMS agent (for more options, see Rule
MTEs: Rule Descriptions and Use).
If you choose Generate Monitor ( ) for this monitor de nition, the following monitor is generated:
12/20/2019
De ning Monitors with the Rule

GET_MTE_BY_CLASS_AS_VIRTUAL
Always use the rule CCMS_GET_MTE_BY_CLASS_AS_VIRTUAL together with the rule CCMS_GET_MTE_BY_CLASS_UNDER_CLASS.
You can use these two rules to display sections of hierarchy trees without having to do without the hierarchical display.
For example, if you want to monitor the following operating system resources, which are to be displayed structured by the monitored
hosts:
CPU utilization (MTE class CPU_Utilization)
Paging-in rate (MTE class Page_In)
Paging-out rate (MTE class Page_Out)
These MTE classes are part of the operating system subtree (MTE class OperatingSystem). If you create a monitor with the rule
CCMS_GET_MTE_BY_CLASS with the MTE classes listed above, you obtain all of the desired values, but in a at hierarchy:
However, if you specify the superordinate MTE class OperatingSystem in the rule CCMS_GET_MT_BY_CLASS, you obtain the desired
hierarchy, but all other values in this subtree as well as the desired values.
12/20/2019
Use the rules CCMS_GET_MTE_BY_CLASS_AS_VIRTUAL and CCMS_GET_MTE_BY_CLASS_UNDER_CLASS instead.
Monitor De nition
Use):
Keep in mind the following points when you use these rules:
Specify the MTE class of a subtree of which you only want to display a section in the rule
CCMS_GET_MTE_BY_CLASS_AS_VIRTUAL. Typical examples of subtrees of this type are:
Instance (MTE class R3ApplicationServer)
Operating system data (MTE class OperatingSystem)
12/20/2019
J2EE Engine (MTE class SAP_J2EE_Engine)
Corresponding subtrees are then displayed in the monitor as virtual nodes.
You specify the MTE class of the node that you want to display under the subtree de ned above in the ChildMTEClass
parameter in the rule CCMS_GET_MTE_BY_CLASS_UNDER_CLASS. The rule adopts the parameters MTEClass and R3System
from the higher-level rule CCMS_GET_MTE_BY_CLASS_AS_VIRTUAL.
To display multiple MTE classes, simply create multiple CCMS_GET_MTE_BY_CLASS_UNDER_CLASS rules under the
CCMS_GET_MTE_BY_CLASS_AS_VIRTUAL rule.
The Short Name is usually sufficient in the Display Options in CCMS_GET_MTE_BY_CLASS_UNDER_CLASS, since the context
is already displayed by the superordinate rule.
Monitor Display
If you choose Generate Monitor ( ) for the above monitor de nition, the following monitor is generated:
Monitoring Properties Variants

De nition
A monitoring properties variant contains settings for properties and method assignments for monitoring tree elements (MTEs), MTE
classes, and attribute groups. Every change to these settings is assigned to a properties variant.
Use
MTEs are prede ned with their general properties, method assignments, and alert threshold values. These settings are grouped into
properties variants. You can use multiple properties variants when monitoring your IT landscape, allowing you to utilize different
monitoring strategies. The current settings delivered by SAP are contained in the SAP DEFAULT properties variant.
12/20/2019
There is a hierarchy of properties variants in the monitoring architecture, in which the values contained in SAP DEFAULT are at the
lowest level. MTE values changed by customers and saved in the active properties variant are at the very top of the hierarchy. This is
the active properties variant. If you do not specify a variant when changing MTE values, the change is saved in the variant *.
As of SAP R/3 4.6A, there is an additional level in this hierarchy. If you create a monitoring properties variant, you can specify a
superordinate variant (parent variant) whose values are to be used if the variant de ned by the customer does not contain any values
for an MTE class. If the parent properties variant also contains no values for the MTE class, the system uses the values contained in the
SAP DEFAULT properties variant.
As of SAP R/3 4.6A, you can also assign a properties variant to an operation mode (see De ning Operation Modes). This has the
advantage that you no longer need to activate the variant manually. The variant is activated when the relevant operation mode starts.
See also:
Changing Monitoring Properties Variants
Activating Monitoring Properties Variants
Copying a Monitoring Properties Variant

Use
You can copy the values contained in amonitoring properties variant to another variant. You can also select individualproperties for
certain monitoring tree elements (MTEs) or MTE classes in a properties variant and then copy them to another properties variant.
12/20/2019
You do not need to de ne speci c values for every individual MTE class in your properties variant. If you do not specify your own values
for an MTE class, the system automatically uses the values prede ned by the customer (properties variant *), or theSAP-DEFAULT
values.
Caution
Do not copy the properties variant SAP-DEFAULT, since you would prevent the updating of the values when a new SAP-DEFAULT
variant is imported.
Procedures
Copying Speci c Properties from One Monitoring Properties Variant to Another
Choose CCMS → Control/Monitoring → Alert Monitor, or call transaction RZ21.
In the Properties group box, select either the Properties Assigned to MTE Classes radio button or the Properties Assigned to Attribute
Groups radio button, and choose Display Overview.
Sort the list by the Values for Variant column. You can then clearly recognize the properties variants with your MTE classes or attribute
groups.
Select the individual MTE classes or attribute groups that you want to include in your target properties variant, and choose List →
Select Entries → To Variant. You can use the possible entries help to display a list of the available properties variants.
Copy Monitoring Properties Variants to a Target Properties Variant
Choose CCMS → Control/Monitoring → Alert Monitor, or call transaction RZ21.
Choose Properties →Variants →Variants Overview.
Tocreate a new monitoring properties variant, choose Variant →Create.
Choose Variant → Copy. Specify the source and target variants. You can use the possible entries help to display the properties variants
available in the system.
Select the data that you want to copy from the source variant to the target variant.
Choose Continue. The data that you have speci ed is copied to the target variant. The data that exists in the target variant is
overwritten.
You have now copied all properties of a variant to the target variant. If you want to edit the target variant, proceed as follows:
To display the contents of the target variant, return to the initial screen of transaction RZ21. Select either the Properties Assigned to
MTE Classes radio button or the Properties Assigned to Attribute Groups radio button, and choose Display Overview.
Sort the list by the Values for Variant column. You can then clearly recognize the properties variants with your MTE classes or attribute
groups.
You can reduce the size of the properties variant by selecting the individual properties that you want to include in your properties
variant and choosing Delete Entry.
To change the properties of an individual MTE class or attribute group, select the MTE class or attribute group and choose Edit Data.
Switch to change mode by choosing Display «Change ( ), and change the settings as desired.
Create Monitoring Properties Variant

12/20/2019
Create Monitoring Properties Variant
Use
A monitoring properties variant is a collection of settings for one or more monitoring tree elements (MTEs) in the Alert Monitor. If you
activate a properties variant, you can use the settings saved in it in the Alert Monitor.
You can de ne multiple properties variants with different settings for the same MTEs or MTE classes. You can also transport properties
variants. You can de ne your own strategies for system monitoring based on these properties.
Procedure
Creating a Variant
1. Start the Customizing transaction by choosing CCMS → Con guration → Alert Monitor, or call transaction RZ21.
2. To create a properties variant, choose Properties → Variants → Create. Enter a name and a description for the variant, and
specify the superordinate variant (parent variant), whose values are to be used if the new variant does not contain a speci c
value for an MTE class. Enter the person responsible for the variant under Owner. If you are using variants from third party
suppliers, the vendor's name is displayed under Owner.
3. Choose Save. The system returns you to the initial screen of transaction RZ21.
Assigning Objects
Assign objects (MTE classes, attribute groups, or individual MTEs from the monitoring tree) to your new properties variant. All of these
objects should follow the same monitoring strategy:
1. Select a object type in the Properties group box in transaction RZ21, and choose Display Overview, to display a list of objects.
2. Select the objects that you want to include in the properties variant, and choose List → Select Entries → To Variant
3. The system displays a dialog box in which you select the properties variant to which you want to copy the object settings.
4. If you want to change the settings for the object, switch to change mode by choosing Display « Change ( ). The changes are
stored in the properties variant to which you have assigned the object. Your changes are active as soon as you activate the
variant (see Activating Monitoring Properties Variants).
See Also:
Changing Monitoring Properties Variants
Copying Monitoring Properties Variants
Change Monitoring Properties Variant

Change Monitoring Properties Variant
Use
If you change an MTE from the Alert Monitor, your changes are automatically stored in the currently active properties variant.
If you call the Customizing transaction RZ21 directly, you can change any properties variant of your choice.
Procedure
Change Active Properties Variant
12/20/2019
3. To change the monitor, choose Extras → Activate Maintenance Functions and select the MTE for which you want to change the
properties. Choose Properties.
4. The system displays the Monitoring: Properties and Methods screen. Choose change mode with the Display « Change ( )
pushbutton.
5. Make the required changes. When you save the changes, they are automatically stored in the properties variant that is currently
active in the Alert Monitor.
Change Any Properties Variant
1. Choose CCMS → Con guration → Alert Monitor, or call transaction RZ21.
2. In the Properties group box, choose one of the following radio buttons:
Properties assigned to MTE classes
Properties assigned to attribute groups
MTE-speci c properties
1. Choose Display Overview. The system displays a screen with a list of properties. You can identify to which properties variant the
property is assigned in the Values for Variant column. Choose the desired property by double clicking it.
2. The system displays the Monitoring: Properties and Methods screen. Choose change mode with the Display « Change ( )
pushbutton.
3. Make the required changes. When you save your changes, they are stored in the properties variant speci ed above.
Activating a Monitoring Properties Variant

Use
Procedure
1. Start the Customizing transaction by choosing CCMS → Con guration → Alert Monitor, or call transaction RZ21.
2. The Monitoring: Properties and Methods screen appears. The eld Variant Currently Activedisplays the properties variant that
is currently active. Choose Properties → Variants → Activate.
3. The system displays a dialog box in which you can choose the properties variant to be activated.
Note
The settings in the variant become active immediately. You do not need to de ne speci c values for every individual MTE
class in your variant. If you do not specify your own values for an MTE class, the system automatically uses the values
prede ned by the customer (properties variant *), or, if this does not exist, the SAP-DEFAULT values.
See also:
Copying a Monitoring Properties Variant
Creating a Monitoring Properties Variant
SAP-DEFAULT
12/20/2019
De nition
SAP-DEFAULT is a monitoring properties variant that contains the SAP default values for the properties of all monitoring tree elements
(MTEs).
Use
You can use SAP-DEFAULT as a template for creating your own properties variants for speci c MTEs in your system. You cannot change
or delete the settings in SAP-DEFAULT.
Note
The advantage of the SAP-DEFAULT properties variant is that you do not need to de ne a speci c value for every single MTE in your
properties variant(s). If you do not specify a value of your own for an MTE, the SAP-DEFAULT values are always used.
User-de ned properties variants are not affected by new SAP-DEFAULT values during an upgrade. This means that both the newest
SAP default values and your own user settings are available in the system. You can therefore always return to SAP-DEFAULT if you
unintentionally change the values delivered by SAP in the system, and use SAP-DEFAULT as a reference for the values recommended
by SAP.
See also:
Creating a new SAP-DEFAULT Variant
Creating a New SAP-DEFAULT Variant

Use
We recommend that you create a new SAP-DEFAULT properties variant in the following cases:
If you install a new component of the SAP system
After a release upgrade
If you have written a new data supplier whose values have changed and you want to load the new values into the database
If you create a new SAP-DEFAULT variant, the old default values are automatically saved in the properties variant SAP-
DEFAULT_OLD_X. When you restart the application server, the newest default values in the database are loaded and saved as the new
SAP-DEFAULT variant. User-de ned properties variants are not affected by these changes; that is, you can compare the values in your
own properties variants with the SAP default values.
Procedure
Choose CCMS →Con guration →Alert Monitor, or call transaction RZ21.
The Monitoring: Properties and Methods screen appears. Choose Properties → Variants → Variants Overview
→ Variants → SAP-DEFAULT Variant → Create New Version.
The system informs you in a dialog box about the function of the SAP-DEFAULT variant. Choose Continue, and con rm the question in
the next dialog box about whether you want to create a new SAP-DEFAULT variant.
12/20/2019
Result
After you restart the application server, the new SAP-DEFAULT values are loaded into the database. The old values are saved in the
properties variant SAP-DEFAULT_OLD_X.
Registering SAP NetWeaver Components and

Hosts in CEN
Use
To centrally monitor remote SAP NetWeaver components or any hosts, you need to register the corresponding component in CEN.
There are two ways of doing so:
If you are using the SAP NetWeaver Administrator (NWA), we recommend that you con gure the monitored components using
the Con guration Wizard.
If you are using the Alert Monitor, register the desired component in the con guration transaction for the Alert Monitor
(transaction RZ21). This procedure is described here.
Prerequisites
There is a CSMREG user in CEN.
There is also a CSMREG user on the ABAP or double-stack system to be monitored.
If you want to register a host with no SAP NetWeaver components in CEN, install the host agent on that host.
The Java or TREX systems to be monitored have a release status of at least SAP NetWeaver 7.0 EhP2.
Note
You can register Java and TREX systems with a release status up to SAP NetWeaver 7.0 EhP1 with CEN using CCMS agents.
Note
If you want to centrally monitor any system with a central monitoring system with release SAP NetWeaver 7.0, this procedure
is not applicable. In this case, follow the procedure described in the newest Monitoring Setup Guide for SAP NetWeaver 7.0
instead. You can obtain the Monitoring Setup Guide at the Internet address service.sap.com/operationsnw70 in the
Monitoring area.
Procedure
1. To monitor an additional system or host, call transaction RZ21.
2. Choose Technical Infrastructure Con gure Central System Create Remote Monitoring Entry .
3. Choose which component type you want to register in CEN.
4. In the group box CSMREG User of the Central System, enter the password for the CSMREG user in CEN.
5. Depending on the type of component to be monitored, enter the following system and connection data for the component to be
monitored:
Type Input Data More Information

12/20/2019
ABAP The connection to the monitored system is

System ID
tested with user CSRMREG when you save
Double-Stack
Message Server (or if you choose the button in the RFC
Connections to Remote Component)
Logon Group; the SPACE, which group box. The monitored component is
always exists, is set as the default only added and the RFC destinations (see
below) are only created if the test is
Password of CSMREG on the
performed successfully.
monitored system
Java
System ID
Message Server
HTTP port of the message server
TREX You require the user at operating system

System ID
level to execute a con guration script on
Server the TREX host (see TREX documentation).
Instance number
Register only hosts without SAP NetWeaver

Host Host Name
components here. Ensure that the host
agent is installed on the host.
6. In the Operating System User on the Host of the Monitored System group box, enter the password of an administration user
at operating system level. For an SAP NetWeaver component, this is the user <SysID>adm., for a host, it is sapadm.
Note
You require this authentication since the Web service call for registering a component in CEN is protected.
Technical Background
To monitor an ABAP or dual-stack system centrally, the system creates two RFC destinations in that system:
<SysID>_RZ20_COLLECT reads monitoring data for the monitored system; the connection uses the CSMREG user.
<SysID>_RZ20_ANALYZE is the destination with which you as an administrator can execute an analysis method in
the monitored system. The destination is created without a user, meaning that you need to authenticate yourself in the
monitored system.
A Customizing destination between the CEN and the relevant Java Engine is required, so that you can change the properties of
the monitoring data of the Java Engine (such as threshold values) from the Alert Monitor. This is automatically created under
the name SAP.CCMS.J2EE.<SysID> when adding a Java system, where <SysID> is the system ID of the Java system to be
monitored.
Result
You can now monitor the corresponding with the Alert Monitor or with the NWA. If you are using rule-based monitors for monitoring,
the new system is automatically added to your monitors. Otherwise, add the new system to your monitors or create a new monitor (see
Creating and Changing Monitors).
Note
To deregister a component again, call the topology display (see Technical Topology of the Monitoring Architecture).
12/20/2019
More Information
Infrastructure of the SAP NetWeaver Management Agents Start Page
Host Agent
Creating the CSMREG User

Use
To monitor remote systems, you require a user for the monitoring infrastructure with speci c, greatly-restricted authorizations. The
user should have the User Type Communications. We recommend that you create and use the user CSMREG for this purpose. You
require this user for the following tasks, for example:
Performing the data collection in the monitored systems
Pushing the monitoring data from monitored systems that are connected to the central monitoring system using CCMS agents
(see Installing/Registering the CCMS Agents for Experts)
Registering a System Component Repository (SCR) with a central repository
You need to create the CSMREG user in all monitored systems; it is not created automatically.
Procedure
1. Choose CCMS Con guration Alert Monitor , or call transaction RZ21.
2. Choose Technical Infrastructure Con gure Central System Create CSMREG User .
3. Enter any password for this user.
Note
If errors that indicate a missing pro le occur when creating the user, generate the pro le for the role SAP_BC_CSMREG in
transaction PFCG (more information: Role Maintenance).
Note
The role SAP_BC_CSMREG contains the following authorizations:
Authorization Object Field Value
S_CCM_RECV ACTVT P0-P2
TABLE *
S_RFC RFC_FUGR FUGR
12/20/2019
Authorization Object Field Value
RFC_NAME SALC
SALF
SALH
SALP
SALS
SAL_CACHE_RECEIVE
SDIFRUNTIME
SYST SCSM*
SYSU
SCCMSBI_UTIL_FUNCTIONS
RFC1
SAPWLN3_COLLECTOR
SAPWLN3_UTILITIES
SCCMSBI_UTIL_FUNCTIONS
SWNC_GLOB_SYSTEM
ACTVT 16
Monitoring multiple systems with identical

system IDs
Use
If you want to monitor multiple systems, enter the Target System ID of the system to be monitored. This is usually the system ID of the
system. The monitoring infrastructure uses this target system ID to identify and differentiate between all monitored systems.
It is now possible that you want to monitor multiple systems with an identical system ID. This situation occurs in particular in very large
IT landscapes or with outsourcing. In this case, nodes from different systems, but which are known by the same target system ID in the
monitoring infrastructure, can no longer be clearly assigned to the corresponding system. You should therefore assign target system
IDs that are unique system landscape-wide in the case of multiple systems with an identical system ID. When doing this, you must only
ensure that the rst three characters of the target system ID match the system ID of the corresponding system.
The nodes of the systems can then be assigned to exactly one system within the central monitoring system using the unique target
system ID. However, only the rst three characters of the target system ID are used during access to the remote system (such as for
data collection or to execute and analysis method). As these three characters are the three-character system ID, it is possible to read
and process data in the remote system. When transporting data back to the central system, the system ID is again supplemented by
the target system ID known in the central system. The longer target system ID is always used in the central monitoring system.
Procedure
To do this, follow the procedure described in Registering SAP NetWeaver Components and Hosts in CEN. Specify the desired target
system ID as the System ID. Ensure that you ful ll the following three conditions when doing so:
The rst three characters of the target system ID match the system ID of the remote system.
12/20/2019
The target system ID is unique among all monitored systems.
The target system ID has a maximum length of eight characters.
The rest of the procedure is the same as the standard registration of a system to be monitored.
Note
Note that when you are registering the SAPCCMSR -j2ee agent using the Visual Administrator, the target system ID cannot contain
an underscore ( _) (see Installing an Agent on a Java Instance (Java Standalone System)).
System Groups in the Alert Monitor

Purpose
A system group consists of a series of systems that you want to display together in the CCMS monitoring architecture. You can enter a
system group when de ning a monitor: the monitor then contains all systems that belong to the system group.
Integration
De nitions of system groups are stored in the CCMS System Component Repository (SCR). The SCR is a component that maps one or
more SAP systems.
Example
You want to distribute the monitoring of your SAP systems among several colleagues. To achieve this, you can de ne a system group
for each colleague and assign the systems that each person is to monitor to the corresponding system groups. You then de ne a
monitor for each system group in the Alert Monitor. In the monitor de nitions, you specify the name of each system group in the rule
CCMS_DEFINE_R3_SYSTEMS. The monitor de nitions resolve the system group into the systems de ned in it. In this way, each
colleague sees the systems for which he or she is responsible in the monitor.
See also:
Maintaining System Groups
Registering SAP NetWeaver Components and Hosts in CEN
Creating a Central Repository
Maintaining System Groups

Use
You can create and delete system groups, and add systems to and remove systems from existing system groups.
Note
The CCMS System Component Repository (SCR) automatically creates system groups, which you can use as you want, if the
systems contained in the groups are monitored by the monitoring architecture (see Registering SAP NetWeaver Components and
12/20/2019
Hosts in CEN). A system group is created for each SAP release and each database system in use. Each of the groups contain the
relevant systems of the SCR.
Procedure
To call the individual functions in the table, choose CCMS → Con guration → Alert Monitor, or call transaction RZ21. Choose Technical
Infrastructure → Con gure Central System → Maintain System Groups, and expand the tree to display the groups that have already
been de ned.
Function Navigation What You Should Know
Create a new system group Maintain Groups → Create System Group The new system group initially has the icon
.The group only has the folder icon ( or )
once it contains systems.
Delete a System Group Select the system group, then choose

Maintain Groups → Delete System Group and
con rm the command
Add a System to a System Group Select the system group, then choose Use the input help to display the systems that
Maintain Systems → Add System are known to the monitoring architecture.
Remove a System from a System Group Expand the system group and select the The system is only removed from the system
system, then choose Maintain Systems → group. However, it is not removed from the
Delete System and con rm the command entries for remote systems.
Result
The entries that you have made are saved directly. You do not need to save the data before leaving the screen.
Deactivating and Reactivating Monitoring Tree

Elements
Deactivating and Reactivating Monitoring Tree Elements
Use
You can deactivate individual monitoring tree elements (MTEs). This means that the system collects no values and generates no alerts
for these MTEs. This is useful if, for example, you are working on a particular component on which an error occurred. You can avoid the
system generating additional alerts for this component while you are working on the problem. As the data collection methods for the
deactivated MTEs are also no longer executed, you also reduce the workload created by monitoring.
You can also Delete nodes. Deleted nodes are no longer displayed in the alert monitoring tree, are explicitly deleted in shared memory,
and can only be recreated by restarting the relevant application server or associated startup method (see Deleting and Recreating
Nodes in the Alert Monitoring Tree).
Prerequisites
To be able to change the Alert Monitor, you must rst activate the maintenance functions.
Constraints
You cannot deactivate virtual nodes.
12/20/2019
Procedure
3. Choose Extras → Activate Maintenance Function.
4. Select the desired node in the Alert Monitor, and choose Edit → Node (MTE) → Deactivate.
5. The node now contains the description <<<<Node is deactivated>>>>. If you also no longer want to display the node, you must
change the appropriate monitor de nition (see Creating and Changing Monitors). This is, however, only possible for your own
monitors, as you cannot change the monitors delivered by SAP.
Result
The MTE still exists in the monitoring segment of the shared memory, but is no longer used. As the data collection methods are also no
longer performed for this MTE, this does not affect performance.
The deactivation of the data collection method applies only to the selected MTEs. If the same method is still assigned to other MTEs,
the deactivation of a method for one node does not affect other nodes with the same method.
No alerts are generated in the selected MTEs until you reactivate them. To do this, repeat the procedure above, but choose Edit → Node
(MTE) → Activate.
Deleting and Restoring Nodes in the Alert

Monitoring Tree
Deleting and Restoring Nodes in the Alert Monitoring Tree
Use
Monitoring objects in the alert monitoring tree are created during the rst run of the corresponding data suppliers and stored in the
monitoring segment of the shared memory. At the start of the alert monitor, the information is read from the shared memory and
displayed in various monitors broken down by components and applications and grouped by topic.
You can remove individual nodes or entire subtrees both from the display and from monitoring by the monitoring architecture. This can
be useful to improve the clarity of the monitors that you are using or to improve the performance of the monitoring. You must
differentiate between four types when deleting:
Remove the node from the display
Stop the associated data collection methods
Delete the node in shared memory
Delete the class properties (such as threshold values) from the database
In addition to the commands described here, you can also Deactivate Monitoring Tree Elements. This means that no more values are
collected for the nodes. However, the nodes remain in the alert monitoring tree with the entry <<<<Node is deactivated>>>> and are
not deleted from the shared memory.
Prerequisites
To delete a node, you must rst activate the maintenance functions.
Deleting a Node from the Alert Monitoring Tree
1. Start the Alert Monitor. To do this, choose CCMS → Control/Monitoring → Alert Monitor, or call transaction RZ20.
2. Activate the maintenance functions. To do this, choose Extras → Activate Maintenance Functions.
12/20/2019
3. Start the monitor in which you want to delete a node and select the desired node.
4. Choose Edit → Nodes (MTE) → Delete. The system displays the Note for "Delete Node" Operation screen. You have the
following options:
Remove the node from the display (Option 1)
With this option, you change only the display of the node in the alert monitoring tree. To allow you to do this, the system displays the
de nition of the monitor. Change the de nition so that the relevant node is no longer part of the monitor. This is only possible for your
own monitors, as you cannot change the monitors delivered by SAP (see Creating and Changing Monitors).
Delete the node from the runtime environment (Option 2)
With this option, you delete the node from the alert monitoring tree and from the shared memory. This option is not possible for virtual
nodes.
We recommend that you use the deactivation of nodes instead of options 2 to 4. The advantage is that you can reactivate the
deactivated nodes much more easily.
You should, in particular, not use options 3 and 4 in most cases, as even a node that you have deleted using option 2 neither creates
workload due to monitoring nor requires space in the monitoring segment. It is therefore not necessary to additionally delete the class
properties of the node in the database.
Restoring a Node in the Alert Monitoring Tree
If you want to restore a node that you have deleted, follow the appropriate procedure below, depending on the deletion method that
you used:
You only deleted the node from the display (option 1)
In this case, you only need to change the corresponding monitor de nition again.
You deleted the node in the runtime environment (options 2-4)
In general, nodes that have been deleted from the shared memory are recreated and provided with values again, at the latest when the
relevant application server is restarted. For nodes with passive data suppliers (the data collection methods), it is sufficient to execute
the corresponding method. Follow the procedure below:
2. In the Topology group box, choose Segment Overview and choose Display Overview.
3. The system displays the Monitoring: Display Technical Topology screen. Choose change mode with the Display « Change ( )
pushbutton.
4. Choose the segment that contains the node. If the deleted node is contained in a subtree of an application server, this is the
segment with the name of the application server; otherwise, the segment is the central instance.
5. Choose Reset Segment in "WARMUP" Status. This restarts all startup methods of this monitoring segment.
You can nd out whether a node is provided with data by passive or active data suppliers by choosing the Properties for the node. If an
entry exists for Data Collection Method in the tab page Methods, the node is supplied with data by a passive data supplier.
Display Options of the Alert Monitor

Use
The display options combine the settings that determine which data is displayed in the various displays and views of the Alert Monitor.
You can also determine whether and with what frequency the display should be refreshed.
12/20/2019
Features
Monitor-Speci c Settings of the Display Options
· Refreshing the Monitor Display
If automatic refreshing is activated, the Alert Monitor updates the display with the information currently available in the
monitoring system. The refreshes are performed at the intervals that you de ne in the display options. The alert monitoring tree
is not rebuilt during a refresh; rather, the existing MTEs are updated with the currently available information. We recommend
that you choose a refresh time of at least 300 seconds.
Note
You can also manually update the Alert Monitor by choose the Refresh pushbutton ( ), or by performing other operations
that trigger a refresh, such as exiting the Alert Browser, or switching from the Open Alerts view to Current Status.
· Detail Display Settings
You can determine which data is displayed in the detail display (see Display Detail Data and Tailor Display).
Global Settings of the Display Options
· Displaying Error Nodes
You can determine whether the Alert Monitor display should contain MTEs that are not currently functioning. Possible reasons
for this are:
¡ A monitoring segment has been set to offline, that is, the collection of information from the monitoring segment has
been deactivated.
¡ An error occurred when communicating with the remote server on which the monitoring segment is located. Data
from this segment could not be collected.
¡ The remote server on which the monitoring segment is located was shut down. Data from this segment could not be
collected.
If you display error nodes of this type, these nodes are indicated by a symbol ( ) displayed after the node.
· Displaying the Current Measured Values
You can determine whether the most recent relevant value is displayed in the Current Status view, or whether you simply want
to be informed about the current status of the node by its color.
· Displaying the Alert-Details
You can determine whether the message text for the alert is displayed in the Open Alerts view; you can also de ne in
superordinate nodes whether the alert text or the source of the alert is displayed.
Activities
To set the display options in the Alert Monitor, follow the procedure below:
3. 3. Choose Extras → Display Options.
4. 4. Depending on which options you want to set, switch to the appropriate tab page:
Function Tab Page
Refreshing the Monitor Display General
Detail Display Settings Tree Display
12/20/2019
Function Tab Page
Displaying Error Nodes
Displaying the Current Measured Values
Displaying the Alert-Details Detail Data Display
5. 5. Make your settings and con rm your changes.
Saving and Resetting the Layout of a Monitor

Use
The layout of a monitor includes the most important settings for the display of the nodes and the monitoring tree in general. This
includes the following settings:
· Active monitor-speci c display options (see Display Options of the Alert Monitor)
· Expanded and collapsed subtrees (see Actions in the Alert Monitoring Tree)
· Selected nodes (see Selecting Nodes in the Alert Monitoring Tree)
· Active monitor-view (see Display Types and Views of the Alert Monitor)
Tip
You can therefore use the layout to ensure that when the monitor is opened, especially important subtrees are already
expanded, for example, or that certain nodes are already selected.
Saving a layout means that the monitor requires a longer load time when it is called. However, from experience, this only has an impact
for large monitors (with more than 1000 nodes). For these monitors, you should decide whether the advantages of a monitor layout
outweigh the disadvantages for you. To minimize the load time, you can also restore the standard layout for a monitor.
Procedure
Saving a Layout
2. 2. Expand the monitor set that contains the monitor that you require, and choose Monitor (Set) → Load Monitor.
3. 3. Set the display of the Alert Monitor in accordance with your needs.
4. 4. Save the layout by choosing Save ( ). If you are dealing with a large monitor, the system warns you that the load time of
the monitor is increased by saving a layout. If you want to accept this, con rm the save.
Resetting a Layout
2. 2. Expand the monitor set that contains the monitor that you require, and choose Monitor (Set) → Load Monitor.
3. 3. Choose Edit → Tree → Restore Default Layout.
12/20/2019
Extending the Shared Memory Area

Use
It is possible that the number of monitoring tree elements (MTEs) in the Alert Monitor and the consequent number of alerts can
become so large that the monitoring segment of the shared memory is not large enough to hold them all. This is especially the case if
too many alerts are generated because of incorrect settings for the threshold values of the MTEs, or if the complete alerts function is
not executed often enough.
Prerequisites
To check whether there is still sufficient space in the monitoring segment of the shared memory, start the CCMS Selfmonitoring
monitor of the SAP CCMS Technical Expert Monitorsmonitor. Check the Space subtree for every application server. To do this, select
one of the attributes of the Space subtree and then choose Start Analysis Method.
Note
The same analysis method is assigned to the three attributes available in the Space subtree, Messages, FreeAlertSlots and
AlertsFrequency.
A dialog box appears, showing the utilization in the monitoring segment. If the space available for the various areas is too small, the
monitoring segment may be too small. In this case, you need to increase the size of the shared memory area for one or more
application servers so that there is sufficient space for all MTEs, attributes, and alerts in the tree.
Procedures
Follow the appropriate procedure, depending on whether the space problem is affecting the alerts or the MTEs/attributes:
Permanently Reduce the Number of Alerts in Shared Memory
Report RSAL_KEEPALTYPE_MODIFY
The best setting for the storing of alerts is to store only the newest alerts for each MTE, rather than any number of alerts. It
would be extremely laborious to manually change this setting for every MTE. To set this value for all MTEs of a system, start the
report RSAL_KEEPALTYPE_MODIFY.
Note
Execute the report once in each affected system and repeat this procedure after every upgrade of the system.
Set Automatic Completion of the Alerts
You can use the method CCMS_Segment_Space_Collect to set up an automatic completion of active alerts. To do this, follow the
procedure below:
2. In the Methods group box, select Method De nitionsand choose Display Overview.
3. The system displays an overview of the method de nitions. Choose the method CCMS_Segment_Space_Collect by double-
clicking it.
4. The system displays the Monitoring: Methods screen. Choose the Parameters tab page.
5. If the system is to automatically complete alerts after a certain number of days, enter the relevant value for the parameter
CMPL_ALERT_AFTER_DAY. The default value is 31. Uncompleted alerts are therefore saved to the alert database after
approximately a month, to create space for new active alerts in the limited shared memory.
6. If the system is to automatically complete alerts if the space in shared memory falls below a threshold value, specify the value X
for the parameter CMPL_ALERT_IF_QUOTA. The value at which the MTE FreeAlertSlots switches from green to yellow is used as
12/20/2019
the threshold value. The system completes the number of alerts required to reduce the number of alerts to the value at which
the color switches from yellow to green.
Note
To view or change the speci ed values, select the Properties Assigned to Attribute Groups radio button in the Properties
group box on the initial screen of transaction RZ21 and choose Display Overview. On the Overview of Attribute Groups
screen, select the CCMSSelfMoni-FreeAlertSlots by double-clicking it. The values are displayed in the Threshold Values
group box.
Increasing the Shared Memory
You can set the size of the monitoring segment in shared memory using the pro le parameter alert/MONI_SEGM_SIZE. The default
value depends on the SAP release. For SAP Web AS 6.20, the value is 16,000,000 bytes. Increase the value only in whole number
multiples of 2,000,000 bytes. Ensure that there is sufficient main memory and a large enough paging-out area on the application
server.
Caution
You should not change the size of the shared memory area in production systems. As far as possible, increase the shared memory
area only in the central monitoring system. You should also ensure that you increase the memory area by as little as possible.
See also:
SAP Note 135503
SAP Note 414029
Setting Up a Central Data Cache

Use
You can use a central data cache to improve the performance of the Alert Monitor when creating the alert monitoring trees. Data for
the various nodes is stored on the local application server in this cache, so that expensive RFC calls to the monitored systems are only
necessary when the de ned life span of the monitoring tree elements in the cache has expired. Depending on the attribute, this is
between two minutes (performance attributes) and twenty minutes (text attribute).
In the ideal case, absolutely no RFC calls are required from the central monitoring system, especially if the monitoring data is
transferred from remote systems using agents that use push technology as of SAP Web Application Server 6.10. The agents then
deliver their values once per minute directly to the central data cache, if they are registered on the server on which the cache is set up.
The basis of the central data cache is the technology of the Internet Server Cache (ISC). This is a cross-process cache in the main
memory of an application server.
Note
The central data cache is in the ccmcache subdirectory of the $DIR_DATA subdirectory. You can display the size of the cache and
the age of the entries using transaction AL11 (SAP Directories).
Procedure
Create Logon Group
12/20/2019
As the central data cache only exists on one application server, you should ensure that you always call the Alert Monitor on this
application server. We recommend that you create a logon group that consists of only one application server:
1. Start transaction SMLG (CCMS: Maintain Logon Groups)
2. Create a new logon group by choosing Create Assignment ( ).
3. The Create Assignment screen appears. Enter an appropriate name for the group in the Logon Group eld, and the name of the
application server on which you want to set up the central data cache in the Instance eld.
4. Ensure that the Ext. RFC enabled indicator is activated on the Properties tab page.
Activating a Central Data Cache
You activate the central data cache using the pro le parameter alert/cache/size_MB. This parameter is not set by default, meaning
that the central data cache is deactivated.
1. Start transaction RZ10 (Edit Pro les).
2. Use the input help for the Pro le eld to select the instance pro le of the application server for which you want to activate the
central data cache.
3. Ensure that Extended Maintenance is activated in the Edit Pro le group box and choose Change ( ).
4. The system displays a list with the pro le parameters for this instance. Create the parameter alert/cache/size_MB if it is not in
the list, and enter the size of the central data cache in megabytes.
Note
We recommend the following values as the size for the central data cache:
Platform Recommended Size in MB
32 Bit We recommend 4; if you are using a dedicated monitoring

system with a small number of users, you can increase the value
for the parameter to 10 to 20. Note, however, that the central
data cache requires the Extended Global Memory (parameter
em/Global_area_MB) when used in the main memory, which can
be very scarce on 32 bit platforms due to the restricted address
space. In this case, increase the value for the parameter
em/Global_area_MB as described in SAP Note 329021.
64 Bit 10% of the parameter em/Global_area_MB, although from

experience an increase of alert/cache/size_MB of over 40 does
not provide any additional performance bene ts. More
information: SAP Note 146289.
Registering Agents with this Application Server
Ensure that the NetWeaver management agents are registered with exactly the logon group that you have intended for monitoring
using the Alert Monitor. For information about registering the agents, see Registering SAP NetWeaver Components and Hosts in CEN.
Result
You have set up the central data cache on an application server. By setting up a logon group that consists of only this server, you ensure
that the central data cache in the Alert Monitor is active if you always logon to this group to use the Alert Monitor.
Note
12/20/2019
In your daily work with the Alert Monitor, you are normally only aware of the central data cache due to a better performance and the
output Central data cache active at the top of the alert monitoring tree.
If new nodes are not correctly displayed (for example, after a new application server is started), you can delete all entries in the
cache at any time. You do this using the Refresh and Invalidate Data Cache pushbutton ( ) (see Actions in the Alert Monitoring
Tree ).
Con guring the Caches of the Monitoring

Architecture
Use
The CCMS monitoring architecture uses various caches to improve its performance. The validity periods of these caches are stored in
the table ALCACHECNF of the central monitoring system. If the relevant values are requested during the validity period of the cache,
the query is met directly from the cache. This reduces the number of RFC calls required, which leads to an improved performance of
the display in the alert monitor.
Note
You can, however, use the buttons Refresh and Invalidate Data Cache (Control-F4) in the alert monitor, to force new collection of the
values at any time (see Setting Up a Central Data Cache).
These validity periods are set by SAP a way that means that even if there are a large number of changes in your monitored IT
landscape, you can quickly see all of these changes in the alert monitor. In very stable production environments, you can increase the
validity periods of selected caches as you wish.
Since there is not maintenance interface for ALCACHECNF, you must perform the maintenance in the Data Browser (transaction
SE16). There is an entry in the table for each individual cache, consisting of the technical name and the validity period in minutes.
The following caches exist in the monitoring architecture:
Technical Name Validity in Minutes Description
ALALERTX 1440 (1 day) Cache for active alerts
Since the alerts do not change until they are

completed, it is useful to store a duplicate of
an alert in the cache after it is read, and to
meet the next read request from this cache.
ALCONSEG 5 Cache for routing
If there are communication problems with

monitored systems or CCMS agents, the
system waits before its next connection
attempt to avoid triggering unnecessary trace
entries or timeouts. You set the wait time in
this cache.
ALMBCADM 30 Cache for collected MTEs from MTE classes
When processing rules, and in particular the

rule GET_MTE_BY_CLASS, the system
collects the MTEs of an MTE class using a
broadcast mechanism. This information is
12/20/2019
expensive to collect, but relatively static, and
is therefore stored in a cache. This cache
therefore determines the period of time after
which a newly started server is displayed in
the alert monitor.
ALMBRADM 30 Cache for collected MTEs from MTE classes
This cache is similar to ALMBCADM and is

required when processing the rule
CCMS_GET_MTE_BY_CLASS_AND_OPTIONS.
This rule exists as of SAP Web AS 6.40.
CSMCENTOOL 1440 (1 day) This value speci es the reorganization

frequency of the store for central auto-
reactions.
Caution
Do not change this value; it is only used
internally.
CSMSEGM 20 Cache for monitoring segments of monitored

systems
When processing rules, the system collects

the monitoring segments of the monitored
systems. This information is stored in a cache.
This cache determines the period of time after
which a newly started system is displayed in
the alert monitor.
CSM_X_TABLES 15 Cache for monitoring contexts of monitored

systems
When processing rules, the system collects

the monitoring contexts of the monitored
systems. This information is stored in a cache.
This cache determines the period of time after
which a newly started system is displayed in
the alert monitor.
Procedure
To change the validity period of one of the caches listed, proceed as follows:
1. Choose Overview → Data Browser, or call transaction SE16.
2. The Data Browser: Initial Screen screen appears. Enter the table name ALCACHECNF, and con rm your entry.
3. The Data Browser: Table ALCACHECNF: Selection Screen appears. Choose Execute ( ).
4. The Data Browser: Table ALCACHECNF screen appears. To change one of the validity periods, select the relevant entry and
choose the Change button ( ). In a very stable production environment, you can increase the validity periods of the following
caches as you wish:
ALMBCADM
ALMBRADM
CSMSEGM
CSM_X_TABLES
5. Enter the desired validity period in minutes and save your entries.
12/20/2019
Working with All-Clears (Green Alerts)

Use
When monitoring a system landscape using a central monitoring system (CEN), the Alert Monitor displays yellow or red alerts in the
case of error situations. The monitoring can react to alerts of this type using auto-reaction methods, such as sending corresponding
messages to the system administrator as e-mail or SMS.
It is also possible to generate messages for green "alerts" and react to them correspondingly. Green alerts of this type do not indicate
error situations, but are intended as all-clears or explicit messages that an action was successful.
Tip
The dialog response time was above the threshold value and therefore created red alerts. The measurements then reduce to
a level below the permissible threshold value again. The system is to generate a green alert when the measured value falls
below this threshold value.
The database backup was successful. The system is to explicitly generate a green alert for this message.
Conditions for Triggering Green Alerts
You can activate green alerts in the Alert Monitor for performance attributes and status attributes.
Behavior in the case of performance attributes
A green alert is generated if the current status is yellow or red and the next report sets the current status to green
Nogreen alert is generated if the current status is already green.
Behavior in the case of status attributes
A green alert is generated if the current status is yellow or red and the next report sets the current status to green
A green alert is generated if the current status is white or inactive and the next report sets the current status to green
Nogreen alert is generated if the current status is already green.
Prerequisites
To be able to generate green alerts, set the pro le parameter alert/GREEN_ALERTS=1 (see Pro le Maintenance) in all instances
pro les in CEN and in the systems in which you want to create green alerts.
After restarting, the monitored systems and CEN can now generate green alerts.
Note
You can also specify the above pro le parameter in the Pro le File of a Host Agent. In this case, green alerts are generated for the
MTEs that are transferred to the CEN using the relevant agent.
Procedure
To activate green alerts for individual nodes, proceed as follows:
1. Start the Alert Monitor in CEN by calling transaction RZ20.
3. Start the desired monitor and select the desired nodes.
4. Choose the Properties button, and Monitoring: Properties and Methods screen, choose the General tab page. You can change
the Maximum number of alerts kept here. By default, this value is 10.
12/20/2019
5. To permit green alerts, enter a negative value here, such as -10. The negative sign signals to the monitoring architecture that
green alerts can be generated for this node. The amount of the number set speci es the total number of alerts that can be
generated for the node.
Note
Note that when you make this setting, the permitting of green alerts is activated for all nodes with the same MTE class in the
system. Alternatively, you can also make the setting for an individual node by rst choosing Edit → Properties → Use for
individual MTE on the Monitoring: Properties and Methods screen.
6. Save your settings.
Result
The monitoring architecture now generates green alerts in accordance with the above conditions for the nodes that you selected.
Green alerts are displayed in the Alert Browser and behave in the same way as regular yellow and red alerts.
In particular, green alerts are taken into account by auto-reaction methods and can therefore be used to forward benign system
messages and all-clears to the system administrator by mail or SMS (see, for example, Forwarding Alerts to Alert Management (ALM)).
Con guring Central Monitoring of Syslog

Messages
Use
You can use the CCMS monitoring infrastructure to monitor the system log, among other things (more information: Syslog). By default,
the message text and criticality of the alert are taken from the settings in transaction SE92 ( Maintain Syslog Messages). However, you
can also de ne the criticality and severity for a system log message directly in the alert monitor itself, by de ning an alert lter. The
relevant procedure is also described in Syslog Monitor.
You always need to perform this con guration locally, that is, in the relevant monitored systems. This can be a very time-consuming
procedure, particularly in large landscapes.
It is therefore meaningful to centrally create lter settings for syslog messages for the monitored settings, and simply to distribute
them to all desired monitored systems. A function for doing this is described in this section.
Features
When distributing lter settings, the table ALGLOBSYSLGFIL is the center, which you need to ll in the central monitoring system
(CEN), and which contains the con guration settings to be distributed. The table has the following columns:
Column Description
LINENUMBER Positive whole number that de nes the sequence in which the lter
settings are assigned to the MTEs. The assignment starts with the
smallest number and is continued in the order of the values. This
means that settings with a lower LINENUMBER are overwritten by
those with a higher LINENUMBER, if these relate to the same message
ID.
SYSGROUP_OR_SID System ID of the monitored system (this system must be con gured in
the monitoring infrastructure in accordance with Registering SAP
NetWeaver Components and Hosts in CEN) or the name of the System
Group to which the lter setting is to apply.
12/20/2019
Column Description
FROMAREA Syslog messages have an ID consisting of three characters, which

consists of a group (the rst two characters) and a sub ID (the third
character).
You can specify ranges of syslog messages in the table, and assign a
particular criticality and severity to them in the CCMS monitoring
infrastructure. The columns FROMAREA and FROMSUBID specify the
start of a range of this type.
FROMSUBID
TOAREA You can specify ranges of syslog messages in the table, and assign a
particular criticality and severity to them in the CCMS monitoring
infrastructure. The columns TOAREA and TOSUBID specify the end of
a range of this type.
TOSUBID
MSGVALUE Criticality that is to be assigned in the monitoring infrastructure to the

messages in the range that you have just de ned. In this context:
Red alert: MSGVALUE=1
Yellow alert: MSGVALUE=2
Green alert: MSGVALUE=3
SEVERITY Severity that is to be assigned in the monitoring infrastructure to the

messages in the range that you have just de ned; the value must be
between 0 and 255.
The alert assignments are distributed to the monitored systems using the report CSM_DISTRIBUTE_ALGLOBSYSLGFIL. We
recommend that you schedule the report for regular execution as a job so that changes to the table ALGLOBSYSLGFIL are reliably
transported to the monitored systems.
Activities
To use central con guration for monitoring of syslog messages, proceed as follows:
1. Fill the table ALGLOBSYSLGFIL in CEN with the desired syslog IDs and the associated alert properties.
2. Execute the report CSM_DISTRIBUTE_ALGLOBSYSLGFIL in CEN. You can do this manually using transaction SE38.
Note
If you change the table ALGLOBSYSLGFIL, you need to ensure that the above report is executed again so that the current
con guration settings are active in the monitored systems. You can do this by scheduling the report
CSM_DISTRIBUTE_ALGLOBSYSLGFIL as a job to be regularly executed. You can do this by de ning a job (transaction
SM36); more information: Job Scheduling.
Error Handling and Self-Monitoring
To check whether the desired settings are in effect in a monitored system, check the settings of the attribute group
R3SyslogMcsDefaultCusGroup, which is assigned to all syslog messages in the monitoring infrastructure. You can do this as
follows:
1. Start the alert monitor by entering the transaction code RZ20.
2. In the monitor set SAP CCMS Monitor Templates, start the Syslog monitor by double-clicking it.
12/20/2019
3. Expand the subtree for any instance, select any log attribute, and choose Properties.
4. Switch to the Filter tab page. The table Revaluation of SAP System Log Messages on this tab page shows the con guration
settings that you created in table ALGLOBSYSLGFIL.
If the desired settings are not in effect in one or more monitored systems, check whether report
CSM_DISTRIBUTE_ALGLOBSYSLGFIL ran without errors:
1. Start the alert monitor by entering the transaction code RZ20.
2. In the monitor set SAP CCMS Technical Expert Monitors, start the monitor CCMS Selfmonitoring by double-clicking it, and
expand the subtree <SysID> CCMS_Selfmonitoring Customizing Distribution (CEN) .
3. The Messages log attribute contains any error messages that occurred during the execution of the report.
More Information
Detailed information about central con guration of the monitoring of syslog messages: SAP Note 1303845.
Best Procedure for Central Monitoring with

CCMS
Use
This section describes the Customizing settings and procedures that have proved themselves in day-to-day operation of CCMS
monitoring, and ensure high performance and reliability.
Process
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 x 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 x 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 speci ed 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.
12/20/2019
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 speci cation 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 ve (163840).
Consistency Check of the CCMS Monitoring

Infrastructure
Use
The CCMS Monitoring Infrastructure provides reliable and powerful functions for the central monitoring of any IT environments. The
large number of these functions and con guration settings on the one hand, and the many places in which errors can occur on the
other mean that it can become very time-consuming to search for the causes of any errors that occur or inconsistent con guration
settings, and to correct these.
The CCMS consistency check is available to you for this purpose. The associated transactions RZ50, RZ51, and RZ52 provide a variety
of functions to check the con guration and runtime of the CCMS monitoring infrastructure, to display errors, and to correct these
automatically. The checks are called from the central monitoring system (CEN) and include both the CEN itself and the monitored
systems. The individual checks, each of which relate to a topic in the central monitoring system or in a monitored system, are called
check objects.
In detail, the consistency check provides the following functions:
You can check the con guration settings of the CEN and (where it is meaningful) have them repaired, for example, in the
following areas:
Correct scheduling of required jobs of the CCMS monitoring infrastructure
Settings for availability monitoring with CCMSPING and GRMG
Con guration of the connections to monitored systems
Assignment of central auto-reaction methods
Speci c monitoring settings, such as the monitoring of selected transactions and jobs
You can display runtime errors for nodes in CEN and in monitored systems and have the errors repaired.
You can display the status of the connections between CEN and the monitored systems.
You can check the currentness of the data for selected nodes in CEN and in the monitored systems.
You can de ne reference settings for speci c nodes and, if necessary, centrally distribute these to all monitored systems. These
settings are combined and stored as a check group. The reference settings include the following:
Threshold values
Method assignments (data collection methods, analysis methods, and auto-reaction methods)
You can either assign the speci ed reference settings at MTE class level, or import them from any monitor of any system. This
means that, for the rst time, the CCMS monitoring infrastructure provides you with a way of centrally customizing threshold
12/20/2019
values and method settings. More information: Checking and Distributing Settings for Selected MTEs and Monitors.
In addition to the automatic distribution of threshold values and method settings, you can have identi ed problems
automatically corrected in various check groups; for more information about this, refer to Troubleshooting and Distributing
Settings of the Consistency Check.
You can call the CCMS consistency check both in dialog and as a job with the check results automatically sent by e-mail.
You can also de ne and save the parts of all of the possible checks that are relevant for you. A selection of this type is called a check
area. This means that you can have only your desired checks performed during the consistency check. More information: Restricting
the CCMS Consistency Check to Speci c Topics.
Performing a CCMS Consistency Check

Use
You can use the Consistency Check of the CCMS Monitoring Infrastructure to check the con guration and runtime of the CCMS
monitoring infrastructure, display errors, and automatically correct these errors.
This procedure describes how you can call the consistency check and what options you have to adjust the details of the check to your
needs.
Since the consistency check is useful both for searching for the cause of a problem that has occurred and a routine function check,
there are two ways in which you can call the check:
You can call and run the check directly in dialog; the result is displayed immediately after the check is performed. This type of
call is particularly useful if errors have occurred in the context of the CCMS monitoring infrastructure and you want to
determine the cause.
You can schedule the check as a job and the result is sent to you as an e-mail. This is particularly useful if you schedule the
speci ed job periodically to obtain a summary of the con guration and runtime of the monitoring infrastructure every week, for
example.
Procedure
To perform a consistency check of your central monitoring, proceed as follows:
1. Start transaction RZ50.
2. If you want to restrict the consistency check to speci c topics, enter an existing Check Area, create a new check area by
choosing . More information: Restricting the CCMS Consistency Check to Speci c Topics.
3. If you also want to check speci c nodes for their method assignments, threshold values, and currentness, specify and existing
MTE Customizing Check Group, or create a new check group by choosing . More information: Checking and Distributing
Settings for Selected MTEs and Monitors.
4. Specify which monitored systems are to be checked. There are a large number of different selection options available here:
You can select systems directly using their system ID by choosing the radio button From System List (ALSYSTEMS),
and specifying the desired system IDs in the relevant input elds.
You can select systems using the system group to which they belong by selecting the radio button From System Group,
and specifying the desired groups in the relevant input elds. More information about system groups: System Groups in
the Alert Monitor.
You can select systems using their additional properties, such as the release or the database type in use, by selecting the
radio button Other Selection Criteria, and specifying the desired properties in the relevant input elds.
12/20/2019
Note
If you do not make any speci cations about the monitored systems that are to be checked, all systems that are registered
with the CCMS monitoring infrastructure as monitored systems are checked (these systems are entered in the table
ALSYSTEMS). You can display these systems in transaction RZ21 by selecting the radio button System Overview in the
Topology group box, and choosing the button (more information: Monitoring Systems in the Topology Display).
5. You can have the results of the check sent to you as an e-mail. To do this, select the Send Result by E-Mail? indicator. More
information: Displaying the Results of the CCMS Consistency Check.
Note
Sending the check results is particularly useful in connection with executing the check in the background (menu
Program Execute in Background . In this way, you can schedule the con guration check as a job to be executed regularly,
and are automatically informed about the result of the check by e-mail.
6. To run the check now, choose the button.
Displaying the Results of the CCMS

Consistency Check
Use
Performing a CCMS Consistency Check describes how you can start the Consistency Check of the CCMS Monitoring Infrastructure.
This section describes the various ways in which you can nd out about the result of the check. There are three options:
You can display the results yourself directly in the CCMS Consistency Check transaction (RZ50). This is primarily useful if you
have started the consistency check manually yourself due to a current problem and require the results immediately.
You can have the results sent to your by e-mail. This is primarily useful if you have scheduled the consistency check regularly as
a job (for example, once daily).
The results are always forwarded as log attributes to the CCMS. You can therefore also display them in the Alert Monitor
(transaction RZ20). Use this property if you have set an alert work ow and the results are therefore available in the form of
alerts in the CCMS monitoring infrastructure.
Procedure
Displaying the Check Result in Transaction RZ50
If you perform a consistency check in transaction RZ50 (more information: Performing a CCMS Consistency Check), the result is
displayed there. The screen has the following structure:
The various check objects are displayed with their status in a tree structure on the left, both for the central monitoring system
(CEN) and for the monitored systems.
The subscreens on the right show a description and the check result of the check object selected in the tree structure.
The check log is displayed in a list at the bottom of the screen. To switch between a global log of the entire check and a log of
the selected check object, choose Object-Speci c / Global Log Display.
12/20/2019
The following functions are also available to you in the display of the check result:
You can switch between the global and local object log display.
For check objects for which it is meaningful and possible, you can use the button to correct the underlying error. More
information: Troubleshooting and Distributing Settings of the Consistency Check.
You can repeat the check. To do this, choose or .
Displaying the Check Result in the Alert Monitor
The results of the CCMS consistency check are also reported in the monitoring infrastructure itself, so that you can use all of the
functions of the alert monitor wth regard to the results, such as assigning auto-reactions, or forwarding alerts to an external alert
management system. For each status in the CCMS consistency check, an alert with the same color is generated. The results of the
check are reported as log attributes, meaning that the results of previous checks are also available to you here.
12/20/2019
The check results are written to a system-wide monitoring context called RZ50 Results; you can, for example, display the results in the
subtree <System-ID> CCMS Selfmonitoring in the CCMS Selfmonitoring monitor of the SAP CCMS Technical Expert Monitors
monitor set.
Displaying the Check Results in an E-Mail
You can de ne in the consistency check that the results are also to be sent to you as an e-mail. This is particularly interesting if you
have scheduled the consistency check regularly as a job (more information: Performing a CCMS Consistency Check). The SAPconnect
infrastructure is used to send the e-mail, so ensure that you have performed the appropriate con guration in CEN.
To send the check results in an e-mail, select the indicator Send Result by E-Mail in the E-Mail Alert group box, and specify the
Distribution List or the Sender Name to which the e-mail is to be sent.
You can also specify which results of the check you want to be informed about in the Alert Threshold input eld:
Short Description of the Alert Threshold Meaning
Green alerts You are informed about all checks irrespective of their outcome.
Yellow alerts You are informed about all check results with the status yellow
(warnings) and red (errors).
Red alerts You are informed about all check results with the status red (error).
Note
12/20/2019
The e-mail contains the information that is displayed in transaction RZ50. However, you can adjust the text of the e-mail to your
needs if you edit the corresponding text modules. The texts belong to the document class Dialog Text. The names of the text
elements follow the naming convention ML_CL_SCSM_<SAPSYS|CENSYS>_<check objcet>. You can therefore display all
documents by specifying, in the document maintenance transaction (transaction SE61), the speci ed Document Class and the
Dialog Text ML_CL_SCSM*. You can identify parameters of which the current value is used in the text during the runtime of the
check by the character string $<Name>$.
More information about adjusting these texts: Modifying SAP Documentation.
Restricting the CCMS Consistency Check to

Speci c Topics
Use
You can adjust the Consistency Check of the CCMS Monitoring Infrastructure to your needs by restricting the check to only the topics
that are relevant for you. To do this, you create a check area in which you specify whether or not individual check objects are to be
performed. You can also specify for the individual check objects whether problems that occur are to be automatically corrected.
However, this function is not useful for all objects, and therefore does not exist for all objects (mroe information: Troubleshooting and
Distributing Settings for the Consistency Check).
Procedure
To create, edit, or delete check areas, start transction RZ52, or, in the Consistency Check (transaction RZ50), choose the button.
Creating a New Check Area
1. Choose the button, and enter the desired name in the relevant input eld.
2. In the Checks tree structure, you can de ne the following points for each check object:
Is the object to be checked during consistency checks for which the corresponding check area is selected? If yes,
activate the Select indicator.
Shoudl the system automatically correct problems that occur for this object in the context of the consistency check? If
yes, activate the Troubleshooting indicator.
Editing a Check Area
1. In the relevant input eld, use the input help to choose the desired check area, and choose the button. Switch to change
mode by choosing the button.
2. De ne the desired properties of the check area, as described in Creating a New Check Area.
Deleting a Check Area
In the relevant input eld, use the input help to choose the desired check area, and choose the button.
Checking and Distributing Settings for

Selected MTEs and Monitors
12/20/2019
Use
You can use the Consistency Check of the CCMS Monitoring Infrastructure to check the general settings and runtime status of the
CCMS monitoring infrastructure. However, you can also de ne reference settings for selected IMTE classes, with which the settings for
the corresponding nodes in the checked systems are compared.
The speci ed reference settings for the MTE classes are in a CCMS customizing check group; a check group of this type is therefore a
container for the following settings for selected MTE classes:
Threshold values
Method assignments (data collection methods, analysis methods, and auto-reaction methods)
Currentness of the nodes (maximum age of the last update)
For each of these three settings, you can specify at MTE class level, whether it is to be part of the consistency check.
Differences are output during the consistency check in the check objects Method Status for Check Groups and MTE Con guration
(more information: Displaying the Results of the CCMS Consistency Check).
In addition to the check, you can also distribute these reference settings to all checked systems. To do this, create a check area by
activating the Troubleshooting indicator for the check objects speci ed above (more information: Troubleshooting and Distributing
Settings of the Consistency Check). You can also transfer the reference settings in the consistency check display, if you have the
relevant check object repaired (more information: Displaying the Results of the CCMS Consistency Check).
Note
The only exception is the currentness of the nodes. You can use this information to check whether the local data collection methods
are still running. For example, if the collector for Oracle Tablespaces is no longer running, this can lead to an error situation not
being identi ed, and in the worst case, the system could hang. There is no automatic repair available for data collection activity.
Procedure
To create or change a CCMS Customizing check group, you need to rst specify which MTE classes are to be contained in the check
group. You can do this in two ways:
You can explicitly specify MTE classes and the settings that you want for them.
This method is particularly useful if you know exactly which settings you want to check or distribute for which MTE classes. This
method also has the advantages that you can use wildcard characters ( *) when specifying the MTE class.
Example
You want to set and distribute threshold values for the available free memory and a central auto-reaction method for all
monitored systems with the database type MaxDB. The desired MTE class is
SDB_space_data_free_mb_pfcl_<System ID>; therefore, to include all nodes regardless of the ID of the monitored
system, enter the MTE class SDB_space_data_free_mb_pfcl_* with the desired settings in the check group.
You can use a rule-based monitor de nition to import MTE classes from this monitor de ntion with their settings. This is
particularly useful if you have already created a corresponding monitor de nition that contains the MTE classes and settings
that are relevant for you.
Note
For information about how to create a rule-based monitor de nition, refer to Creating and Changing Monitors.
Both options are described below.
12/20/2019
Creating a Check Group by Importing a Monitor De nition
1. Start transaction RZ51, and choose the button.
2. A hierarchical list with all monitor sets and associated monitors in CEN appears in the navigation bar on the right. Choose the
desired de nition.
3. Next, select the system from which the settings for the MTE classes of the monitor de nition are to be taken.
Note
At this point, you can also specify a system other than the central monitoring system (CEN), even if the monitor de nition
itself is transferred from CEN. The reason for this is that it is possible that the settings for the desired MTE classes are
missing in CEN, because the relevant nodes do not exist there. If, for example, you want to create a check group for settings
of nodes for monitoring Oracle databases, but CEN has a different database type, select the monitor de nition Database
from the monitor set SAP CCMS Monitor Templates, and choose a monitored system that has an Oracle database.
4. All MTE classes are now displayed in a table with their properties, corresponding to the monitor de nition in the selected
system. Transfer the desired MTE classes to the check group by setting the Apply indicator for the relevant line. To transfer all
MTE classes displayed, choose .
5. Use the indicators for the columns Check Threshold Values, Check Tool Assignments, and Check Data Collection Activity to
de ne which checks are performed for the individual MTE classes.
The Check Threshold Values indicator is only meaningful for performance attributes and is activated by default for
these. In this case, the system checks whether nodes with this MTE class in the checked systems have the threshold
values de ned in the check group. If this is not the case, the discrepancy is displayed in the consistency check and, if you
have set the corresponding check settings, the threshold values from the check group are transferred (more
information: Restricting the CCMS Consistency Check to Speci c Topics).
The Check Tool Assignments indicator is activated by default if method assignments exist in the properties of the MTE
class. While it is not meaningful to change the data collection method, if you have created your own assignments for
analysis and auto-reaction methods in a system, you can compare the settings in all checked systems with these
reference assignments and, with the relevant check settings, transfer the assignments from the check group.
Auto-Reaction Methods - Central Auto-Reaction Methods
The Check Data Collection Activity indicator is not activated by default. It checks whether the nodes for the relevant
MTE class are still provided with values in all checked systems; if this is not the case, a corresponding message is
displayed. If you want to check the data collection activity, specify the maximum time in seconds that is to have passed
since the last update in the Last Update (Seconds) column. If a time is de ned in the corresponding MTE class, as of
which a value is to be regarded as obsolete ( 'Value is obsolete' and set to inactive after...), the system uses twice this
length of time as the default value.
If this time is exceeded, a corresponding message is displayed during the check.
6. De ne the check group to which the properties of the MTE classes are to be assigned by selecting it in the drop-down list box
Assign to Check Group. If you want to create a new check group for this purpose, choose .
Creating a Check Group Manually
Use this procedure if you want to create a new check group manually, or if you want to add a new MTE class and its properties to an
existing check group.
1. Start transaction RZ51, and choose the button.
2. In the Check Group for CCMS input eld, enter the name of the check group to which you want to assign the MTE class and its
properties. You can use the input help for this input eld, if you want to make the assignment to an existing check group.
12/20/2019
3. In the input eld MTE Class, enter the name of the MTE class that you want to assign to the check group. You can use the wild
card character ( *) here.
4. Use the indicators Check Threshold Values, Check Tool Assignments, and Check Data Collection Activity to de ne which
checks are performed for this MTE class.
The Check Threshold Values indicator is only meaningful for performance attributes. In this case, the system checks
whether nodes with this MTE class in the checked systems have the threshold values speci ed in the check group. If this
is not the case, the discrepancy is displayed in the consistency check and, if you have set the corresponding check
settings, the threshold values from the check group are transferred (more information: Restricting the CCMS
Consistency Check to Speci c Topics).
The Check Tool Assignments indicator allows you to check the settings in all checked systems against reference
method assignments. With the relevant check settings, the assignments of the check group for the analysis and auto-
reaction methods are transferrred for the checked nodes.
By selecting the Check Data Collection Activity indicator, you can have the system check whether the nodes for the
relevant MTE class are still provided with values in all checked systems; if this is not the case, a corresponding message
is displayed.
5. Switch to the Threshold Values tab page. If you want to check the threshold values, enter the desired reference threshold values
in the relevant input elds.
6. Switch to the Method Assignment tab page. If you want to have the method assignment checked, enter the reference settings
for the data collection, analysis, and auto-reaction methods in the relevant elds.
7. If you want to check the data collection activity, specify the maximum time in seconds that is to have passed since the last
update in the Last Update (Seconds) input eld. If this time is exceeded, a corresponding message is displayed during the
check.
Result
You have created a check group with reference settings for selected MTE classes. If you sepcify this check group for the consistency
check, the properties for the relevant MTEs in all checked systems are compared with the reference settings and differences are
shown. With the relevant check settings, you can also have the reference threshold values and method assignments distributed to all
checked systems.
Troubleshooting and Distributing Settings of

the Consistency Check
Use
In the context of the Consistency Check of the CCMS Monitoring Infrastructure, you can have problems automatically corrected. If you
have created a check group (more information: Checking and Distributing Settings for Selected MTEs and Monitors), you can also
distribute the reference threshold values and method assignments of the nodes in the check group to all monitored systems. You have
two options for doing this:
You can have the selected check object repaired after the consistency check is performed in transaction RZ50, by choosing
(more information: Displaying the Results of the CCMS Consistency Check).
You can create a check area, in which you have troubleshooting automatically started for selected check objects, as soon as the
consistency check is performed (more information: Restricting the CCMS Consistency Check to Speci c Topics).
Automatic troubleshooting is available for the following check objects:
12/20/2019
Check Object Troubleshooting
CEN Local Checks Status of the Monitoring Segments The segment table is reorganized, that is, inaccessible monitoring
segments, for example, for inactive application servers, are removed
Monitored System Status of the Monitoring Segments
from the segment table.
CEN Local Checks Method Status The nodes that have a method status with an error are reset (more
information: Resetting MTEs and Alerts). This means that values are
Monitored System Method Status
provided for the relevant nodes again, since the data collection
methods are restarted.
CEN Local Checks Method Status for Check Group
Monitored System Method Status for Check Group
Central Jobs Job for Central System Dispatching The central system dispatching job is scheduled (more information:
Activating and Deactivating Method Execution).
Central Jobs Jobs for Collecting CPH Data The jobs required to collect CPH data are scheduled (more
information: Collecting and Reorganizing Performance Values).
Central Jobs Jobs for Managing Monitoring Pauses The jobs for managing monitoring pauses are scheduled (more
information: Managing Monitoring Pauses in the Alert Monitor).
Central Jobs Job for Background Dispatching The background dispatching job is scheduled (more information:
Activating and Deactivating Method Execution).
Agents Agent Status The agent performs a reinitialization of the shared memory area of the
agent (command -initshm).
MTE Con guration Threshold Values The threshold values for the corresponding nodes are set as speci ed
in the check group (more information: Checking and Distributing
Settings for Selected MTEs and Monitors
MTE Con guration Method Assignment The assigned analysis and auto-reaction methods for the
corresponding nodes are set as speci ed in the check group (more
information: Checking and Distributing Settings for Selected MTEs
and Monitors
MTE Con guration Central Auto-Reaction The assigned central auto-reaction methods for the corresponding
nodes are set as speci ed in the check group (more information:
Checking and Distributing Settings for Selected MTEs and Monitors

DB Monitor

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

DB Monitor

Загружено:

Авторское право:

Доступные форматы

12/20/2019

SAP NetWeaver 7.5 | SPS16

Original content: https://help.sap.com/viewer/984899fe989d4efab0409b818433f892/7.5.16/en-US

For more information, please visit the https://help.sap.com/viewer/disclaimer.

All errors generate alerts, which are displayed in a tree structure.

Operating the Alert Monitor

Customizing the Alert Monitor

Concept of the Monitoring Architecture

Monitoring Objects and Attributes

Technical Basics: Data Supplier

The host systems on which your SAP system is running

SAP instances (application servers) and their services and components

Components outside the system

Changing Properties and Method Assignments

Alert Threshold Values and Assignment to Attribute Groups

Alert Colors and their Meanings

red Problem or Error

gray No information available

Monitoring Objects and Attributes

There are ve diﬀerent types of monitoring attributes:

Attribute Type Description

Status Attribute Reports error message texts and alert status

Properties of Log Attributes

Properties of Performance Attributes

Properties of Status Attributes

MTE Classes and Attribute Groups

The following methods exist:

Data Collection Method

· Executing an operating system command

· Executing an auto-reaction in the central monitoring system

Operating the Alert Monitor

1. Start the alert monitor by calling transaction RZ20.

Change Views: Current Status/Open Alerts

Tutorial for the Alert Monitor

The system displays the CCMS Monitor Sets.

4. Check the current status of your system.

a. Display the current system status in your monitor.

b. Check the color indicators in the monitoring tree.

The colors of the nodes in the tree mean the following:

Green: The component is running correctly.

Yellow: The system is issuing a warning.

Red: The system is reporting a problem or a critical state.

Gray: No data is being delivered for the node.

5. Check what has happened recently in the Open Alerts view

Ensure that you are in the Open Alerts view.

1. If the alert is resolved, set it to Complete.

Start and Change Monitors

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

Switch Between Monitors

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

Actions in the Alert Monitoring Tree

Selecting Nodes in the Alert Monitoring Tree

Tutorial for the Alert Monitor

Selecting Nodes in the Alert Monitoring Tree

Selecting MTEs in the Tree

Menu Path Function

Node (MTE) Select the currently selected node

All Nodes (MTE) Select all nodes in the current monitor

Deleting Selection of MTEs in the Tree

Menu Path Function

Display Overview of All Selected MTEs in the Monitoring Tree

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

3. Select the desired MTEs.