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.
(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.
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.
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.
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.
If the application support personnel understand the application code, they can drill down further to look at the method execution tree as shown below.
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.