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 of Log Attributes
Properties of Performance Attributes
Properties of Status Attributes
· 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.
Structure
The general properties are as follows:
| Property | Description |
| Message Class and | 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.
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 kept is 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 first … | 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) |
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 define 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.
No comments:
Post a Comment