Hallett_German

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

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

Last month we discussed the APM transaction application definition lifecycle as an approach that can be used to create, monitor, and maintain transaction definitions.

This month discusses the five implications of this lifecycle:

1) Seen as an ongoing process rather than a one-time event
The result is that APM transaction definition activities can be proactively scheduled and resourced. It can also be included in the application monitoring roadmap and strategy. This is less likely to happen if viewed as a one-time event.

2) Ties in well with Application Lifecycle Management (ALM)
Transaction definition and monitoring activities has a corresponding ALM event. The result is that APM monitoring is an active part of the application creation, test, deployment, and maintenance lifecycle. So, having constant and consistent visibility into application performance and customer experience reaps the benefit of a higher quality and better performing application.

3)Helpful for Time Tracking and Hiring Resources
The approach can be used to track the time of each phase and hire APM administrators for just one or two phases. This allows one to see 1) if more hours need to be spent on a particular step. 2) The relationship between hours spent on creating, maintaining, and optimizing definitions and the number of false positive or missed defects/alerts. Few hours spent maintaining definitions may lead to outdated and invalid definitions plus false positives.

4) Can easily incorporate reporting as part of the lifecycle.
Reports can be used as a validation tool to determine, false positives, under and over counts, overlapping definitions and more. This works well with the monitor, optimize, and maintain phases.

5) The phases also correspond nicely with setup/configuration issues.
Each transaction definition lifecycle activity has a related set of things that could happen to hinder completion. One may be unable to record because of bad private keys or bad network traffic. A definition may not work because of missing a request header or the content type used. An application may be hard to optimize if there are few parameters that are unique. Knowing what can go wrong in each phase will make it easier to resolve

The lifecycle will continued to be reviewed in forthcoming articles particularly the maintenance and optimization stages.


Questions for discussion:
1) Do you use reporting as a transaction definition validation tool? What are some of the techniques that you use?
2) What are some of the issues that you face in each face that hinder your completion?
3) How well do you tie the ALM approach with APM?

Outcomes