CA Tuesday Tip-: APM Transaction Definition Lifecycle : Part 1

Discussion created by Hallett_German Employee on Mar 31, 2012
Latest reply on Apr 3, 2012 by MaryGreening
CA Wily Tuesday Tip by Hallett German, Sr. Support Engineer for 4/3/2012

APM Transaction Definition Monitoring is typically presented as a series of discrete steps resulting in a monitored transaction. This approach fails to address the following:

1) How to maintain transaction definitions in a fast changing environment.
2) How to optimize transaction definitions.
3) That transaction definition is an ongoing not one-time process.

This article proposes that a different approach is needed in the real-world for applications which continue to be updated. Instead of a series of steps, see it as a repetitive circular process -- a lifecycle.

The lifecycle consists of five steps:
1) Record a Transaction Signature -- Previously we talked about the many different ways that one can create a transaction signature. It is important to make sure that we have captured the steps that uniquely define that transaction and do not have any overlapping definitions.

2) Define a Transaction -- This includes setting up the transaction matching rules, cleaning up definitions and consolidating/splitting off definitions. Take the time here to get the definition correct to eliminate false positives.

3) Monitor -- Set up the defect thresholds, promote, monitor the transaction,and look at the defects/reports/and statistics produced. For many customers, this is when the process ends.

4) Optimize
Clean up your definition for 1) creating false positives, 2) including old or unneeded components, 3) handling all appropriate environments and users (internet and intranet for example).

5) Maintain
Your transaction definition must be actively maintained so it continues to uniquely identify a transaction regardless of the application release. Curiously, it is not publically documented which changes in the application would require corresponding changes in the transaction definition. (I have created such a list that may be published in a future article.)

These five steps may be repeated as many times as needed. I would recommend no less than once a quarter.

In the next few months, we will talk about the implications of the lifecycle and more on optimization and maintenance.

Questions for discussion:
1) How often do your applications change? Do these require frequent transaction definition revisions?
2) How much time does you or your company spend the optimization/maintenance phase?
3) How do you manage this lifecycle for multiple applications simultaneously?