What you have to deal with when you work with AppDynamics – or other APM tools

For many years now I have been working with Application Performance Management (APM) tools in the Java realm. Compared to other performance analyzing tools as for example profilers, APM tools are monitoring as well as analyzing tools. They provide a better overview over distributed applications and can offer a direct connection between user actions, users’ performance experiences and technical processes.

From my experience I believe there are some frequent misperceptions about what lies ahead in terms of preparatory work and how to best use an APM tool in order to fully benefit from it. In this blog I want to illustrate these misperceptions as well as the tasks connected with an APM tool.

My experience is foremost with AppDynamics, but also with Dynatrace, monitoring, analyzing and optimizing the performance of Java applications. While both tools use at least in part fundamentally different concepts, their appearance, use and value from the user’s point of view is similar. So while I will be referring to AppDynamics – and using examples from it – for the rest of this article, the issues are valid for Dynatrace and most likely for other APM tools, too.

1. Set up the Infrastructure

In order to work with AppDynamics, you have to install a controller, the central unit that collects, analyzes and displays all data. Depending upon the number of systems you want to monitor and the traffic they generate, you have to size the controller accordingly, i.e. supply sufficiently sized hardware for the controller to fulfill its duties. AppDynamics agents must be deployed on the systems under supervision and all components must be configured to communicate with each other.

As these processes are necessary prerequisites before one can start working with an APM tool, it is obvious that manpower, time and hardware have to be invested to get the new tool up and running.

In the case of AppDynamics, this is all you have to do in order to see this shiny and flashy – and indeed immensely useful – central dashboard, the flow map:

AppDynamics Main Dashboard

Just after installing the APM tool, most of the architecture of your application, often something of a mystery beforehand, lies transparently before your eyes. It seems as if the work is already halfway done. The only thing left to do is…

3. Dashboards and Alarms

The main use case of an APM tool is to monitor the performance of an application. You want comprehensive dashboards that show you at a glance how your application is performing. AppDynamics provides excellent dashboards out of the box which do just this. One example is the dashboard above, just focus on the graphs and tables on the right and bottom sides of the screen which provide the most relevant performance information. Additionally, AppDynamics offers many possibilities to construct custom dashboards according to your own needs and wishes.

AppDynamics also comes with a very useful set of rules to throw events in case of performance issues. Most users will want to fine-tune these and add their own rules to implement a fitting alerting system.

AppDynamics Health Rules

After this it’s easy to think that everything is set and done – the APM tool is up, running and providing all the performance information about the application one needs to know and warns when things are going astray.

Very wrong. Stopping here, means to ignore most of the value an APM tool can provide. In order to unlock the main powers of e.g. AppDynamics, you have to…

2. Define Business Transactions

The numbering, by the way, is no error. This step should be undertaken before you build your custom dashboards and define your alerting rules as you will most likely want to incorporate Business Transactions in your dashboards and alarms.

From my point of view, Business Transactions are the true centerpiece of AppDynamics and probably most APM tools. A Business Transaction is the action of a user of an application, a request against the application, which is traced and tracked as it follows along its winding path, meandering through the systems under surveillance within a distributed application. As result you get an end-to-end performance measurement of the request, listing the Java-systems it went through including the exit points where remote systems and services were contacted.

AppDynamics Snapshot of a Business Transaction

AppDynamics offers Business Transaction detection out of the box, but in many productive distributed applications this out of the box detection will be just a starting point. It is quite normal that one sees too many Business Transactions but at the same time not the right ones that can be connected to user actions. Depending on the architecture, identifying useful Business Transactions and configuring them properly can be some work, sometimes necessitating cooperation from the application users as well as of development. But the result will be an unprecedented insight into the inner mechanics of one’s application – and its connection to the performance experiences of the application users.

Therefore I want to enhance the awareness – of the benefits of Business Transactions as well as of the effort necessary to detect and configure them.

Having defined good Business Transactions is also a prerequisite to make full use of your APM tool in the following tasks:

4. Performance Troubleshooting and Performance Optimization

One of the most important benefits of Business Transactions – and APM tools as a whole – is their support in pinpointing the real causes of performance problems. Without APM, it is rather common that when application users note performance problems with certain of their user actions, the only available option is to guess the causes as one is simply left in the dark. With AppDynamics, if you know the Business Transaction that corresponds to the user action in question, you have a direct handle to the problem. Very often you can drill down straight to the Java method or the call to a remote system (database, web service, etc.) that is the root of the performance troubles.

AppDynamics Waterfall View

AppDynamics Hot Spots

This is a rather technical task. One must know his application and systems quite well and at least some experience with developing Java applications is helpful as well, so providing qualified personnel may not be that easy. But ignoring this area of APM just means to forego one of the biggest profits an APM tool can offer.

To sum it up: By all means, go and use APM! It will give you an enormous insight into your distributed applications, including the connection between the technical side and the user experience. It is probably even more powerful as you have imagined beforehand. But this power comes at a price, as perhaps more time, manpower and resources have to be invested and more tasks have to be accomplished than estimated beforehand. Just be aware of it!