The monitor-configuration.xml (SAP Library

The monitor-configuration.xml

Definition

The monitor-configuration.xml files provided by the monitored resources are the source used by the monitoring framework for the creation of new monitors, objects and summaries.

Each XML file consists of two parts – monitor semantics and monitor tree.

Structure

Monitor Semantics

This part is contained in the element <monitor-semantics>. It describes the semantics of the installed monitors, objects and summaries. Each node that appears in the monitoring tree has to have a configuration group element in this semantics part. The objects and the summaries are described by <simple-configuration-group> elements while each of the monitors has to be described by a configuration group corresponding to its type. For example, <text-configuration-group> - for text monitors, <integer-configuration-group> - for integer monitors, and so on.

In the configuration groups you provide information such as: a description of the node, type of data collection (pushed by resource or polled by the monitor), reaction on failure (keep the monitor when a failure in retrieving the data has occurred, or uninstall it), and so on.

Some monitors are qualified as performance monitors. Thresholds that represent certain barriers of performance quality can be configured for them. These thresholds are used when visualizing the tree to bring the system administrator’s attention to certain problems in the performance. Green, yellow and red colors are used to denote good performance, warning and error states of the monitors. The warning, and error colors are propagated up to the root of the tree so that a certain problem is noticeable even before you expand the tree.

When you configure the thresholds, four values are expected. They identify the transitions “green-to-yellow”, “yellow-to-red”, “red-to-yellow”, and “yellow-to-green”. In the simple case, you can configure the pairs “green-to-yellow” – “yellow-to-green” and “yellow-to-red”-“red-to-yellow” to have the same values. But if you want to prevent the color from changing frequently when the value of the monitor fluctuates around the threshold value, you may set different values for the counterpart thresholds.

In some cases, a “green” value is associated with large numbers (for instance, the money in your bank account) and in others the “green” value can represent small numbers (for example, when the monitor shows the number of escalations you have had to deal with during the week). In both situations you only have to provide adequate numbers for the thresholds. The monitoring framework is then responsible for defining the direction in which colors change from green to red.

The reason for describing the configuration groups in a separate part of the XML is that they can be reused; that is, some monitors in the monitoring tree can share a common configuration group. This is very useful for monitors that describe objects of one and the same type and for dynamically installed monitors.

Monitor Tree

The second part of the monitor-configuration.xml is contained in the element <monitor-tree>. It describes all nodes that have to appear in the monitoring tree. Each node that is described is put in an element describing its parent in the tree. Thus, the <monitor-tree> element actually describes whole sub-trees in the monitoring tree.

The example below presents a sample object and its monitors (an integer monitor and two long monitors) that are described to appear under the <services>summary node in the monitoring tree:

<monitor-tree>

<integer-monitor name="ExportedRemoteObjectsCount" configuration-group="P4.ExportedRemoteObjectsCount">

<monitored-resource name="p4" type="SERVICE"/>

<integer-attribute-mapping>

<integer-attribute>

<observed-resource-attribute name="ExportedRemoteObjectsCount"/>

</integer-attribute>

</integer-attribute-mapping>

</integer-monitor>

<long-monitor name="RequestsCount" configuration-group="P4.RequestsCount">

<monitored-resource name="p4" type="SERVICE"/>

<long-attribute-mapping>

<long-attribute>

<observed-resource-attribute name="RequestCount"/>

</long-attribute>

</long-attribute-mapping>

</long-monitor>

<long-monitor name="FailedRequestsCount" configuration-group="P4.ErrorRequestCount">

<monitored-resource name="p4" type="SERVICE"/>

<long-attribute-mapping>

<long-attribute>

<observed-resource-attribute name="ErrorRequestCount"/>

</long-attribute>

</long-attribute-mapping>

</long-monitor>

</object>

</services>

</monitor-tree>

A monitored resource is described for each monitor. The monitored resource is the resource MBean registered by the resource. One option is to give the full ObjectName of the MBean. This, however, can often cause errors and sometimes the developer of the resource does not know the exact name, under which the resource MBean is registered (if convenience methods from the JMX library are used). Thus, in addition to the type MBEAN, the monitoring framework recognizes three more types of monitored resources (or resource MBeans): MANAGER (for kernel resources), SERVICE, and APPLICATION. When some of these types are used, the resource provider has to give only a simple descriptive name for the monitored resource. The monitoring framework knows which convenience methods from the JMX library it has to use to generate the ObjectName of the described resource MBean. The same convenience methods have to be used by the resource when registering the resource MBean.

In addition to the name of the resource MBean, the resource provider has to describe the attribute mapping between the monitor and the attributes or methods of the resource MBeans. In this way the monitor knows which attribute to check, which method to invoke, or which JMX notification to listen for when updating its value.

For a description of the DTD defining the monitor-configuration.xml files, see monitor-configuration.dtd.