Welcome!

Oracle Developer Articles and Techniques

Debu Panda

Subscribe to Debu Panda: eMailAlertsEmail Alerts
Get Debu Panda via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


I spoke to a few customers last week about Application Performance Management (APM) and many of them are still confused about the different functionalities offered by APM products, such as transaction tracing and deep-dive monitoring. I will use screens shots from BMC Application Diagnostics as illustrations.

 

Most of today’s applications are multi-tiered and involve a multitude of systems such as application servers, databases, messaging systems or external web services.  Consider the following example of a transaction where a user bids for a product offered in an auction site.  This is based on the ActionBazaar application as depicted in my book EJB 3 in Action.

 

image001.jpg

 

(Source: EJB 3 in Action, Manning, April 2007)

 

A transaction may involve multiple application (JVM or CLR) tiers.  However, there are several applications where you have a single application tier (e.g. Java /.NET) accessing a relational database. A transaction trace is a complete log of information that depicts the interaction between application systems involved in the complete transaction.

 

Often a transaction trace provides enough data about an instance of a transaction to diagnose a latent or failed transaction. For example, a user named Bob came to ActionBazaar.com and tried to make a Bid for an old Car, but he got an obscure error (NullPointerException).  A transaction trace captured for that transaction will help application support diagnose this issue.  Hence transaction tracing is a capability to isolate transaction issues by capturing a detailed record for the transaction when a problem occurred.

 

Interestingly some APM products often refer only to cross-tier or multitier tracing capabilities as transaction tracing.  Here is an example of a transaction trace that involves multiple tiers.  We can see that the transaction trace has sufficient information about the transaction to identify the problem by showing the transaction flow (or path) for Place Bid transaction and time spent in each node.

 

image002.png

Note that some people refer the automatic discovery of transaction paths as run-time application discovery.

 

A graphical view of transaction traces helps application operation personnel identify the culprit-tier e.g. JBoss 2 VM in the above example.

 

However, application support personnel will need to further drill down to determine why a specific node is generating an error or is slow.

A transaction trace may optionally include deep-dive monitoring data for that tier to indicate why the specific node/tier is slow. It may include data such as application server metrics, the code execution path, or parameters that may help application support personnel to diagnose the issue and help fix it.

 

The following graph illustrates transaction tracing vs. deep-dive monitoring.

image004.png

The following figure shows an example of deep-dive monitoring data.  The first view suggests that the PlaceBidService running on the JBoss2 server is causing the latency issue. It also shows some top application server metrics and how these compare with baselines.  These metrics help pinpoint issues with the underlying application infrastructure.

 

image006.png

 

As you can see, it also shows how various kinds of technology frameworks contribute to the latency of PlaceBidService.

The transaction trace may also break down the time spent in DB (SQL calls), as shown below, in order to help application support personnel determine whether certain DB calls are slowing down the transaction.

 

image008.png

 

If the application support personnel understand the application code, they can drill down further to look at the method execution tree as shown below.

 

image010.png


Many products such as BMC Application Diagnostics include code level deep-dive data in the transaction trace. However some APM products require different agents to collect deep-dive data vs transaction traces, and you may have to manually correlate the transaction trace with deep-dive information.

 

I hope this provides a good background into how transaction tracing and deep-dive monitoring are related.

Read the original blog entry...

More Stories By Debu Panda

Debu Panda is a Director of Product Management at Oracle Corporation. He is lead author of the EJB 3 in Action (Manning Publications) and Middleware Management (Packt). He has more than 20 years of experience in the IT industry and has published numerous articles on enterprise Java technologies and has presented at many conferences. Debu maintains an active blog on enterprise Java at http://debupanda.blogspot.com.