SYNOPSIS

Businesses are driving their IT operations managers to improve performance and boost productivity by becoming increasingly application-centric, a radical change of the infrastructure-centric approach that IT has had for years. At the same time, however, applications themselves are becoming increasingly difficult to manage as they move toward highly-distributed, multi-tier, multi-element constructs that in many cases rely on application development frameworks such as Microsoft .NET or Java.

In The Five Essential Elements of Application Performance Monitoring, author and renowned business technology expert Don Jones shows you the 5D Framework, an Application Performance Monitoring (APM) approach that helps businesses achieve this new application-centric focus.  You will learn how to improve application performance from the perspective of the business and the end user by constructing a 5D-compatible approach to APM within your own environment.  Jones offers an informative discussion of new tools and techniques that are enabling new, more effective forms of APM, and closes the book with a set of evaluation criteria for APM tools, based on the 5D approach.

CHAPTER PREVIEWS

Chapter 1: In Application Performance, the End User's Experience is King

Application Performance Monitoring (APM) is a complex set of disciplines designed to give you accurate details on how your business applications are performing. Many businesses rely on APM to tell them whether their internally‐developed applications are performing well, and many extend their monitoring to include third-party line-of-business applications. The ultimate goal of APM is to tell you whether an application that is supporting the business is slowing it down, and to provide you with tools and direction for solving application performance problems.

When it comes to measuring the overall performance and health of an entire application system, there is only one perspective that matters - that of the end users. This chapter will introduce APM and explore why end user experience (EUE) monitoring is the most important high-level metric you can have for APM.

Chapter 2: Tracking and Monitoring the User Transaction

Once you've accepted that the end user experience (EUE) is the ultimate top-level metric of your application's performance, how will you actually monitor it? More importantly, when the EUE isn't where you need it to be, how can you start finding the root cause of the problem?

The answer to both of these questions is the user transaction. I should probably take a minute to ensure we're on the same page with the term transaction. In the software development world, transaction usually means some group of operations that must be completed together or not completed at all. For example, in a financial application, you have to be sure to debit and credit the two sides of a ledger at the same time; if you only do one or the other, everything's messed up. A user transaction has a vaguely similar sort of meaning: It's a collection of discrete steps that a user undertakes to complete some higherlevel task. The classic example is an e-commerce shopping cart, which not only involves numerous steps for the user but also typically includes numerous back-end steps: saving a shopping cart, processing a credit card, generating an order entry, creating an invoice, and so forth. User transactions typically impact multiple components in your application, and they are the top-level unit of work that results in the EUE that you monitor.

Monitoring the user transaction can be incredibly complicated simply because our applications have, over the years, evolved into pretty complex systems. In fact, monitoring application performance used to be a lot easier.

Chapter 3: Discovering and Modeling Application Components

We're moving on to the third dimension of application performance monitoring (APM). At this point, we've learned to monitor the end‐user experience (EUE) as our primary, toplevel performance metric. That will let us know whether our application is performing to our business needs, and comprises the first dimension of APM. The second dimension, discussed in the previous chapter, involves tracking individual user transactions through our application, which provides us with high‐level insight into how individual elements of the application are performing. At that level, we should be able to tell which major component of our application is contributing to poor EUE metrics. For example, we might be able to narrow the problem to a Web server, database server, or some other high‐level component. Once we've done so, we need to dive deeper into those components to find the root cause of the performance problem.

Before we can do that, we need to help our monitoring tools understand how our application is built-and we need to do so at a fairly granular level. So before we can begin the component‐level deep‐dive, and indeed before we can even start seriously evaluating the user transaction tracking, we have to create a model of our application, which is the third dimension of APM's five‐dimensional, or 5D, model.

Gartner defines this dimension as the "…technologies [that] discover what software and hardware components are exercised as user‐defined transactions are executed, and how those components are related to one another, [insofar] as they support user‐defined transaction execution paths." Gartner also notes that this is the one dimension in the model that is still maturing; in today's solutions, you can expect a combination of three techniques:

• IT service dependency mapping tools, which are typically technologies that discover how different types of traffic flows through different types of physical and virtual infrastructure elements
• Transaction profile snapshots, which are built from the output of transaction tracking from the model's second dimension
• Service‐Oriented Architecture (SOA) topology maps, when available In this chapter, we'll focus on these techniques as well as how to use the application model, or map, that they can help create.

Chapter 4: Diving Deep into Your Application Components

With a valid and comprehensive application stack mapped out, you can start monitoring specific components' health. But when something goes wrong with a component, how do you figure out exactly what went wrong and start to take action toward fixing it? You could take the traditional approach and have IT specialists dig into the component using domainspecific tools—which can be difficult to do and often leads to specialists arguing with each other about whose components are really at fault. The 5D approach is to use a consolidated toolset that can dive deep within components to identify specific problems. You're moving beyond component health, now, and starting to diagnose specific root causes by looking under the hood.

Moving Further In: Going from Health Problems to Component Diagnostics

In their paper "Magic Quadrant for Application Performance Monitoring," Gartner defines this fourth dimension of APM as "Application component deep‐dive monitoring," describing it as:

…a diverse set of technologies. In addition to the higher‐level application health portraits obtained by the first three dimensions, effective diagnosis of performance problems frequently involves "looking under the covers" of the critical elements that hold a modern, highly modular application stack together; such elements include database management systems, application server middleware, message‐oriented middleware, off‐the‐shelf application stack frameworks and even some aspects of the network infrastructure. (Byte code instrumentation is a frequently favored way, for example, of deepdive monitoring for application servers.)

It's important to note that a lot of APM solutions don't really provide this dimension. Many of them stop at the server level; they can tell you when a database server isn't performing well, for example, but they can't dive deeper to tell you which bit of a Java or .NET Framework application that uses that database is holding up performance. As I'll discuss in the next chapter, proper APM depends on having all five dimensions in the 5D approach, and this fourth dimension is especially important for quickly pinpointing the root, actionable cause of a problem.

Chapter 5: Bringing it All Together: Managing Application Performance Data

In this final chapter, I'll discuss the last dimension of the 5D application performance monitoring (APM) model. This last dimension is what brings the prior four together and makes them useful, so before I dive in, I'll present an example case study from my experience (names have been changed). This will help provide context and show how the 5D model can work in a real‐world environment.

Case Study: The Application Is Slow!

I'll call this application Trax. It's a complex, distributed application designed to track customer order information. New orders are added to Trax by a separate order management system; the job of Trax is to provide both customers and customer service representatives with access to current order status and information. Customers access Trax via a Web‐based interface; in‐house service agents use a Java‐based client application. I'll refer to Trax' owner as just "the company."