APM (application performance management) is a lot like exercise: Everyone knows they need it, but only a fraction practice
it consistently, citing high costs and lengthy deployment times as excuses.
In these days of doing more with less, however, those who give APM a closer look can reap significant rewards. Supported by
counters -- both existing metrics and custom counters exposed by in-house developers -- APM solutions monitor everything from
CPU utilization and memory consumption to network throughput. Most include some kind of analysis component to interpret the
counter data, highlight and log discrepancies, trigger alerts, and so on. The analyzed APM data can then be used to manage
capacity, troubleshoot problems, ensure performance levels, or even plan future growth.
Today's IT pros can tap a wealth of tools and resources that tell exactly what's going on under the hood. Depending on your
OS starting point, you may be able to stitch together a workable solution using nothing more than what's sitting aroundyour IT lab.
In this article, we examine the state of the APM art as it relates to three leading OS platforms: Microsoft Windows Server,
Sun Solaris, and Linux. Each takes a slightly different approach to the task of tracking application run-time behavior, so
IT shops must shape their respective APM strategies to fit their chosen platform.
Counters, Counters Everywhere
The heart of any APM solution is the metrics counter. This unimposing entity is the ultimate insider, delivering critical
data on the darkest regions of the run-time environment's underbelly. Whether woven into the OS kernel or tacked on to a virtual
machine class library, metrics counters are what make systemwide APM possible.
Counters also say a lot about the ideology of the OS developer. For example, Solaris provides a wealth of counters for exploring
the inner workings of Sun's own hardware, while Windows channels its broad array of system and application counters through
a central library (the Performance Data Helper DLL), making them accessible to even casual developers.
The move to browser-based application architectures introduced an entirely new layer to the APM stack: the Web application
server. With an emphasis on code portability and platform abstraction (through the aforementioned virtual machine model),
Web application servers require their own instrumentation facilities that may or may not mesh with those of the underlying
host OS, making APM trickier.
As the complexity level spirals upward and IT faces the challenge of managing parallel APM architectures, the ability of a
given vendor solution to integrate these disparate resources -- without forcing customers to seek third-party help -- is rapidly
becoming a key APM selling point.
How do you gauge your APM options? Consider three variables: deployment cost (time and effort as well as dollars), ease of
use, and APM functionality. Put those factors together, and platform cohesiveness trumps best-of-breed in many situations.