Application Performance Monitoring in production – A Step-by-Step Guide – Part 1
Setting up Application Performance Monitoring is a big task, but like everything else it can be broken down into simple steps. You have to know what you want to achieve and subsequently where to start. So let’s start at the beginning and take a top-down approach
Know what you want
The first thing to do is to be clear of what we want when monitoring the application. Let’s face it: we “do not want to” ensure CPU utilization to be below 90 percent or a network latency of under one millisecond. We are also not really interested in garbage collection activity or whether the database connection pool is utilized. We need to monitor all of these things in order to reach our main goal. And the main goal for this article series is to ensure the health and stability of our application and business services. To ensure that we need to leverage all of the mentioned metrics.
What does health and stability of the application mean though? A healthy and stable application performs its function without errors and delivers accurate results within a predefined satisfactory time frame. In technical terms this means low response time and/or high throughput and low to not existing error rate. If we monitor and ensure this than the health and stability of the application is likewise guaranteed.
Define your KPIs
At first we need to define what satisfactory performance means. In case of an end-user facing application things like first impression and page load time are good KPIs. The good thing is that satisfactory is relatively simple as the user will tolerate up to 3-4 seconds but will get frustrated after that. Other interactions, like a credit card payment or a search have very different thresholds though and you need to define them. In addition to response time you also need to define how many concurrent users you want, or need, to be able to serve without impacting the overall response time. These two KPIs, response time and concurrent users, will get you very far if you apply them on a granular enough level.
If we are talking about a transaction oriented application your main KPI will be throughput. The desired throughput will depend on the transaction type. Most likely you will have a time window in which you have to process a certain known number of transactions, which dictates what satisfactory performance means to you.
Resource and Hardware usage can be considered secondary KPIs. As long as the primary KPI is not met, we will not look too closely at the secondary one. On the other hand, as soon as the primary is met optimizations must always be towards improving this secondary KPI.
If we take a strict top-down approach and measure end-to-end we will not need more detailed KPIs for response time or throughput. We of course need to measure more detailed than that in order to ensure performance.
Know what, where and how to measure
In addition to specifying a KPI for e.g. the response time of the search feature we also need to define where we measure it.
This picture shows several different places where we can measure the response time of our application. In order to have objective and comparable measurements we need to define where we measure it. This needs to be communicated to all involved parties. This way you ensure that everybody talks about the same thing. In general the closer you come to the end user the close it gets to the real world and also the harder it is to measure.
We also need to define how we measure. If we measure the average we will need to define how that is calculated. Averages themselves are alright if you talk about throughput, but very inaccurate for response time. The average tells you nearly nothing about the actual user experience, because it ignores the volatility. Even if you are only interested in throughput volatility is interesting. It is harder to plan capacity for a highly volatile application than for one that is stable. Personally I prefer percentiles over averages as they give us a good picture of the distribution and thus the volatility.
In the picture we see that the page load time of our sample has a very high volatility. While 50 percent of all page requests are loaded in 3 seconds, the slowest 10 percent take between 5 and 20 seconds! That not only bodes ill for our end user experience and performance goals, but also for our capacity management (we’d need to over provision a lot to compensate). High volatility in itself indicates instability and is not desirable. It can also mean that we measure the response time not granular enough. It might not be enough to measure the response time of e.g. the payment transactions in general. The CreditCard and DebitCard payment transaction might have very different characteristics and we should measure them separately. Without doing that type of measuring response time becomes meaningless because we will not see performance problems and monitoring a trend will be impossible.
This brings us to the next point, what do we measure? Most monitoring solutions allow the monitoring either on an URL level, servlet level (JMX/App Servers) or Network level. In many cases the URL level is good enough as we can use pattern matching on specific URI parameters.
For Ajax, WebService Transactions or SOA applications in general this will not be enough. WebService frameworks often provide a single URI entry point per application or service and distinguish between different business transactions in the SOAP message. Transaction oriented applications have different transaction types which will have very different performance characteristics, yet the entry point to the application will be the same nearly every time (e.g. JMS). The transaction type will only be available within the request and within the executed code. In our Credit/Debit card example we would most likely see this only as part of the SOAP message. So what we need to do is to identify the transaction within our application. We can do this by modifying the code and provide the measures ourselves (e.g. via JMX). If we do not want to modify our code we could also use aspects to inject it or use one of the many monitoring solutions that supports this kind of categorization via business transactions.
In our case we would measure the response time of every transaction and label it as a DebitCard payment transaction when the shown method is executed and the argument of the first parameter is “DebitCard”. This way we can measure the different types of transactions even if they cannot be distinguished via the URI.
Think about errors
Apart from performance we also need to take errors into account. Very often we see applications where most transactions respond within 1.5 seconds and sometimes a lot faster, e.g. 0.2 seconds. More often than not these very fast transactions represent errors. The result is that the more errors you have the better your average response time will get, that is of course misleading.
We need to count errors on the business transaction level as well. If you don’t want to have your response time skewed by those errors, you should exclude erroneous transaction from your response time measurement. The error rate of your transaction would be another KPI on which you can put a static threshold. An increased error rate is often the first sign of an impeding performance problem, so you should watch it carefully.
I will cover how to monitor errors in more detail in one of my next posts.
What are problems?
It sounds like a silly question but I decided to ask it anyway, because in order to detect problems, we first need to understand them.
ITIL defines a problem as a reoccurring incident or an incident with high impact. In our case this means that a single transaction that exceeds our response time goal is not considered a problem. If you are monitoring a big system you will not have the time or the means to analyze every single violation anyway. But it is a problem if the response time goal is exceeded by 20% of your end user requests. This is one key reason why I prefer percentiles over averages. I know I have a problem if the 80th percentile exceeds the response time goal.
The same can be said for errors and exceptions. A single exception or error might be interesting to the developer. We should therefore save the information so that it can be fixed in a later release. But as far as operations is concerned, it will be ignored if it only happens once or twice. On the other hand if the same error happens again and again we need to treat it as a problem as it clearly violates our goal of ensuring a healthy application.
Alerting in a production environment must be set up around this idea. If we were to produce an alert for every single incident we would have a so called alarm storm and would either go mad or ignore them entirely. On the other hand if we wait until the average is higher than the response time goal customers will be calling our support line, before we are aware of the problem.
Know your system and application
The goal of monitoring is to ensure proper performance. Knowing there is a problem is not enough, we need to isolate the root cause quickly. We can only do that if we know our application and which other resources or services it uses. It is best to have a system diagram or flow chart that describes our application. You most likely will want to have at least two or three different detail levels of this.
- System Topology
This should include all your applications, service, resources and the communication patterns on a high level. It gives us an idea of what exists and which other applications might influence ours.
- Application Topology
This would concentrate on the topology of the application itself. It is a subset of the system topology and would only include communication flows as seen from that applications point of view. It would end when it calls third party applications.
- Transaction Response Flow
Here we would see the individual business transaction type. This is the level that we use for response time measurement.
Maintaining this can be tricky, but many monitoring tools provide this automatically these days. Once we know which other applications and services our transaction is using we can break down the response time into its contributors. We do this by measuring the request on the calling side, inside our application and on the receiving end.
This way we get a definite picture of where response time is spent. In addition we will also see if we loose time on the network in form of latency.
At this point we can monitor health, stability and performance of our application and we can isolate the causing tier in case we have a problem. If we do this for all of our applications we will also get a good picture how the applications impact each other. The next steps are to monitor each application tier in more detail, including used resources and system metrics. In the coming weeks I will explain how to monitor each of these tiers with the specific goal of allowing production level root cause analysis. At every level we will focus on monitoring the tier from an application and transaction point of view as this is the only way we can accurately measure performance impact on the end user.
Finally I will also cover System Monitoring. Our goal is however not to monitor and describe the system itself, but measure how it affects the application. In terms of Application Performance Monitoring, system monitoring is an integral part and not a separate discipline.