CLM Server Monitoring Rules 4.0.6 and 4.0.7 (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 4.0.7, 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.

These rules are not recommended for monitoring CLM 5.0.0 and higher. Please use the XML format rules instead.

CLM Server Monitoring 4.0.6 Rules

CLM Server Monitoring needed a robust way to identify performance issues and in CLM 4.0.6 problem detection rules were put into place. The rules are properties-based, and are stored in the same smarterserver.properties file as all other properties. See the Adding or removing rules section.

CLM Server Monitoring 4.0.6 Rules - Syntax

[context/namspace].[groupName: optional].[resource type].[attribute].[operator]=[value]

context/namespace - To avoid collisions in the future, with other possible rule types, this namespace uniquely identifies the rule type.
groupName - The name of the group this rule belongs to.
resouceType - The type of resource to test. There are a few in the system. Some examples are Request,Service,Http_Client_Request,Cache,etc...
attribute - The name of the attribute to test.
operator - Equality and relational operator. The only possible values are <, >, and =

A few basic rules about this syntax:

1. Any rule missing a group name will be grouped into the DEFAULT group
2. A rule group rules together using the logical AND operator. This means all rules must evaluate to true
3. When evaluating multiple groups, they are bound together using the logical OR operator. This means only one set of the groups has to evaluate to true in order to have the compound statement to evaluate to true
4. The monitor already has a built in duration for the resource. This rule is always included as a rule in the default group. Using a rule such as the following does not make much sense, but is acceptable:

problem.service.duration.gt=10000

The threshold on the monitor should be used.

CLM Server Monitoring 4.0.6 Rules - Rule groups

Rules can be grouped together in a logical "AND" ordering. This means all rules in the group must evaluate to true for the group to return a true evaluation result. The use of groups now allows you to evaluate items with different conditions and allows users to gain a more finer grain control over problem detection. All that is needed in addition to the simple syntax is a group name.

An example to set the threshold for a specific service (FooService):

problem.mygroup.service.duration.gt=20000
problem.mygroup.service.servicename.eq=FooService

This rule states that a problem will be flagged on a service named FooService if the duration of the call took > 20000ms. This now supercedes the default threshold defined by the monitor. Even if the monitor has an overall threshold of say 10000ms, it will not apply here.

CLM Server Monitoring 4.0.6 Rules - Adding or removing rules

There are two ways to add or remove rules:

1. Edit the smarterserver.properties
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
  addRule	String key, String value, boolean persist	This rule will be dynamicall installed and effective immediately
  removeRule	String key	Removes a rule if it exists
  listRules	String	List of rules running in server

CLM Server Monitoring 4.0.6 Rules - Multivalue rules

Sometimes there might be multiple values that are valid for a particular attribute. Using the service resource as an example, a problem may want to be flagged on both FooService and BarService if its duration > 30000ms. A few properties can be defined as follows:

problem.mygroup.service.duration.gt=30000
problem.mygroup.service.servicename.eq=FooService,BarService

The value for the attribute key must be a comma separated string. Under the covers, the service name gets grouped into an or expression, overall an and expression is used to group the duration + the or expression for the service name.

CLM Server Monitoring 4.0.6 Rules - Rule Actions

Sometimes an action must be taken when certain conditions are met. The problem rule vocabulary has been expanded to accommodate this. It is used in conjunction with an attribute value test.

Take for example a test on a request duration for > 2000ms:

problem.group1.request.duration.gt=2000

This makes any request that takes longer than 2000ms a problem. It may be desirable to perform an action when the duration is say > 10000ms. To do this the original duration test must be extended. Using the example above, the new rule definition will look like:

problem.group1.request.duration.gt=2000;action.gt=10000:__<some action>__

This says "flag the request as a problem if it exceeds a 2000ms threshold." Additionally take when the duration has exceeded a 10000ms threshold.

The number actions available is limited. Currently, there are only 2 actions available:

• heap - Performs a Java heap dump
• core - Performs a core dump
• javacore - Performs a Java core dump

If I wanted to force a core dump when a request exceeds 10000ms, I could write the following rule:

problem.group1.request.duration.gt=2000;action.gt=10000:core

CLM Server Monitoring 4.0.6 Rules Examples

Jazz Team Server (jts) Rules 4.0.6

#Defaults
problem.service.duration.gt=4000;action.gt=10000:javacore
problem.db_statement.duration.gt=4000;action.gt=10000:javacore
problem.request.duration.gt=4000;action.gt=10000:javacore
problem.http_client.duration.gt=4000;action.gt=10000:javacore

# Contributor Sync takes 5 second on a regular basis
problem.group1.service.name.eq=com.ibm.team.repository.service.jts.contributor.internal.ContributorRecordUpdateRestService.service
problem.group1.service.duration.gt=10000
problem.group2.request.name.eq=/contributorRecords/
problem.group2.request.duration.gt=10000

Change and Configuration Management (ccm) Rules 4.0.6

#Defaults
problem.service.duration.gt=4000;action.gt=10000:javacore
problem.db_statement.duration.gt=4000;action.gt=10000:javacore
problem.request.duration.gt=4000;action.gt=10000:javacore
problem.http_client.duration.gt=4000;action.gt=10000:javacore

# Contributor Sync takes 5 second on a regular basis, raise threshold to 10 seconds
problem.group1.http_client_request.name.eq=https://csmserver:9444/jts/contributorRecords/
problem.group1.http_client_request.duration.gt=10000
problem.group2.service.name.eq=com.ibm.team.repository.service.compatibility.contributor.internal.CompatContributorService.performSynchronization
problem.group2.service.duration.gt=10000
problem.group3.service.name.eq=com.ibm.team.repository.service.compatibility.util.http.CrossServerHttpClientService.send
problem.group3.service.duration.gt=10000

Related topics: None

External links:

• None

Additional contributors: None