Any IT infrastructure exists solely to support the activities of the organisation using it. Functionality is provided to users by software applications; whilst monitoring the availability and performance of underlying infrastructure will go some way toward ensuring that they function correctly, if applications themselves can be directly monitored then a more complete and accurate picture emerges.
Much of the activity in the ESM marketplace in recent years has been concentrated around application monitoring. Infrastructure monitoring is now a relatively mature activity dominated by a small number of established players with official or de facto standards in place. In contrast, application monitoring is a rapidly growing sector with hundreds of vendors providing a plethora of mainly proprietary solutions to satisfy demand created by organisations looking to improve the quality of application service delivery. The adoption of a “service orientated” IT delivery model (where services delivered to users are the focus, as opposed to how well individual elements of the IT infrastructure are working) is further fuelling the interest in application monitoring and encouraging further new entrants into this marketplace.
Although few if any standards have emerged in the area of application monitoring, some common principles and techniques are, at least, used by all solution vendors. Most if not all applications operate via transactions. A transaction is an activity or series of linked activities, which are performed using an application and which deliver a useful result. Examples of transactions include performing a search via a Web search engine, creating a new customer record in a CRM system, running an online management report, making a credit card payment via a secure website and so on.
As discussed earlier, modern IT infrastructures tend to be highly distributed with tens, hundreds or even thousands of computers interlinked via networks being used to deliver applications to users. It is the norm for the successful execution of application transactions to be reliant upon multiple infrastructure components and network connections, all of which must be functioning effectively. Applications may also be reliant upon other applications, which themselves have their own infrastructure and perhaps application dependencies. Take the example of a Web-based application provided by an airline which allows customers to view schedules and book seats. The infrastructure which supports the application is as follows: –
A typical transaction would be to request information on available flights and prices for a specified origin, destination and date as the first step in booking a flight. The sequence of operations is as follows: –
1. User enters address for website in their Web browser
2. User selects link to “book flights” form (page); form is loaded from Webserver into Web browser
3. User enters “From” and “To” airport, date and whether it is a one way or return flight; click on “Search Flights”
4. Information entered into form is sent to application server which in turn issues a “select” statement against the back end database to find all data matching the criteria entered into the “book flights” form
5. Data matching the selection criteria are sent back to the application server by the database server
6. Data are formatted for display in the “book flights” webpage by a script running on the application server
7. Formatted Web page containing requested data is uploaded to the Web server
8. User’s Web browser displays updated web page with available flights, times and prices
So, even a relatively simple everyday transaction is made up of a number of steps and reliant upon a number of different pieces of infrastructure and software, all intercommunicating over a network. Each of these components is monitored using the appropriate element manager (server hardware), agent & management server (server operating system, database, application and webserver processes), network monitoring tool (network devices, topology & connectivity) and agentless monitoring tool (flight booking website availability). To complete the monitoring picture, it is necessary to monitor the individual steps making up the overall transaction to ensure that: –
a) Each transaction step completes successfully
b) Each transaction step completes within the required time limit
c) The overall transaction completes successfully
d) The overall transaction completes within the required time limit
Typically, a number of approaches may be taken to monitor the application transaction. One way is to use a robot to periodically perform the transaction in order to simulate what is being done by real users. If this synthetically-generated transaction fails or takes too long, then it is reasonable to assume that the same problem would be experienced by a real user.
Another approach would be to install a piece of agent software onto the PC from where the user is accessing the application, and to monitor the stream of instructions being processed by the PC operating system as the transaction is executed. An agent could also be installed on the application server and work in a similar manner. The advantage of this approach is that all transactions being processed by the application server are visible, as opposed to the far lower number of transactions that would be executed on a single user’s PC. These approaches are known as client and server instrumentation.
Another approach again is to use a network probe to capture data being transmitted over the network and deduce what transactions are being performed, by whom, from which locations, how long they are taking and whether they are successful from the captured data.
In each case, the monitoring technology used needs to be configured to recognise the application transactions to be monitored. In the case of synthetic transaction generation, this is done by “recording” transactions executed by a real user; in the case of client or server instrumentation or network data capture, this can be done either by performing sample transactions on an otherwise quite server/network infrastructure, or, as is more common nowadays letting the technology capture data for an extended period so that it can “learn” which transactions are taking place and what they do from the information contained within the captured data.
The choice of approach for application monitoring will depend on many factors such as infrastructure platforms used, application architecture, number of users, transaction volumes, size of network and others considerations, not least price. Once configured, the chosen monitoring tool will generally need to be integrated into the incumbent framework application (if present). Alternatively, most application monitoring vendors supply their own full-capable management server, administration and event browser consoles.