IBM Tivoli Composite Application Manager for Transactions, Version 7.4.0.0

Aggregating Transaction Tracking nodes by using reporting and filtering

You can use filtering in the Application Management Configuration Editor to exclude nodes that you are not interested in, or reporting to combine transactions or applications so that they are displayed as a single node in the Tivoli Enterprise Portal. Filtering is useful in large, complex monitored environments where you may have many spurious transactions in which you are not interested.

ITCAM for Transactions V7.2 and later enables you to exclude nodes using filters for any components from the Application Management Configuration Editor. This includes nodes from ITCAM for Application Diagnostics, WebSphere MQ, and so on. See Using filters for further information.

To apply filtering and reporting rules, you complete the following steps:

Decide which aggregates to filter or rename
Define filtering and reporting rules

Determining which aggregates to filter or rename

First, discover your enterprise using Transaction Tracking, and in the ITCAM for Transactions tables in the Tivoli Enterprise Portal, examine the aggregates that have been discovered.

Tip: Export tables to .csv files so that you can examine and manipulate lists of aggregates more easily. Using csv files enables you to find patterns in the data.

You can then filter any aggregates you choose by manipulating that data. Listed below are some of the common aggregates that you may want to filter for particular applications:

IBM HTTP Server and other web servers
Static pages generally do not involve complex processing, so do not need to be monitored. Either filter these files out entirely or combine them into a single node.

Examples - *.html, *.htm, *.xml, *.dtd, *.png, *.jpg, *.gif, *.css, *.es, *.js, *.txt, *.ico, *.htc, *.grxml, *.ulaw, *.wav. For example, set http://www.mywebsite.com/*.jpg

Combine any URLs with the same base address but differing query strings into one aggregate by configuring the ARM data collector to drop the query string part of the URL. For example, use http://www.mywebsite.com/search.jsp instead of http://www.mywebsite.com/search.jsp?sessionId=2132135.
WebSphere Application Server, Java EE, .NET and so on
- Resources with similar names - It is not unusual for applications to use a naming scheme with a common prefix, which groups related resources. You can group these resources together. For example, you may wish to group all URLs of a particular application together and name them by their application.
  Example:Map all travel related URLs to Travel Transactions.
  
  Apply the filter TransactionName=”/web/travel/*” and rename the node to a static string such as Travel Transactions.
- Trivial pages - Application servers can also have static pages which do not need to be monitored. Either filter these files out entirely or combine them into a single node.
WebSphere MQ and WebSphere Message Broker -
- System queues and non-targeted queues
  MQ Tracking uses its own filtering mechanism. System queues and non-targeted queues are filtered out by default.
- Dynamic queues
  Rename dynamic queues to a name which describes their function.
  
  Dynamic queues have a dynamically generated name based on a pattern specified by the user. To filter these queues, use the pattern as the filter value with an asterisk (*) as a wildcard for filtering. Specify the same pattern in the reporting rule value, so that the aggregates are collapsed down to CREDIT.REPLY.* for example.
CICS and IMS
Naming conventions in CICS and IMS are application-specific, so appropriate filtering is also client application-specific. However, transaction names typically follow a naming convention where transactions sharing a common prefix are part of a common application. For example, all Payroll transactions might start with P. To annotate the transactions displayed in Transaction Tracking, apply the filter TransactionName=”P*”. To annotate the transaction name with the application name, in the reporting rules, set TransactionName=”Payroll ($TransactionName$)”.

CICS Tracking uses its own filtering mechanism. System queues and non-targeted queues are filtered out by default.

Configuring filtering and reporting rules

After you have determined which nodes you want to combine or remove, set filtering and reporting rules in the Application Management Configuration Editor.

To group nodes together, add transaction definitions in the Application Management Configuration Editor for groups of transactions that you want to aggregate, apply a suitable filter and set the required reporting rules.

See Using filters for more information.

Remember the following points:

All data has a type, such as ARM, MQ, MB, and a rule is applied to data only of the specified type
A rule has two parts, filtering and reporting:
- Filtering determines whether a rule applies to an aggregate. The rule applies to an aggregate if all Include filters match the values of an aggregate and it does not match any Exclude filters.
- Reporting affects aggregates accepted by the filter. Use reporting to modify the values that the aggregate is reported under and change the names of transactions. Default rules take precedence over additional rules.
  Tip: Copy the include patterns from the default rule, then modify them as required.

Example: grouping applications

An environment has a remote Transaction Collector and monitors IBM HTTP Server and Rational Performance Tester agent, creating about 30 applications and 500 transactions. Hundreds of applications are listed in the Tivoli Enterprise Portal navigator under Application Management Console > Applications, making the reported information difficult to understand.

Logically these applications can be grouped into five business applications each with a unique context URI making the reported information much easier to understand.

To group the applications:

In the Applications section of the Application Management Configuration Editor, create a transaction definition for the first IBM HTTP Server business application.
Apply a filter that matches the business application. For example, one of the following:
- http://www.hostname.com/contextroot/path/morepath/filename*
- http://www.hostname.com/contextroot/path/morepath/application1*
- http://www.hostname.com/contextroot/path/morepath/application2*
- http://www.hostname.com/contextroot/path/morepath/application3*
- http://www.hostname.com/contextroot/path/morepath/application4*
Tip: You may want to create an alias for an application that has an long name. For example, to create an alias for a single URL, specify the exact URL for the ApplicationName on the Filter tab. Do not include wildcards.
Change the ApplicationName on the Reporting tab to a meaningful, fixed value name that helps you understand the information reported. For example, Filename, Application1, Application2, and so on.
Repeat steps 1 to 3 for the remaining four IBM HTTP Server business applications, and the five Rational Performance Tester business applications.
If there are IBM HTTP Server requests from ITCAM for Application Diagnostics or MQ that are not already covered by the new transaction definitions for IBM HTTP Server, you can optionally create another transaction definition called OtherIHS. Set a filter to include all other transactions, and set the reporting of the ApplicationName to OtherIHS.
Apply the new transaction to a profile:
1. Select Profiles, and in the Profiles list, either select Transaction Tracking > Default to use the default profile or create a new profile.
2. The Transactions tab lists all active transactions (reporting and filtering rules) associated with the profile. On the Transactions tab, select the newly created transaction and click Add.

Example: grouping MQ dynamic queues

Add a new profile for WebSphere MQ Transaction Tracking, which combines MQ dynamic queues into a single node by changing the Transaction name from a variable to a static name, Merge Dynamic Queues:

Create a new transaction with the Transaction name Merge Dynamic Queues:
On the Filter tab, add a filter to include data with any server name, component name, and application name, and set this profile to only include aggregates with a transaction name prefixed by Dynamic by using a wildcard. That is, specify Dynamic* in the Value field:
On the Reporting tab, specify the static value Merge Dynamic Queues instead of a variable in the Transaction Name field:
Set this transaction as the default for Transaction Tracking on WebSphere MQ:
1. Go to Profiles.
2. On the Transactions tab, select WebSphere MQ in the list.
3. Click Add to display the Transaction Selection dialog box.
4. Expand WebSphere MQ and select the new transaction.
5. Click OK.
The combined aggregates are displayed in the Transaction Aggregate Topology and Transaction Instance Topology workspaces as a single node, Merge Dynamic Queues. Further information about the aggregated node is displayed in the Contexts table.

Last updated: September 2014