WO2002013018A2 - Web site monitoring system and method - Google Patents

Abstract

Methods and systems for monitoring transactions and components on web sites are described. A universal monitoring module invokes a transaction agent associated with the web site by, for example, transmitting an HTTP GET command to a unique URL associated with that transaction agent. The transaction agent, which can be customized by the web site's owner to test the reachability and functionality of the web site components, performs at least one transaction on the web site and reports results using a standardized reporting format that can be readily parsed by the universal monitoring module. The universal monitoring module takes appropriate action, e.g., alerting web site responsible parties, based on the reported data. Using this type of monitoring methodology, a scalable yet customized monitoring solution is achieved.

Description

TRANSACTION COMPONENT MONITORING SYSTEM AND METHOD

COPYRIGHT NOTICE

This application includes Appendices containing exemplary software code and other materials which illustrate exemplary embodiments of the invention, which materials are subject to copyright protection. The copyright owner has no objection to the facsimile reproduction on paper of this software code as it appears in the records of the U.S. Patent and Trademark Office, but otherwise reserves all rights whatsoever.

BACKGROUND

The present invention relates generally to systems and methods for monitoring the functionality performance of computer-related transactions, e.g., those which occur on web sites. More particularly, the present invention relates to systems and methods for monitoring such transactions in a manner which is both scalable and customized. In the 1990's, the global, distributed computer network known as the Internet became a powerful tool for business. Whole new categories of business, referred to by the umbrella term of "e-commerce", were created to take advantage of the potential efficiencies provided by rapid, global information exchange and these new businesses quickly captured the attention of both the public and private industry. Among other things, the Internet acts as a transport mechanism for the World Wide Web, which can be described as a global, interconnected system of navigational links between collections of data. The World Wide Web is comprised of a very large number of web sites, each of which is a smaller group of linked data collections, e.g., web documents, that is accessible via the interconnected computer network. In order to provide the interconnectivity which is ubiquitous to the Internet, standard protocols were adopted for its various aspects. For example, the Transfer Control Protocol/Internet Protocol (TCP/IP) was adopted as the lowest level data transfer protocol by which computers exchange data over the Internet. HyperText Markup Language (HTML) provides a set of coding conventions which define how to present and link documents stored in the documents that make up web site data collections. Similarly, HyperText Transfer Protocol (HTTP) has been adopted as the client-server protocol by which documents are requested and transmitted over the World Wide Web. Web object addresses have been standardized by uniform resource locators (URLs) which uniquely identify a location of an object for retrieval via the World Wide Web. At their inception, web sites employed in e-commerce were typically designed, constructed, and operated by the same organization, often by the same people. Such e- commerce companies therefore had complete control and understanding of all of the software used in running their web site. This software included both high level graphical user interface and linking code, as well the business logic code (i.e., code performing business-related functions such as a shopping basket, order management, chat, searching, etc.) which underlies the display and document linking functionality of the web site. This provided the site operators with all of the knowledge needed to design and implement additional software for monitoring the operation of the business logic code. As the e-commerce industry experienced explosive growth, the level of effort required to operate and maintain more complex and sophisticated web sites increased in tandem. This, in turn, led to the development of web site operation and hosting services, where an e-commerce company out-sources the operational aspects of running their web site to another company, although the creation of the underlying business logic code typically remained with the e-commerce company itself. While this outsourcing of web site operation permitted e-commerce companies to focus their resources on their core business, it also created a situation where neither the writers of the business logic code nor the writers of the web site infrastructure and operations software have sufficient understanding of the other's software to create monitoring tools. Overcoming this mutual lack of familiarity is a significant undertaking, as the two parties must communicate the details of their code to the other party. This approach has proved to be impractical and overly burdensome. Moreover, the problems created by such an approach are exacerbated by the fact that the hosted web site (the e-commerce company) will normally implement ongoing changes to their business logic code, creating changes to the transactions that need to be monitored and requiring further cumbersome communications between the company performing the web site hosting/operation and the e-commerce company.

Some attempts have been made to automate the analysis of web sites. These typically can be categorized as mapping tools, which aid in understanding the contents and linkages of data collections within a web site, or automated load and performance testing tools, whereby software simulates traffic to a web site to test the site's performance and identify bottlenecks. An example of the former type of tool can be found in U.S. Patent No. 5,870,559, entitled "Software System and Associated Methods for Facilitating the Analysis and Management of Web Sites", assigned to Mercury Interactive, the disclosure of which is incorporated here by reference. An example of the latter type of tool can be found in U.S. Patent No. 5,974,572, entitled "Software System and Methods for Generating a Load Test Using a Server Access Log", also assigned to Mercury Interactive, the disclosure of which is also incorporated here by reference. In the '572 patent, various mechanisms are described for generating individualized test scripts that simulate actual web site usage, which test scripts can be executed to load test the web site by generating requests for information directed to the web site according to the script.

However, these conventional load monitoring systems suffer from the limitation of not being able to directly check the transactions involved in providing a service on a web site. That is, they do not have the ability to check the individual business logic code components in a manner which is customized to identify problems that are considered significant by those familiar with that business logic code. Instead, they infer from the point of failure, or the length of the response time, what is actually happening within the web site. Thus, these conventional attempts at automated web site testing fail to provide an adequate alternative to creating customized monitoring tools at the web hosting site based on information communicated by an e-commerce company's business logic code developers. SUMMARY

According to exemplary embodiments of the present invention, these and other drawbacks and difficulties of conventional monitoring techniques are overcome by providing agents and systems that permit customers (e.g., e-commerce companies) to install customer specific transaction monitoring software (referred to herein as an

"agent", which term is intended to refer to a program which can be either continuously or intermittently rarrning) within their business logic code through a defined process, and to have this agent interact with universal monitoring software. By providing universal monitoring software with customer specific transaction monitoring agents, solutions according to the present invention are both scalable and provide customized, detailed feedback regarding the web site's operational status.

According to the present invention, the customer is given guidelines and/or an implementation interface for creating one or more transaction monitoring agents which are specific to their web site. The universal monitoring software invokes the agent(s) with a customer-defined periodicity using a predetermined URL. The transaction monitoring agent(s) interact with the business logic code of the web site to determine whether the business logic code is functioning correctly, i.e., whether the customer's software components are both reachable and functional.

The transaction monitoring agent(s) then pass report data in a predetermined format, e.g. , an XML document have predefined fields, containing the results of the monitored transactions through the predetermined URL back to the universal monitoring software. The document(s) can then be parsed, since they contain at least some predefined, universal components, and the resulting values can be evaluated by event logic coded within the universal monitoring software. Based upon this logic, a variety of actions can be taken, e.g. , notifying various people within either the web site hosting company or the e-commerce customer company of a particular problem with the web site.

The present invention therefore provides, among other advantages, the opportunity for the customer to leverage its knowledge of the business logic code employed within a web site to create and update transaction monitoring agents, and allow these transaction monitoring agents to interact with universal monitoring software ranning, for example, on a web hosting company's operational systems. The web hosting company need only implement one universal monitoring architecture which can monitor, through interaction with the transaction monitoring agents, the functionality of any or all of their customer's web sites.

BRIEF DESCRIPTION OF THE DRAWINGS These and other objects, features and advantages of the present invention will be readily understood by those skilled in the art by reading the following detailed description in conjunction with the drawings, in which: Figure 1 describes a transaction monitoring architecture according to exemplary embodiments of the present invention;

Figure 2 is a flowchart which illustrates an exemplary transaction monitoring method according to an exemplary embodiment of the present invention;

Figure 3 conceptually depicts exemplary fields of a document that can be returned by the transaction monitoring agent according to the present invention; and Figure 4 illustrates a universal monitoring module which monitors the transactions performed by transaction agents at multiple web sites.

DETAILED DESCRIPTION In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular systems, networks, software components, techniques, etc. in order to provide a thorough understanding of the present invention. However, it will be apparent to one skilled in the art that the present invention may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known methods, devices, and circuits are omitted so as not to obscure the description of the present invention.

Figure 1 depicts an exemplary architecture for transaction monitoring according to the present invention. Therein, it will be immediately apparent that the architecture has been subdivided into two sections separated by a dotted line, specifically, a universal monitoring module 10 and a customer side which hosts the transaction agent 20. This manner of illustrating an exemplary embodiment of the present invention has been selected for ease of description and should not be considered as limiting of the present invention, which is amenable to any desired architecture. For example, the software functionality of the customer to be monitored may, or may not, be hosted by a third party's hardware. Moreover, for the purposes of this specification, it should be understood that the term "customer" is intended to include all types of computer systems and software whose functionality can be monitored including, but not limited, to web sites.

In the example of Figure 1, the universal monitoring module 10 includes a number of functional modules. First, a URL fetcher module 100 provides the requisite functionality for transmitting a command signal which invokes the customized transaction agent. This can occur with a periodicity which is defined by the web site owner. For example, the URL fetcher 100 can invoke the transaction agent by transmitting an HTTP GET command over the Internet or an intranet to a unique URL which has been provided for the web/application server 200. In effect, the URL fetcher 100 operates as a "tickler" mechanism for initiating the customized transactions at the web site from which the monitoring results are gleaned. The universal monitoring module 10 also includes, for example, an XML parser which receives, in this example, an XML document containing the results of the monitored transactions. The XML parser 110 parses out of the XML document the values of various predefined fields, examples of which will be described below. The universal monitoring module 10 further includes an event dispatcher 130 which contains the logic that is applied to the results of the transaction monitoring received from the XML parser 110. Based upon this logic, the event dispatcher may take a variety of different actions such as: notifying a network operations center (NOC), e.g., via an SNMP trap event, of a particular problem which is identified in the XML document (and/or the severity level of the problem), sending the results to a mail server to issue an e-mail page alert to interested parties (e.g. , the customer's CIO, finance, legal, engineering departments, etc.), posting the event on a web or application server or storage of the transaction monitoring results in a performance of database 160. Moving now to the customized side of the architecture illustrated in Figure 1, those skilled in the art will appreciate that the particular hardware and software which is used to implement any given customer's web site may vary significantly. In the example illustrated in Figure 1, a two-tier architecture is depicted, although the present invention is equally applicable to N-tier architectures of any type. Specifically, a web/application server 200 is operative to receive HTTP commands and output responses thereto. Connected to the web/application server 200 in this particular example are an LDAP server 210, an application server 220 and a database 230. Thus, for example, it may be desirable for a transaction agent to be developed on the customized side of the architecture to test the reachability and functionality of the LDAP server 210, the application server 220 and/or the database 230 to provide a balanced monitoring result regarding the operation of the web site supported by server 200. The transaction monitoring agent itself may reside on any of the servers (the web server, the app server, etc.) within the architecture of the customer site. If there is more than one of a certain type of server, such as web server, then instances of the transaction agent can reside on any or all of the customer's web servers, e.g., to allow monitoring of each of these servers independently.

Having described some general, exemplary architecture by way of which exemplary embodiments of the present invention can be implemented, general methods for monitoring transactions according to exemplary embodiments of the present invention will now be described with respect to the flowchart of Figure 2. Therein, the universal monitoring module 10 will invoke a transaction agent 20 associated with the web site to be monitored. For example, universal monitoring module 10 can transmit an HTTP GET command to a predetermined URL associated with the intended transaction agent at step 240. Examples of such HTTP GET commands are provided below. If desired, URLs can be authenticated or provided as a protected resource using either base 64 or MD5 digests. Such authentication or protection may be desirable in order to avoid unauthorized access to the monitoring tools provided by the transaction agents in a particular web site.

Next, at step 244, assuming that the GET command has been authenticated, the transaction agent associated with the URL in the GET command is launched or activated. This transaction agent will perform one or more transactions with components of the web site. These components may include, for example, the LDAP server 210, the application server 220 or the database 230 illustrated in Figure 1. However, those skilled in the art will appreciate that the particular components, links and transactions which are predefined in the transaction agent for performance upon receipt of the HTTP GET command should be customized for any particular web site to provide an accurate monitoring result regarding the reachability and functionality of the web site components. A more detailed example of a transaction agent is also provided below in Appendix A.

Once the one or more transactions associated with the transaction agent have been performed, the results are collated into a predefined format. It will be appreciated that the predefined format permits the universal monitoring module 10 to operate on the results, regardless of the differences between the web sites that it monitors. In this particular exemplary embodiment, the predefined format is an XML document. By using an XML document it is possible to use tags that describe the type of data contained within the XML document, however, those skilled in the art will further appreciate that the predefined format can take other forms than an XML document, e.g. , a text document. Thus, at step 246, an XML document based on the transaction results is generated, for example, by an application program interface (API). Next, at step 248, the XML document is transferred to the universal monitoring module 10. As mentioned above, the XML document is then parsed at step 250 to extract the predefined fields. These predefined fields are then evaluated by the event dispatcher 120 at step 252. Based upon the field values which are identified as a result, the event dispatcher 120 will then selectively transmit one or more messages and/or take other desirable actions at step 254 to indicate the results of the monitored transactions. Lastly, at step 256, the event dispatcher 120 may also store and/or post transaction results, e.g., to the performance database 160.

Having provided a general overview of the architecture and techniques for transaction monitoring according to exemplary embodiments of the present invention, additional details and examples of the components of systems and method according to the present invention will now be provided in order to enhance the understanding thereof. Transaction Agent URL. Invoking the Transaction Agent and Response

As mentioned earlier, a predetermined URL is assigned to each transaction agent 20 to provide a mechanism that permits the universal monitoring module 10 to invoke that agent. Each web site that is monitored according to the present invention may have more than one such predetermined URLs if it is desirable to break up the monitored components into separate agents, e.g., if certain portions of the web site should be tested less frequently than other portions of the web site. Those skilled in the art will appreciate that the format for the transaction agent URL may vary, but the following are examples of such URLs.

1 http : //host . loudcloud . com servlets/ticklerName

2 http : //host . loudcloud . com/servlets/ticklerName?user = value&pass wd = value

3 http : //host . loudcloud . com/cgi-bin/ticklerName . cgi

4 http : //host . loudcloud . com/cgi-bin ticklerName . cgi/user = value&passwd = value 5 http : //host . loudcloud . com/ticklerName . html

The transaction agent 20 is invoked by the transmission of a command by the universal monitoring module 10. These commands may be designed to require password protection or authentication prior to launching the transaction agent as a security precaution. In the foregoing URL examples 2 and 4, passwords are conveyed as arguments to the URL. However, in examples 1, 3 and 5 above, the request headers themselves can include the authentication credentials to be validated prior to launching the transaction agent. Examples of HTTP GET commands which can be used to invoke the transaction agent are provided below, one of which employs Base 64 encoding of an MD5 hashed username and password, whereas the second example just employs the Base 64 encoding.

1. UNIVERSAL MONITORING MODULE REQUEST USING MD5 AUTHENTICATION • GET/servlets/ticklerName HTTP/1.0

• User- Agent: TransSentinel-LC/1.0

• Accept: text/plain, text/xml

• Authorization: MD5 username:passwd 2. UNIVERSAL MONITORING MODULE REQUEST USING BASIC AUTHENTICATION

GET/servIets/ticklerName HTTP/1.0 User-Agent: Trans-Sentinel- l-.CV 1.0 • Accept: text/plain, text/xml

• Authorization: BASIC username:passwd

The web/application server 200 which is hosting the transaction agent (as well as the web site to be tested) can then return a suitable response. For example, if the authentication is valid, the server 200 can transmit a response header back to the universal monitoring module 10 as:

1. AGENT SERVER RESPONSE (Authentication Passes) HTTP/1.1 200 OK Date: July 31, 2000 19:56:09 GMT

• Content-Type: text/plain

Otherwise, if the authentication fails, then the server 200 can send, for example, one of the following response headers back to the universal monitoring module: 2. AGENT SERVER RESPONSE (MD5 Authentication Fails) HTTP/1.1 401 Authorization Required Date- July 31, 2000 19:56:09 GMT WWW- Authenticate: MD5 realm = "user" • Content-Type: text/plain

3. AGENT SERVER RESPONSE (Basic Authentication Fails) HTTP/ 1.1 401 Authorization Required • Date: July 31, 2000 19:56:09 GMT

WWW-Authenticate, BASIC realm= "user"

Content-Type: text/plain

Transaction Agents

Once the handshaking between the universal monitoring module 10 and web server 200 is completed (with or without authentication), then the transaction agent will be activated. A significant feature of the present invention involves the customized nature of the transaction agents, which are therefore expected to vary widely in complexity, design and functionality. Thus, those skilled in the art will appreciate that transaction agents can be implemented using different programming techniques. Nonetheless, purely as an illustrative example for the interested reader, an exemplary Java implementation of a transaction agent is provided as Appendix A. In the code modules found in Appendix A, a Java servlet checks various aspects of a two-tier architecture by performing transactions including: (1) a user authentication against a flat file, (2) a database query transaction and (3)a credit card authorization transaction.

XML Return Document

Regardless of the manner in which the transaction agent is implemented, the results of the monitored transactions should be returned to the universal monitoring module 10 in a predetermined format and using certain predefined, recognizable values so that the universal monitoring module 10 can operate on results being returned from a wide variety of different web sites, as will be illustrated and described below. As a purely exemplary format for illustration herein, an XML document with the predefined fields illustrated in Figure 3 can be used to return monitoring results to the universal monitoring module 10. These predefined fields can be used to pass values which provide the following monitoring functionality.

1. trans category. This field in the returned XML document contains a customizable token or group identifier which can be used by the universal monitoring module to group similar or identical transactions.

2. trans_no. A field which contains a step number which can be automatically incremented to reflect a sequence of transactions.

3. trans_name. A field which contains a name for the transaction being monitored.

4. trans desc. A field which contains a customizable description of the transaction which will be meaningful for usage in messages transmitted by the event dispatcher 130. For example, this field could contain a string such as: "LDAP user/passwd authentication with LDAP server ldap.loudcloud.com:389". 5. trans_status. A field which contains a customizable status for the transaction, e.g., indicative of success or error for that transaction. Again, the contents of this field can be used by the event dispatcher as part of an alert mechanism. For instance, this field could contain the string: "Failed to establish Connection to LDAP server Idap,loudcloud.com:389".

6. trans_rtt_ms. This field contains a value reflective of the response time e.g., in milliseconds, for the latency experienced in performing the transaction during the current step.

7. trans_lc.status. This field contains a string having one of a plurality of predefined values known to the universal monitoring module 10, e.g., "SUCCESS" or "FAILURE" to provide an absolute indication of the status of the monitored transaction.

8. trans_lc.severity. This field contains a string having one of a plurality of predefined values known to the universal monitoring module that reflects a level of severity associated with the condition reported in the trans_lc. status field, e.g., "NORMAL", 'WARNING", "ERROR", "FATAL". To reinforce the reader' s understanding of the relationship between transaction monitoring agents and the predefined, formatted data to be returned to the universal monitoring modules, a set of exemplary XML documents is also provided as Appendix B. These documents reflect exemplary output gathered by the exemplary Java servlet transaction agent which precedes them in the Appendix A. Those skilled in the art will recognize that the eight fields illustrated in Figure 3 and described above are purely exemplary and that other fields providing other functionality may be included, while some or all of the foregoing fields can be omitted. This example serves, however, to reinforce the hybrid customizable/universal qualities of monitoring techniques according to the present invention. These qualities are further reflected upon consideration of the system illustrated in Figure 4.

Therein, a plurality of customers 1-N, e.g., 400, 410, 420 and 430 are associated with a plurality of web sites to be monitored by a single universal monitoring module 10. Thus, each of the customers has their own (at least one) URL enabled transaction monitoring agent which can be invoked by, for example, the transmission of a corresponding GET command thereto. In response, each customer site web server returns XML documents having the same or similar predefined fields to the universal monitoring module 10, so that the universal monitoring module 10 can parse the results of the transactions being monitored and take appropriate action. Since the XML documents (or other forms of returnable output, e.g., text documents) are at least partially standardized, the single universal monitoring module 10 can be used to monitor the activities of many different web sites, thus rendering monitoring techniques according to the present invention eminently scalable. At the same time, since the customer creates the transaction monitoring agent(s) associated with their web site, and the standardized return document can include at least some customizable fields, the monitoring feedback provided by universal monitoring module 10 can be focused on mission critical transaction components and provide customer-tailored alerting functionality.

The above-described exemplary embodiments are intended to be illustrative in all respects, rather than restrictive, of the present invention. Thus the present invention is capable of many variations in detailed implementation that can be derived from the description contained herein by a person skilled in the art. For example, the web site to be monitored may be hosted by a third party or not, the universal monitoring module may share a server or a network with the transaction monitoring agent(s), etc. All such variations and modifications are considered to be within the scope and spirit of the present invention as defined by the following claims.

APPENDIX A Java Servlet import java.io.*; import java.util.*; importjava.net.*; import Java. sql.*; import j ava . security . * ; import j avax . servlet . * ; import javax.servlet.http. *;

public class TestTicklerAuthArgs extends HttpServlet { public void doGet (HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException

{

String title = request.getParameter("cust"); if (title = = null) { title = new String(" Generic Customer"); } try {

My TestTicklerAuthArgs myTickler = new

MyTestTicklerAuthArgs(request, response, title); myTickler . doSteps() ; } catch (IOException e) { throw e;

}

} public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { doGet(request, response);

}

}

// Author : Jules Damji

// Description : Java Servet to Check end to end transaction connectivity

// : A simple prototype to check various aspects of a two tier architecture

// : A user authenticatification against a Flat File, a

Oracle DB query

// : Transaction followed by a credit card authorization.

// : Here the arguments, save customer, are base64 encoded strings of MD5 hased

// : text. The Server than compares its MD5 base64 strings against the arg to

// : verify authentication. This is a counter example to

CheckTransAuthArgs using

// : Java Tickler Interface (JTI) interface

// Inputs : cust = customer_name&user = user_name&owner = owner_name

// : This is more secure than sending everything in the clear.

// Date : Wed May 3 13:24:35 PDT 2000

// Example NO : 2

import java.io.*; import java.util.*; import java.net.*; import java.sql.*; import java.security.*; import javax.servlet.*; import javax.servlet.http.*;

import sun.misc.*; import com.loudcloud.mon.tickler.*;

public class My TestTicklerAuthArgs extends TransTickler { private String dbFile = " /cust/usr/apache/servlets/ . db . conf " ; private String transFile =

" /cust/usr/apache/servlets/ . trans . txt " ; private String user = "moneng"; private String passwd = "SentinelFreak! "; private String userB64; private String passwdB64; private String hostname;

public MyTestTicklerAutbArgs (HttpServletRequest request,

HttpServletResponse response, String custName) throws IOException { super(request, response, custName); initO;

}

// Create Base64 hash of the MD4 digest for user and passwd which is

// then compared against the Servlet arguments. private void init() { try {

MessageDigest md = MessageDigest.getInstance("MD5"); md.update(user . geιBytes()) ; byte userraw[] = md.digest();

BASE64Encoder encoder = new BASE64Encoder(); userB64 = encoder. encode(userraw);

// reuse again md.reset(); md.update(passwd.getBytes()); byte passwdraw[] = md.digest(); passwdB64 = encoder. encode(passwdraw);

} catch (NoSuchAlgorithmException ex) { System.out.println("Exception: " + ex.getMessage());

} }

// Subclass implements this instance method to excercise various components

// involved in a successful transaction. // public void doSteps() {

try {

PrintWriter out = new PrintWriter(getTransResponse() . getWriter()) ; if (!authCheck(getTransRequest())) { setAuthError(response, out); return;

} } catch(IOException e){ handleException(e); return;

} doDbTrans(getTransRequest()) ; doXXXCheck(); doYYYCheckO; doZZZCheck(); doRPCCheckO; doVerityCheck(); doWrapUpO; }

//

// Do the DataBase Query Here. This could be a simple query or a

// trivial update to ascertain that the DB is functioning. private void doDbTrans(HttpServletRequest req) {

Connection con = null; Statement st = null; ResultSet rs = null; String dbUrl = null; String dbUser= null; String dbPasswd = null; String dbDriver = null; String dbHost = null; String resVal = null; long tl, rt;

tl = rt = 0; try { setTransTagVal(TRANS_NAME, "DbSize"); setTransTagVal(TRANS_DESC, "DB ACCESS to db.foo.com");

// Get the dbstuff from its config files.

Properties dbProps = new Properties(); tl = System. currentTimeMillisO; try {

FilelnputStream os = new FilelnputStream (dbFile); dbProps.load(os); dbUrl = dbProps.getPropertyC'dbUrl"); dbUser = dbProps.getPropertyC'dbUser"); dbPasswd = dbProps . getProperty ( " dbPasswd " ) ; dbDriver = dbProps. getProperty ("dbDriver");

DriverManager . register Driver (new oracle . jdbc . driver . OracleDriver ()) ; con = DriverManager.getConnection(dbUrl,dbUser, dbPasswd); st = con.createStatementO; rs = st.executeQueryC'SELECT SUM(BYTES) FROM DBA EXTENTS WHERE OWNER= ' " + req.getParameter("dbOwner") + " ' "); while (rs.next()) { resVal = rs . getString( " sum(bytes) " ) ;

} rs.close(); st.closeQ; rt = System. currentTimeMillisO - tl; setTransTagVal(TRANS_STATUS, "SUCCESS - DB Query OK"); setTransTagVal(TRANS_RTT_MS,

Long . toString(rt)) ; setTransTagVal(TRANS_LC_STATUS, lcStatus[TRANS_LC_STATUS_OK]);

setTransTagVal(TRANS_LC_SEVERITY, IcSeverity [TRANS JLC_SEVERITY_OK]) ;

} catch (IOException e) { rt = System. currentTimeMillisO - tl; setTransTagVal(TRANS_STATUS, e.getMessageO); setTransTagVal(TRANS_RTT_MS, Long . toString(rt)) ; setTransTagVal(TRANS_LC_STATUS , lcStatus[TRANS_LC_STATUS_FAIL]); setTransTagVal(TRANS_LC_SEVERITY, lcSeverity[TRANS_LC_SEVERITY_FATAL]);

} catch (SQLException ex) { rt = System. currentTimeMillisO - tl; setTransTagVal(TRANS_STATUS , ex.getMessage()); setTransTagVal(TRANS_RTT_MS, Long . toString(rt)) ; setTransTagVal(TRANS_LC_STATUS , lcStatus[TRANS_LC_STATUS_FAIL]); if (ex.getErrorCodeO = = 2456) {

setTransTagVal(TRANS_LC_SEVERITY, lcSeverity[TRANS_LC_SEVERITY_FATAL]);

} else { setTransTagVal(TRANS_LC_SEVERITY, IcSeverity [TRANS_LC_SEVERITY_ERROR]) ;

}

} genTransXML("OracleDB"); } catch (TransTicklerException e) {

System, err .println(e . getMessage()) ; e.printStackTrace();

} finally { try { if (con ! = null) { con.close();

}

} catch (SQLException ex) {}

} }

// This obtains user profile from LDAP server

// private void doYYYCheck() { long rt, tl; rt = tl = 0; try { setTransTagVal(TRANS_NAME, "LdapUserProfile"); setTransTagVal(TRANS_DESC, "Fetch User Profile from LDAP server ldap.foo.com: 1039"); tl = System. currentTimeMillisO; try {

Thread. sleep(600); } catch (Exception e) {} rt = System. currentTimeMillisO - tl; short rand = (short)(Math.floor(Math.random() * 5) + 3); setTransTagVal(TRANS_RTT_MS, Long.toString(rt));

if (rand % 2 = = 0) { setTransTagVal(TRANS_STATUS, "Failed to connect to ldap.foo.com"); setTransTagVal(TRANS_LC_STATUS, lcSta s [TRANS J C_STATUS_FAIL]); setTransTagVal(TRANS_LC_SEVERITY, lcSeverity[TRANS_LC_SEVERITY_FATAL]); } else { setTransTagVal(TRANS_STATUS, "SUCCESS - CONNECTION OK yp.foo.com"); setTransTagVal(TRANS_LC_STATUS, lcStatus[TRANS_LC_STATUS_OK]); setTransTagVal(TRANS_LC_SEVERITY, IcSeverity [TRANS JLC_SEVERιTY_OK]) ;

} genTransXML("LdapDB");

} catch (TransTicklerException e) { Sy stem, err . println(e . getMessage()) ; e .printStackTrace() ;

}

} // Update the user profile on LDAP server at a different port. private void doZZZCheck() {

long rt, tl; rt = tl = 0; try { setTransTagVal(TRANS_NAME, "LdapWriteProfile"); setTransTagVal(TRANS_DESC, "Update User Profile at LDAP server ldap.foo.com: 1039"); tl = System. currentTimeMillisO; try {

Thread. sleep(600); } catch (Exception e) {} rt = System. currentTimeMillisO - tl; short rand = (short)(Math.floor(Mafh.random() * 5) + 3); setTransTagVal(TRANS_RTT_MS, Long.toString(rt));

if (rand % 2 = = 0) { setTransTagVal(TRANS_STATUS, "Failed to connect to ldap.foo.com"); setTransTagVal(TRANS_LC_STATUS , lcStatus[TRANS_LC_STATUS_FAIL]) ; setTransTagVal(TRANS_LC_SEVERITY, lcSeverity[TRANS_LC_SEVERITY_FATAL]); } else { setTransTagVal(TRANS_STATUS, "SUCCESS - CONNECTION OK yp.foo.com"); setTransTagVal(TRANS_LC_STATUS, lcStatus[TRANS_LC_STATUS_OK]); setTransTagVal(TRANS_LC_SEVERITY, lcSeverity[TRANS_LC_SEVERITY_OK]) ;

} genTransXML("LdapDB");

} catch (TransTicklerException e) { System, err .println(e. getMessage()) ; e.printStackTraceO;

}

}

//check the RPC server private void doRPCCheck() { long rt, tl; rt = tl = 0; try { setTransTagVal(TRANS_NAME, "CheckRPC"); setTransTagVal(TRANS_DESC, "Verify the RPC server daemon yp.foo.com:4000"); tl = System. currentTimeMillisO; try {

Thread.sleep(350); } catch (Exception e) {} rt = System. currentTimeMillisO - tl; short rand = (short)(Math.floor(Math.random() *

5) + 3); setTransTagVal(TRANS_RTT_MS, Long.toString(rt));

if (rand % 2 = = 0) { setTransTagVal(TRANS_STATUS, "Failed to connect to yp.foo.com:4000"); setTransTagVal(TRANS_LC_STATUS, lcStatus[TRANS_LC_STATUS_FAIL]); setTransTagVal(TRANS_LC_SEVERITY, lcSeverity[TRANS_LC_SEVERITY_FATAL]); } else { setTransTagVal(TRANS_STATUS, "SUCCESS RPC OK yp.foo.com:4000"); setTransTagVal(TRANS_LC_STATUS, lcStatus[TRANS_LC_STATUS_OK]); setTransTagVal(TRANS_LC_SEVERITY, IcSeverity [TRANS_LC_SEVERITY_OK]) ; } genTransXML(); } catch (TransTicklerException e) {

System.err.println(e.getMessage()); e . printStackTrace() ; }

}

//Check Verity Search engine process private void doVerityCheck() { long rt, tl; rt = tl = 0; try { setTransTagVal(TRANS_NAME, "VerifySearch") ; setTransTagVal(TRANS_DESC, "Verify the Verity Search server daemon search.foo.com:2020"); tl = System. currentTimeMillisO; try {

Thread.sleep(350); } catch (Exception e) {} rt = System. currentTimeMillisO - tl; short rand = (short)(Math.floor(Math.random() *

5) + 3); setTransTagVal(TRANS_RTT_MS, Long.toString(rt)); if (rand % 2 = = 0) { setTransTagVal(TRANS_STATUS, "Failed to connect to search.foo.com:2020"); setTransTagVal(TRANS_LC_ST ATUS , lcStatus[TRANS_LC_STATUS_FAIL]) ; setTransTagVal(TRANS_LC_SEVERITY, IcSeverity [TRANS_LC_SEVERITY_FATAL]) ;

} else { setTransTagVal(TRANS_STATUS, "SUCCESS - Search OK to search.foo.com:2020"); setTransTagVal(TRANS_LC_ST ATUS , lcStatus[TRANS_LC_STATUS_OK]); setTransTagVal(TRANS_LC_SEVERITY, IcSeverity [TRANS_LC_SEVERITY_OK]) ;

} genTransXML(); } catch (TransTicklerException e) {

System.err.println(e.getMessageO); e .printStackTrace() ;

}

} // This step could be anything that checks a critical component of your

// architecture: a check against an external daemon running that does

// your credit card transaction, a request from some broker agent to

// ensure it is running.. private void doXXXCheck() { long rt, tl; rt = tl = 0; try { tl = System. currentTimeMillisO; setTransTagVal(TRANS_NAME, " Verify CreditCard") ; setTransTagVal(TRANS_DESC, "VERIFY CREDIT CARD

AUTHORIZATION connection with fdc.bank.com"); setTransTagVal(TRANS_STATUS, "SUCCESS - fdc

Client OK"); try {

Thread.sleep(1500); } catch (Exception e) { } rt = System. currentTimeMillisO - tl; setTransTagVal(TRANS_RTT_MS, Long.toString(rt));

setTransTagVal(TRANS_LC_STATUS, lcStatus[TRANS_LC_STATUS_OK]) ; setTransTagVal(TRANS_LC_SEVERITY, lcSeverity[TRANS_LC_SEVERITY_OK]); genTransXML(); } catch (TransTicklerException e) { System.err.println(e.getMessage()); e .printStackTrace() ; }

}

// Compare the encoded Base64 MD5 digests against the ServLets version. private boolean authCheck(HttpServletRequest req) {

String requserB64 = req.getParameter("user");

String reqpasswdB64 = req.getParameter("passwd"); if (userB64.equals(requserB64) && passwdB64.equals(reqpasswdB64)) { return true; } else { return false; }

}

// Authorization Error

// Do not generate the transaction page.

// The client will receive a 401 error private void setAuthError(HttpServletResponse res, PrintWriter out) { try { res.sendError(res.SC UNAUTHORIZED);

} catch (IOException e) { e.printStackTrace();

}

}

// finish stuff up

// private void doWrapUp() { flushXMLO; genFooterXMLO ; closeOutStreamO ;

} // // Handle Exception by sending only on trans tag with SEVERITY as warning. private void handleException (IOException ex) { try { setTransTagVal(TRANS_NAME, "ExceptionError"); setTransTagVal(TRANS_NO, "0"); setTransTagVal(TRANS_DESC, "Failed to get Servlet Out Stream"); setTransTagVal(TRANS_STATUS, ex.getMessageO); setTransTagVal(TRANS_RTT_MS, "0"); setTransTagVal(TRANS_LC_STATUS, lcStatus[TRANS_LC_STATUS_FAIL]) ; setTransTagVal(TRANS_LC_SEVERITY, lcSeverity[TRANS_LC_SEVERITY_WARNING]); genTransXMLO; doWrapUp();

} catch (TransTicklerException e) {

System, err .println(e. getMessage()) ; e.printStackTrace() ;

} }

}

APPENDIX B

<?xml version="1.0" ?>

<!DOCTYPE transactions SYSTEM "trans.dtd"> <transactions customer ="Psuedo" hostname ="webgrunt" tstamp="965368251561"> <trans category="OracleDB">

< tr ans_no > 1 < /tr ans_no > <trans_name > DbSize < /trans_name > <trans_desc>DB ACCESS to db.foo.com</trans_desc> <trans_status> SUCCESS ~ DB Query OK</trans_status>

< tr ans_rtt_ms > 135 < /tr ans_rtt_ms > <trans_lc_status > SUCCESS </trans_lc_status >

< tr ans_lc_severity > NORMAL < /trans_lc_severity > < /trans >

<trans category="UnDefined"> <trans_no > 2 </trans_no >

< trans_name > VerifyCreditCard < /trans_name >

<trans_desc> VERIFY CREDIT CARD AUTHORIZATION connection with fdc .bank.com < /trans_desc >

<trans_status>SUCCESS - fdc Client OK</trans_status>

<trans_rtt_ms > 1496 </trans_rtt_ms >

<trans_lc_status > SUCCESS </trans_lc_status >

<trans_lc_severity>NORMAL</trans_lc_severity> < /trans >

<trans category="LdapDB">

< tr ans_no > 3 < /tr ansjno >

< tr ansjname > LdapUserProfile < /trans_name > <trans_desc> Fetch User Profile from LDAP server ldap.foo.com: 1039 </trans_desc>

<trans_status>SUCCESS - CONNECTION OK yp.foo.com</trans_status>

< trans_rtt_ms > 601 < /trans_rtt_ms > <trans_lc_status > SUCCESS </trans_lc_status > <trans_lc_severity>NORMAL</trans_lc_severity> </trans>

<trans category="LdapDB"> <trans_no >4 </trans_no >

< tr ans_name > L dap WriteProfile < /tr ans_name > <trans_desc>Update User Profile at LDAP server ldap.foo.com: 1039 </trans_desc>

<trans_status> SUCCESS - CONNECTION OK yp.foo.com</trans_status>

<trans_rtt_ms > 598 </trans_rtt_ms >

<trans_lc_status > SUCCE SS </trans_lc_status >

<trans_lc_severity>NORMAL</trans_lc_severity> < /trans >

<trans category ="UnDefined">

<trans_no > 5 </trans_no >

<trans name >CheckRPC< /trans name> <trans_desc> Verify the RPC server daemon yp.foo.com:4000</trans_desc> <trans_status>SUCCESS - RPC OK yp.foo.com:4000</trans_status>

< trans_rtt_ms > 350 < /trans_rtt_ms > <trans_lc_status > SUCCESS </trans_lc_status > < tr ans_lc_s e verity > NORMAL < /tr ans_lc_s e verity > < /trans >

<trans category="UnDefined"> <trans_no > 6 < /trans_no > <trans_name > VerifySearch</trans_name > <trans_desc > Verify the Verity Search server daemon search.foo.com:2020 </trans_desc> <trans_status>SUCCESS - Search OK to search.foo.com:2020</trans_status>

< trans_rtt_ms > 350 < /trans_rtt_ms >

< trans_lc_status > SUCCE SS < /trans_lc_status > < tr ans_lc_s e verity > NORMAL < /tr ans_lc_s e verity > < /trans > </transactions >

Claims

WHAT TS CLAIMED IS:

1. A method for monitoring a web site comprising the steps of: invoking, from a monitoring module, a transaction monitoring agent using a predetermined uniform resource locator (URL); performing, by said transaction monitoring agent, at least one transaction within said web site; returning, to said monitoring module, at least one result generated from said at least one transaction in a predetermined format; evaluating, by said monitoring module, said at least one result; and selectively, based on said evaluating step, dispatching a message indicating a state of said web site.

2. The method of claim 1, wherein said step of invoking further comprises the steps of: transmitting an HTTP GET command to said predetermined

URL, said HTTP GET command including an identifier associated with said transaction monitoring agent; and launching said transaction monitoring agent responsive to said

HTTP GET command.

3. The method of claim 2, wherein said HTTP GET command includes a request header having authentication credentials.

4. The method of claim 2, wherein said HTTP GET command includes authentication credentials as arguments of said identifier.

5. The method of claim 1, wherein said step of returning further comprises the step of: sending an XML document having said predetermined format to said monitoring module.

6. The method of claim 1, wherein said step of evaluating further comprises the step of: parsing said XML document to obtain at least one value from a predefined field in said XML document.

7. The method of claim 1, wherein said predetermined format includes a field for an identifier for grouping said at least one transaction with other transactions.

8. The method of claim 1, wherein said predetermined format includes a field for a step number associated with said at least one transaction.

9. The method of claim 1, wherein said predetermined format includes a field for a name of said at least one transaction.

10. The method of claim 1, wherein said predetermined format includes a field for a customer-defined description of said at least one transaction.

11. The method of claim 1 , wherein said predetermined format includes a field for a customer-defined string describing a status of said at least one transaction.

12. The method of claim 1, wherein said predetermined format includes a field for a latency value associated with said at least one transaction.

13. The method of claim 1, wherein said predetermined format includes a field for an absolute status value associated with said at least one transaction.

14. The method of claim 1, wherein said predetermined format includes a field for a severity level associated with a status of said at least one transaction.

15. The method of claim 2, further comprising the steps of: authenticating said HTTP GET command; returning a response header from said transaction monitoring agent to said monitoring module; and selectively launching said transaction monitoring agent if said

HTTP GET command is validly authenticated.

16. The method of claim 1, wherein said step of selectively dispatching a message further comprises the step of: sending an e-mail message to a manager of said web site.

17. A system for monitoring transactions comprising: a web server hosting at least one transaction agent for performing at least one transaction and identifying at least one parameter associated with performance of said at least one transaction; a monitoring module for sending a command to a predetermined uniform resource locator (URL) which launches said at least one transaction agent and which receives said at least one parameter therefrom, said monitoring module selectively transmitting an alert message based on said at least one parameter; wherein said at least one transaction agent conveys said at least one parameter to said monitoring module in a predetermined format.

18. The system of claim 17, wherein said monitoring module transmits an HTTP GET command to said predetermined URL, said HTTP GET command including an identifier associated with said transaction monitoring agent.

19. The system of claim 18, wherein said HTTP GET command includes a request header having authentication credentials.

20. The system of claim 18, wherein said HTTP GET command includes authentication credentials as arguments of said identifier.

21. The system of claim 16, wherein said web server authenticates said HTTP GET command, returns returning a response header to said monitoring module and selectively launches said transaction agent if said HTTP GET command is validated.

22. The system of claim 17, wherein said monitoring module parses said predetermined format to obtain at least one value.

23. The system of claim 22, wherein said predetermined format is an XML document having a plurality of fields.

24. The system of claim 23, wherein one of said plurality of fields is a field containing an identifier for grouping said at least one transaction with other transactions.

25. The system of claim 23, wherein one of said plurality of fields is a field containing a step number associated with said at least one transaction.

26. The system of claim 23, wherein one of said plurality of fields is a field containing a name of said at least one transaction.

27. The system of claim 23, wherein one of said plurality of fields is a field containing a customer-defined description of said at least one transaction.

28. The system of claim 23, wherein one of said plurality of fields is a field containing a customer-defined string describing a status of said at least one transaction.

29. The system of claim 23, one of said plurality of fields is a field containing a latency value associated with said at least one transaction.

30. The system of claim 23, wherein one of said plurality of fields is a field containing an absolute status value associated with said at least one transaction.

31. The system of claim 23 , wherein one of said plurality of fields is a field for a severity level associated with a status of said at least one transaction.

32. A computer-readable medium having stored thereon a computer program which, when executed by a computer, causes the computer to perform the steps of: activating, in response to a command directed to a predetermined uniform resource locator (URL), a transaction monitoring agent; performing, by said transaction monitoring agent, at least one transaction which interacts with software that is associated with said predetermined

URL; generating at least one result from said at least one transaction; and outputting said at least one result in a predetermined format.