CLM Server Monitoring Rules (DEPRECATED: CLM Server Monitoring is no longer supported and was dropped in version 6.0.3.)

Authors: Boris Kuschel (BorisKuschel), GeraldMitchell
Build basis: Collaborative Lifecycle Management 4.0.6 and higher, CLM Server Monitoring Agent 5.0.1 and higher

Note that the CLM 4.0.x rules are different from the CLM 5.0.x and above rules in structure. The CLM 5.0.x rules capabilities are easier to manipulate and are more robust and are the recommended rules type for CLM 5.0 and higher. The rules behavior resides in the MBeans, and so the behavior is reliant of the CLM version, which is what has the CLM Server Monitoring Plugin installed.

This is not dependent on CLM Server Monitoring Agent version, as CLM Server Monitoring Agent 5.0.1 and above have support for both rules types. Using CLM Server Monitoring 4.0.6 rules in CLM Server Monitoring 5.0.0 will revert CLM Server Monitoring Plugin to CLM Server Monitoring 4.0.6 behavior, and is not recommended.

For CLM 4.0.6 and 4.0.7 rules, see the separate section CLM Server Monitoring rules for CLM 4.0.6.

The example CLM Server Monitoring rules recommendations and examples are currently under development.

CLM Server Monitoring rules 5.0 and higher

The issue rules are defined in an XML document and sent to the server to install into the rules engine. This provides the engine a way to evaluate resources as they are executing. A rule is comprised of the target resource information (type and name) followed by 1..n number of action elements.

The action elements contain the logic which tests or evaluates the resource. See adding/removing rule section

Rule Schema

<?xml version="1.0" encoding="UTF-8" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="ruleSet">
   <xsd:complexType>
      <xsd:sequence>
         <xsd:element name="rule" maxOccurs="unbounded" minOccurs="0">
            <xsd:complexType> 
                   <xsd:sequence>
                     <xsd:element name="action" maxOccurs="unbounded">
                        <xsd:complexType>                             
                           <xsd:choice>
                           <xsd:element name="and" maxOccurs="1" minOccurs="0" type="logicType"/>
                           <xsd:element name="or" maxOccurs="1" minOccurs="0" type="logicType"/>
                           <xsd:element name="not" maxOccurs="1" minOccurs="0" type="logicType"/>
                           <xsd:element name="test" maxOccurs="1" minOccurs="0" type="Test"/>
                        </xsd:choice>
                           <xsd:attribute name="name" use="required" type="xsd:string"/>
                        </xsd:complexType>
                     </xsd:element>
                   </xsd:sequence>
                   <xsd:attribute name="resourceType" type="xsd:string" use="required"/>
                   <xsd:attribute name="resourceName" type="xsd:string" use="optional"/>
                   <xsd:attribute name="id" type="xsd:string" use="optional"/>
            </xsd:complexType>
         </xsd:element>
      </xsd:sequence>
   </xsd:complexType>
</xsd:element>
<xsd:complexType name="Test">
   <xsd:attribute name="operator" type="opTypes" use="required"/>
   <xsd:attribute name="attributePath" type="xsd:string" use="required"/>
   <xsd:attribute name="value" type="xsd:string" use="required"/>
</xsd:complexType>
<xsd:simpleType name="opTypes">
    <xsd:restriction base="xsd:string">
        <xsd:enumeration value="EQ" />
        <xsd:enumeration value="LT" />
        <xsd:enumeration value="GT" />
        <xsd:enumeration value="IN" />
   <xsd:enumeration value="NEQ" />
   <xsd:enumeration value="STARTSWITH" />
   <xsd:enumeration value="CONTAINS" />
    </xsd:restriction>
</xsd:simpleType>
<xsd:complexType name="logicType">
   <xsd:sequence>
      <xsd:element name="not" maxOccurs="unbounded" minOccurs="0" type="logicType"/>
      <xsd:element name="and" maxOccurs="unbounded" minOccurs="0" type="logicType"/>
      <xsd:element name="or" maxOccurs="unbounded" minOccurs="0" type="logicType"/>
      <xsd:element name="test" maxOccurs="unbounded" minOccurs="0" type="Test"/>
   </xsd:sequence>
</xsd:complexType>
</xsd:schema> 

Examples of basic rules

Example simple rule:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ruleSet>
    <rule resourceType="request" resourceName="/scr">
        <action name="problem">
               <test operator="GT" value="10000" attributePath="duration"/>
        </action>
    </rule>
</ruleSet>

Example of "or" condition rule:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ruleSet>
    <rule resourceType="request" resourceName="/scr">
        <action name="problem">
             <or>
                <test operator="EQ" value="someValue" attributePath="someAttribute"/>
                <test operator="GT" value="10000" attributePath="duration"/>
             </or>
        </action>
    </rule> 
</ruleSet> 

Example of "and" condition rule:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ruleSet>
    <rule resourceType="request" resourceName="/scr">
        <action name="problem">
             <and>
                <test operator="EQ" value="someValue" attributePath="someAttribute"/>
                <test operator="GT" value="10000" attributePath="duration"/>
             </and>
        </action>
    </rule> 
</ruleSet> 

Example mixed group condition and ungrouped tests

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ruleSet>
    <rule resourceType="request" resourceName="/scr">
        <action name="problem">
             <or>
                <test operator="EQ" value="someValue" attributePath="someAttribute"/>
                <test operator="GT" value="10000" attributePath="duration"/>
             </or>
             <test operator="EQ" value="foo" attributePath="another.attribute"/>
        </action>
    </rule> 
</ruleSet> 

Example nested conditions:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ruleSet>
    <rule resourceType="service">
        <action name="problem">
            <or>
                <and>
                    <not>
                        <test attributePath="name" value="com.ibm.team.repository.service.diagnostics.database.internal" operator="STARTSWITH"/>
                    </not>
                    <test attributePath="duration" value="10000" operator="GT"/>
                </and>
                <test attributePath="duration" value="70000" operator="GT"/>
            </or>
        </action>
        <action name="javacore">
            <test attributePath="duration" value="100000" operator="GT"/>
        </action>
    </rule>
</ruleSet>

Adding/Removing Rule

There are 2 ways to add/remove rules:

1. Edit the issueRules.xml file - Provisional
2. Use the SmarterServerConfigurationMBean:

• Object Name: type=Monitoring,name=Rules,rulesType=Issue
• Management interface: com.ibm.team.server.monitoring.jmx.beans.ProblemRulesAdminMBean
• Attributes: None

• Operations:

  Name	Parameters	Description
  installRuleSet	String ruleXml, boolean persist	The rule set will be installed and replace the current one is it exists. The persist parameter is used to write to the issueRules.xml file
  listRules	String	List of rules running in server

CLM 5.0 and higher example rulesets for jazz Applications

Attached to this page are example rule sets for specific CLM applications, created in CLM 5.0. These are provided in order to give realistic examples of what a finished ruleset might look like for each of these CLM applications.

Represented are Jazz Team Server, Rational Team Concert (CCM ), Rational Quality Manager (QM), and Rational DOORS Next Generation (RM). Each of the application rule sets are different, and may list specific services that that are unique to the specific application.

Notices for example rules

These rules were created for the CLM team internal systems, and are likely not applicable to your specific system. These are provided only as an example of a larger rule set against the supported applications in CLM 5.0.1.

Running these rules may adversely affect your system and are not recommended. Do not use these rules on production, or any other stage other than experimentation.

These rules do contain javacore actions that may disrupt your system. It is possible with the rules to be put into a state where the CLM host stops responding due to an overwhelming abundance of javacore requests.

Rule example - build request monitoring in RTC

One instance of many where the examples might diverge from your system is the specific RTC application rules. Example of BuildRequestLookupService BuildAgentLoopTask activity monitoring in RTC XML

<rule resourceName="com.ibm.rational.buildforge.buildagent.internal.service.BuildRequestLookupService.lookupBuildRequestAndRun" resourceType="service">
        <action name="problem">
            <and>
                <test attributePath="duration" value="20000" operator="GT"/>
                <test attributePath="activity.name" value="com.ibm.rational.buildforge.buildagent.BuildAgentLoopTask" operator="EQ"/>
            </and>
        </action>
        <action name="javacore">
            <and>
                <test attributePath="duration" value="100000" operator="GT"/>
                <test attributePath="activity.name" value="com.ibm.rational.buildforge.buildagent.BuildAgentLoopTask" operator="EQ"/>
            </and>
        </action>
    </rule>

Whereas we are using Rational Build Forge for our example, you may be using a different Build infrastructure. Note that this specific rule takes action to create problem record if two tests pass on evaluating a service identified by resource name; the first a duration longer than 20 seconds and the second that the activity (identified through the activity name) be a specific Task. The rule also says to create a javacore if the Task activity takes longer than 100 seconds.

Related topics: None

External links:

• None

Additional contributors: None