Ultimately, the work of IT is about providing services to users, and the primary services -- from a user's perspective -- are storage and applications. Users notice only a few things about applications, most of which boil down to two questions:
- Does the application do what I want well?
- Does the application do what I want quickly?
What application performance monitoring and management does
APM approaches application performance management from several perspectives:
- Server: How does an application perform with respect to its use of compute, memory and storage resources? Does it use them in ways that waste no more than is acceptable and deliver acceptable response time?
- Network: How do traffic flows between the user and application front tier act on the network? How do flows between application tiers and application components behave?
- Desktop: How does the application desktop client perform?
The goal, of course, is to be able to say how well applications are performing, and if they are not performing well, where the problem lies. Your application performance monitoring and management solution should be able to pinpoint whether the problem lies:
- in the architecture and provisioning of the application;
- in the network between users and apps; or
- on the client side.
Having figured out where a problem lies can be critical to taking successful corrective action and to not wasting resources fixing the wrong things.
Choosing an application performance monitoring and management solution
One of the key decisions to make is whether to run application performance monitoring with or without agents. An application performance monitoring solution with agents involves software on servers and clients or specialized hardware in the network, whereas agentless APM does not use management agents on systems or the network. Agentless monitoring can be passive (examining network packets for information about what applications are doing) or active (using standard data access protocols such as SNMP and WMI to poll servers and switches and routers for information). Using an agent can get the most information, but also entails installation of the agents, complicating configuration management and subsequent software lifecycle management for the agents, which can introduce additional cost and effort. Going agentless limits you to the data available via standard management interfaces.
More on application performance monitoring and management
Web application performance: Complex apps make problems for WAN pros
Application performance management prepares you for new applications
Application performance management: Developing a strategy
Application performance monitoring and management: Runtime monitoring for SOA
Where to look in your application performance monitoring and management solution
However you approach APM, it is increasingly important to look at the entire range of behavior, from server and network hardware all the way up to application protocols and specific application operations (i.e., how specific commands and transactions perform and how client and server communicate).
Application performance problems can arise at any layer. A network card or router interface card may be malfunctioning, or two devices connected to one another may not be communicating properly due to misconfigurations. Problems not rooted in the network can result from poor application architecture and coding. Understand that it can be very difficult to direct corrective action toward those causes without being able to rule out the network. It may be necessary in some environments to run specialized code to track the performance of individual applications running on the server -- and even of modules or routines within the applications -- in order to understand application performance problems.
Ultimately, ensuring application delivery requires APM at some level, either to determine a baseline of good performance when things are working well, for future comparison -- or to identify the causes of problems, direct their solution, and verify their having been resolved.
This was first published in April 2012