Elements of the CCMS Monitoring
Infrastructure
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
element of the alert monitoring tree: monitoring summary nodes, monitoring
objects, and monitoring attributes (see also
Elements of the Alert
Monitoring Tree.
Monitoring summary nodes (summary MTEs) provide a better overview in the tree, without performing a monitoring function themselves. They act as titles or headings in the Alert Monitor. No alerts can be triggered for summary MTEs. Alert statuses and alert messages can, however, be displayed, since these are propagated upward in the alert monitoring tree. There are two kinds of monitoring summary node:
● Real monitoring summary nodes (summary nodes)
These nodes are stored in the monitoring segment and have been created by the data supplier to improve clarity. You can identify summary nodes in the alert monitoring tree by the fact that they are the only nodes without an icon after the node name.
●
Virtual monitoring
summary nodes (
)
These nodes are not stored in the monitoring segment, but exist only to provide a clearer display of real MTEs in a monitor Virtual nodes are created in the monitor definition.
Monitoring objects
are particular components of your systems that the monitoring architecture
monitors (such as SpaceManagement or CPU). Like the summary nodes, they are
created by the data suppliers. The objects combine various monitoring
attributes that belong to the same component or the same attribute of the SAP
system. They are identified in the alert monitoring tree by the icon
.
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, among others. A data supplier reports data for these attributes, and the alert monitor triggers alerts for the attributes if the data violates the defined alert thresholds.
There are various types of monitoring attributes:
attribute type |
Description |
|
Collects reported performance values and calculates the average; a performance attribute contains a numerical value for a performance parameter. |
|
Reports error message texts and alert statuses; a status attribute contains individual messages (such as individual status, warning, and error messages) |
|
If your component might output multiple related messages, you can use a log attribute instead of a status attribute to report the messages to the Alert Monitor. The log attribute presents the messages as a log. This means that the user can see the messages in context. Use a log attribute to implement a log or trace for your component. The monitoring architecture provides the log function. You only need to report your messages to the log attribute.
Log 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. |
|
Allows a data supplier to report information that does not have an alert value; the text can be updated if required; use text attributes for text information for a monitoring object that is seldom changed (such as an ID). |
Summary MTEs and
monitoring objects do not contain any information about the status of the
monitored system themselves; they structure the alert monitoring tree. The
monitoring objects form the last level of the hierarchy above the monitoring
attributes. The attributes represent the end of the branches of a monitoring
tree and contain the actual data. Summary nodes are above the monitoring
objects in the monitoring tree, and can form any number of hierarchy levels
(see also
Alert Monitoring
Tree):

You can assign
methods to
monitoring attributes, and use transaction RZ21 of the alert monitor to access
the method definitions. 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 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.
The following methods exist:
● Data Collection Methods
These methods allow the collection of information about the SAP system and its environment that is then reported to the monitoring architecture. The method starts automatically or is automatically started by the Alert Monitor at specified time intervals.
● Auto-Reaction Methods
These methods
start automatically when an alert is triggered. There are multiple predefined
auto-reaction methods in the monitoring architecture, which you can assign to
MTE classes (see also
Selected Methods of
the Alert Monitor):
○ Sending an e-mail
○ Executing an operating system command
○ Executing an auto-reaction in the central monitoring system
● Analysis Method
This method allows an analysis of error situations without leaving the Alert Monitor. You start an analysis method manually. 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.

The following methods are assigned to the MTE class R3UsersLoggedIn (and therefore to all corresponding attribute nodes of all instances):
● Data collection method CCMS_User_Collect; this regularly collects the number of users logged on
● Analysis method CCMS_User_Analyse; this shows the number of users currently logged on if there is a problem
The alert
monitoring tree consists of individual MTEs. These MTEs are assigned to
MTE classes and
attribute groups in the monitoring infrastructure:
● An MTE class describes the general properties (such as assigned help texts) and method assignments that are common to a particular group of MTEs.
● An attribute group describes the specific properties that are shared for a particular attribute type, such as threshold values for alerts in the case of performance attributes.

The attribute group R3DialogResponseTime defines that a yellow alert is to be displayed if the average response time exceeds two seconds. A red alert is displayed if the average response time exceeds three seconds.
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.

Assign a separate MTE class to each type of monitoring object or attribute.
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 (see also
Creating and Changing
Monitors).

You can easily define a monitor that displays the number of users logged on for all systems in the landscape. This monitor selects all nodes of the MTE class R3UsersLoggedIn for all registered systems.
Start
Page Creating
a Data Supplier for the CCMS Alert Monitor
