Modern Web applications are a conglomerate of many individual moving parts. Web server software and hardware, application servers, database systems, custom developed applications, a variety of network devices, the network transport and, of course, the ever-present Web browser all present opportunity for failure. Unfortunately, when a Web application fails, finding out exactly what caused the bug can be a peskier task than fixing the bug itself.

In our test, Xaffire's xFire 3.0 platform attempts to provide a holistic view of a Web application's health and usage to assist in bug isolation. The product mostly succeeds in this task by tying together a range of data, although a few rough edges in its interface and overall approach hold it back at times.

To properly debug any software application - Web-based or not - the problem must be reproduced. Yet when it comes to Web applications, simple log files often don't provide enough information, as you need to know what the user did and the context in which they did it. You need to know not only the series of requests that might have led up to a problem, but also any data a user might have entered, the type of browser they used, and the states of the server and the network at the time of the request.

XFire attempts to provide an instant replay of a Web application problem by capturing and correlating data at the network level and the Web server level. Some data is fairly easy to collect from various logs and network-monitoring interfaces, but to collect actual user session data, xFire needs an interceptor in the form of an Internet Server API filter for an Internet Information Server (IIS) or an Apache module for an Apache-based system. We ran our IIS testing on an IIS 5.0-based system, as the collection filter has not yet been ported to IIS 6.0. Xaffire officials indicated the IIS port is well underway.

One caveat with the filter/module approach for collecting user data is that it will induce some minor performance degradation on a server, particularly if it is under significant load. That seems to be a minor penalty given the payoff of being able to actively debug a live application.

XFire also collects other infrastructure-related data, such as the health of a Web server, application server, database system or an SNMP-capable network device. All the data from monitored sessions and systems is collected at an xFire archiver appliance for monitoring and later analysis. The archiver appliance has a management console that provides access to the three major aspects of the xFire approach: infrastructure monitoring, synthetic transaction deployment and monitoring, and live session capture and playback.

The infrastructure monitor provides a simple graphical overview of the various resources that might be found in a Web farm. Some monitors are very basic ping or SNMP monitors, while in other cases with databases such as MySQL or application servers such as Tomcat, more detailed measurements are taken.

Discovery and configuration of these monitors is generally straightforward, but be forewarned given the range of versions available - particularly for open source platforms - you might have to tinker with settings, as we discovered when one of our versions of MySQL couldn't be monitored immediately.