Locating the Weakest Link
AppSight 4.0 maintains watch over events that may be making your application crumble.
A few months ago I wrote about a briefing I got from the Identify people about
AppSight, their root-cause failure analysis software. This month I had a chance
to install the software and go through a compressed version of their training.
I've got to tell you, it was pretty darned impressive.
Installing the software was trivial; basically just a matter of putting in
the CDs and accepting all the defaults. This left me with the underlying "Black
Box" technology for watching applications, the Black Box Manager to control
the Black Boxes, and an integrated set of consoles (rich GUI applications) for
analyzing the results. Then comes the process of watching a failing application.
Basically, identify what you want to watch, run it, look at the results in the
And wow, what a lot of results you can get. Object creation and destruction,
strings of data sent between components, database accesses, library loads, memory
allocations...damned near anything. There are some pretty amazing things they
can do here. For example, deploy black boxes on all three tiers of an application
that uses a web browser to access a database via an IIS server. Run the browser
and look at the details of the capture in the console. Spot a problem, click
a few times...and be looking at what happened on the IIS server. Click a few
more...and you're right over on the database server looking at what it was doing.
After seeing some of the canned examples, I deployed the technology to a Web
server where I was having a mystery problem. This server wasn't on my domain,
but no problem - you can deploy a Black Box with a simple Web or disk-based
install, and capture its results to a log file for later analysis (and the log
files are amazingly small, even when they're capturing everything the user does
on the screen for later playback). A few minutes later I was looking at the
trace in the console, and quickly found the web page that was causing the problem
and the Windows library where things were blowing up.
One more example of what the software can do: you identify a set of PerfMon
counters that you'd like to track. Run the application. Then look at the counter
values in a graph, like the one that PerfMon displays...only you can scroll
back and forth over the entire lifetime of the application, rather than having
a circular buffer overwrite itself. And as you scroll, the list of application
events stays synchronized. Locating the code that was running when memory leaked
becomes trivial with this model.
Yes, it's high-priced, but this is darned good software. If I were running
a dev group producing a serious commercial product, or distributed apps for
a decent-sized corporation, I'd certainly be fighting to buy a copy.
Mike Gunderloy, MCSE, MCSD, MCDBA, is a former MCP columnist and the author of numerous development books.