Graphics for end to end component mapping and problem-solving in a network environment Number:7,412,502 from the United States Patent and Trademark Office (PTO) owispatent

Title: Graphics for end to end component mapping and problem-solving in a network environment

Abstract: An example of a solution provided here comprises receiving as input at least one event (chosen from an event generated by an application probe, and an event generated by a component probe), and providing graphical output based on said inputs, whereby a user correlates a component problem with a performance problem affecting an application. Methods connected with graphics for end to end component mapping and problem--solving in a network environment, systems for executing such methods, and instructions on a computer-usable medium, for executing such methods, are provided.

Patent Number: 7,412,502 Issued on 08/12/2008 to Fearn,   et al.

---

Inventors:	Fearn; Paul (Raleigh, NC), Olsson; Stig Arne (Apex, NC), Vijayan; Geetha (Austin, TX)
Assignee:	International Business Machines Corporation (Armonk, NY)
Appl. No.:	10/125,619
Filed:	April 18, 2002

---

Current U.S. Class:	709/223 ; 709/224; 709/225; 715/733; 715/734; 715/736
Current International Class:	G06F 15/173 (20060101)
Field of Search:	709/223-226 715/734-737,733

---

References Cited [Referenced By]

---

U.S. Patent Documents

5295244	March 1994	Dev et al.
5459837	October 1995	Caccavale
5504921	April 1996	Dev et al.
5581482	December 1996	Wiedenman et al.
5696701	December 1997	Burgess et al.
5742819	April 1998	Caccavale
5787254	July 1998	Maddalozzo, Jr. et al.
5793753	August 1998	Hershey et al.
5812780	September 1998	Chen et al.
5835756	November 1998	Caccavale
5872973	February 1999	Mitchell et al.
5944782	August 1999	Noble et al.
5978475	November 1999	Schneier et al.
6000045	December 1999	Lewis
6041349	March 2000	Sugauchi et al.
6041352	March 2000	Burdick et al.
6052733	April 2000	Mahalingam et al.
6055493	April 2000	Ries et al.
6070190	May 2000	Reps et al.
6078956	June 2000	Bryant et al.
6108700	August 2000	Maccabee et al.
6141699	October 2000	Luzzi et al.
6151688	November 2000	Wipfel et al.
6163775	December 2000	Wlaschin et al.
6175832	January 2001	Luzzi et al.
6177886	January 2001	Billington et al.
6243396	June 2001	Somers
6269330	July 2001	Cidon et al.
6278694	August 2001	Wolf et al.
6278966	August 2001	Howard et al.
6279002	August 2001	Lenz et al.
6327550	December 2001	Vinberg et al.
6349325	February 2002	Newcombe et al.
6356205	March 2002	Salvo et al.
6397359	May 2002	Chandra et al.
6401119	June 2002	Fuss et al.
6425006	July 2002	Chari et al.
6430712	August 2002	Lewis
6449739	September 2002	Landan
6457143	September 2002	Yue
6499117	December 2002	Tanaka
6510463	January 2003	Farhat et al.
6550024	April 2003	Pagurek et al.
6556659	April 2003	Bowman-Amuah
6587878	July 2003	Merriam
6701342	March 2004	Bartz et al.
6708137	March 2004	Carley
6732168	May 2004	Bearden et al.
6734878	May 2004	DeLuca et al.
6738933	May 2004	Fraenkel et al.
6757543	June 2004	Moran et al.
6760719	July 2004	Hanson et al.
6763380	July 2004	Mayton et al.
6765864	July 2004	Natarajan et al.
6766278	July 2004	Liu et al.
6766368	July 2004	Jakobson et al.
6779032	August 2004	Hericourt
6792455	September 2004	DeLuca et al.
6792459	September 2004	Elnozahy et al.
6801940	October 2004	Moran et al.
6807156	October 2004	Veres et al.
6832341	December 2004	Vijayan
6853619	February 2005	Grenot
6857020	February 2005	Chaar et al.
6859831	February 2005	Gelvin et al.
6868094	March 2005	Bordonaro et al.
6871324	March 2005	Hand et al.
6885302	April 2005	Seal et al.
6889222	May 2005	Zhao
6892235	May 2005	Daude et al.
6901442	May 2005	Schwaller et al.
6904458	June 2005	Bishop et al.
6928471	August 2005	Pabari et al.
6934745	August 2005	Krautkremer
6941358	September 2005	Joiner et al.
6944673	September 2005	Malan et al.
6944798	September 2005	Stephenson et al.
6983321	January 2006	Trinon et al.
6996517	February 2006	Papaefstathiou
7043549	May 2006	Breese et al.
7047291	May 2006	Breese et al.
2002/0004828	January 2002	Davis et al.
2002/0073195	June 2002	Hellerstein et al.
2002/0087882	July 2002	Schneier et al.
2002/0097267	July 2002	Dinan et al.
2002/0161875	October 2002	Raymond
2003/0018450	January 2003	Carley
2003/0061232	March 2003	Patterson
2003/0093460	May 2003	Kinney et al.
2003/0120762	June 2003	Yepishin et al.
2003/0145079	July 2003	Breese et al.
2003/0145080	July 2003	Breese et al.
2003/0167406	September 2003	Beavers
2004/0015846	January 2004	Haisraeli
2004/0064546	April 2004	Olsson et al.
2004/0078684	April 2004	Friedman et al.
2004/0205184	October 2004	Olsson et al.

Other References

Paxson et al., "An Architecture for Large-Scale Internet Measurement", 1998, ftp.ee.lbl.gov/papers/nimi-ieee-comm98.ps.gz, pp. 1-9. cited by other . Phillips et al., "The FERET Evaluation Methodology for Face-Recognition Algorithms", 1999, sequoyah.ncsl.nist.gov/pub/nist.sub.--internal.sub.--reports/ir.sub.--626- 4.ps.Z, pp. 1-20. cited by other . Ruspini et al., "The Haptic Display of Complex Graphical Environments", 1997, robotics.stanford.edu/people/krasi/Siggraph97.ps.Z, 8 pages. cited by other . Blott et al., "User-Level Billing and Accounting in IP Networks", 1999, www.bell-labs.com/user/blott/BLTJ00.pdf, pp. 1-15. cited by other . Dykes et al., "An Empirical Evaluation of Client-side Server Selection Algorithms", 2000, www.ieee-infocom.org/2000/papers/700.pdf, 10 pages. cited by other . VIGNA, "NetSTAT: A Network-based Intrusion Detection Approach", 1998, www.cs.ucsb.edu/.about.vigna/pub/vigna.sub.--kemmerer.sub.--acsac98,ps.gz- , 10 pages. cited by other . Kung et al., "TCP Trunking for Bandwidth Management of Aggregate Traffic", 2000, www.eecs.harvard.edu/.about.htk/publication/2000-kung-wang-tcp-trun- king-1100.pdf, pp. 1-12. cited by other . PARULKAR, "An Architecture for Monitoring, Visualization and Control of Gigabit Networks", 1997, www.cs.wustl.edu/.about.schmidt/PDF/NMVC.pdf, pp. 1-21. cited by other . Chieng, David et al., "Agent-Enhanced Dynamic Service Level Agreement in Future Network Environments", Lecture Notes in Computer Science, vol. 2216, Oct. 29-Nov. 1, 2001, pp. 299-312. cited by other . Bhoj, Preeti et al., "SLA Management in Federated Environments", HP Internet Systems and Applications Laboratory, Dec. 1998, pp. 1-12. cited by other . Fankhauser, George et al., "Service Level Agreement Trading for the Differentiated Services Architecture", Swiss Federal Institute of Technology, Computer Engineering and Networks Lab, Technical Report No. 59, Nov. 1999, pp. 1-17. cited by other . Liu, Zhen et al., "On Maximizing Service-Level-Agreement Profits", ACM Conference on Electronic Commerce, Oct. 14-17, 2001, pp. 213-223. cited by other . Gaidioz et al., "Synchronizing Network Probes to avoid Measurement Intrusiveness with the Network Weather Service", 2000, www.cs.utk.edu/.about.rich/publications/nws-period.ps.gz, pp. 1-9. cited by other . Clark et al., "Application-Level Measurements of Performance on the vBNS", 1999, www.cs.unc.edu/.about.jeffay/papers/ICMCS-99.ps, 5 pages. cited by other . Sekar et al., "A High-Performance Network Intrusion Detection System", 1999, www.seclab.cs.sunysb.edu/sekar/papers/ccs99.ps, 10 pages. cited by other . Adiseshu et al., "A State Management Protocol for IntServ, DiffServ, and Label Switching", 1998, www.ccrc.wustl.edu/.about.hari/icnp.ps, pp. 1-24. cited by other . Mercury Interactive Corporation, "Products and Services/Testing," web page available at www.mercuryinteractive.com, 2001. cited by other . Mercury Interactive Corporation, "Load Tesing Monitors," web page available at www.mercuryinteractive.com, 2001. cited by other . Mercury Interactive Corporation, "Quick Test Professional," data sheet available at www.mercuryinteractive.com, 2001. cited by other . Atesto Technologies, Inc., "How does FunctionChecker work?" web page available at http://www.atesto.com/solutions.sub.--func.sub.--test.sub.--how.sub.--it.- sub.--works.asp, 2001. cited by other . Atesto Technologies, Inc., "Functional and Regression Testing," web page available at http://www.atesto.com/solutions.sub.--automated.sub.--fun.sub.--test.asp.- , 2001. cited by other . Freshwater Software, "SiteSeer Example Reports," http://www.freshwatersoftware.com/SiteSeerReports.htm, 2001. cited by other . Reading Management Reports, web page available at http://demo.freshwater.com/SiteScope/docs/History.htm, 2001. cited by other . Holistix, "Holistix Web Manager," web page available at http://www.holistix.net/products/webmgr/. 2001. cited by other . Holistix, "Holistix Web Manager Reporting," web page available at http://www.holistix.net/products/webmgr/reporting.html, 2001. cited by other . Holistix, "Response time and performance thresholds," web page available at http://www.holistix.net/products/webmgr/url.sub.--response.sub.--time.- sub.--chart.html, 2001. cited by other . Holistix, "Correlating response time to site availability," web page available at http://www.holistix.net/products/webmgr/avail.sub.--by.sub.--monitor.html- ., 2001. cited by other . Keynote, "Test Perspective," web page available at http://www.keynote.com/solutions/html/test.sub.--works.html., 2001. cited by other . Keynote, "The Keynote Solution," web page available at http://www.keynote.com/solutions/html/resource.sub.--transaction.sub.--pe- rspecti.html., 2001. cited by other . Tweney, "The Need for Speed," Business 2.0, vol. 2, No. 7, Aug./Sep. 2001, pp. 144-145. cited by other . Kerbyson et al., "Modelling the performance of large-scale systems", IEE Proceedings-Software, vol. 150, No. 4, Aug. 2003, pp. 214-221. cited by other.

Primary Examiner: Jaroenchonwanit; Bunjob
Assistant Examiner: Doan; Duyen M
Attorney, Agent or Firm: Walder, Jr.; Stephen J. Mims, Jr.; David A.

---

Claims

---

We claim:

1. A method for mapping, said method comprising: receiving component identifiers as input, wherein each component identifier comprises a depth parameter, a component name parameter, and a parent component parameter; receiving one or more event identifiers as input, wherein each event identifier comprises a depth parameter, an event name parameter, and a parent component parameter; and providing a graphical representation of a hierarchy containing separate graphical objects representative of a business process, an event generated by one of an application probe or a component probe, and at least one of a hardware component or a software component, wherein: the graphical representation of the hierarchy is generated based on the received component identifiers and the one or more event identifiers, a general view of a business process is represented in a level at one extreme of said hierarchy, at least one event generated by a component probe is represented in a level at the opposite extreme of said hierarchy from the level at which the general view of the business process is represented, and at least one event generated by an application probe is represented in an intermediate level of said hierarchy between the general view of the business process and the at least one event generated by the component probe, wherein said providing a graphical representation further comprises: providing an axis representing the death parameter, wherein graphical objects representative of the business process, an event generated by one of an application probe or a component probe, and at least one of a hardware component or a software component are arranged along the axis according to their corresponding depth parameter in the corresponding component or event identifier.

2. The method of claim 1, wherein said receiving one or more event identifiers further comprises: at least one event generated by an application probe; and at least one event generated by a component probe.

3. The method of claim 1, wherein said hierarchy includes approximately six to eight levels.

4. The method of claim 1, wherein said providing a graphical representation further comprises: providing a class diagram.

5. A method for mapping, said method comprising: receiving as input at least one component identifier representing at least one of the hardware component or the software component, wherein each component identifier comprises a depth parameter, a component name parameter, and a parent component parameter, receiving as input at least one event identifier representing at least one event chosen from: an event generated by an application probe; and an event generated by a component probe, wherein each event identifier comprises a depth parameter, an event name parameter, and a parent component parameter; and providing graphical output based on at least one component identifier and said at least one event identifier, wherein: providing a graphical output comprises providing a graphical representation of a hierarchy containing separate graphical objects representative of the at least one event whereby a user correlates a component problem with a performance problem affecting an application based on the graphical output, said component problem is associated with said at least one event, a general view of a business process is represented in a level at one extreme of said hierarchy, at least one event generated by a component probe is represented in a level at the opposite extreme of said hierarchy from the level at which the general view of the business process is represented, and at least one event generated by an application probe is represented in an intermediate level of said hierarchy between the general view of the business process and the at least one event generated by the component probe, wherein providing a graphical output further comprises: providing an axis representing the depth parameter, wherein graphical objects representative of the at least one event and the at least one of the hardware component or the software component are arranged along the axis according to their corresponding depth parameter in their corresponding component or event identifier.

6. The method of claim 5, further comprising: directing problem--solving efforts, based on said graphical output.

7. The method of claim 5, wherein said providing graphical output further comprises: providing graphical representations of items chosen from: a business process; and an application.

8. The method of claim 5, wherein said providing graphical output further comprises: providing an axis representing a depth parameter.

9. The method of claim 5, wherein said hierarchy includes approximately six to eight levels.

10. The method of claim 5, wherein said providing graphical output further comprises: providing a class diagram.

11. The method of claim 5, wherein said providing graphical output further comprises: providing one or more views chosen from: an application view; a component view; and a combination view.

12. The method of claim 1, wherein each component identifier and each event identifier further comprise a criticality parameter.

13. The method of claim 1, wherein each event identifier further comprises a problem determination parameter that associates problem determination procedures to an event associated with the event identifier.

14. The method of claim 1, wherein each event identifier further comprises a destination parameter that identifies where a report of an event associated with the event identifier was sent.

15. The method of claim 1, wherein each event identifier further comprises a service level agreement parameter that provides an index into a repository of service level agreements.

16. The method of claim 1, wherein providing the graphical representation of the hierarchy comprises arranging the separate graphical objects such that a graphical object representative of an event generated by one of an application probe or a component probe is graphically linked to a separate graphical object representative of one of a software or hardware component that generated the event.

17. The method of claim 5, wherein each component identifier and each event identifier further comprise a criticality parameter.

18. The method of claim 5, wherein each event identifier further comprises a problem determination parameter that associates problem determination procedures to an event associated with the event identifier.

19. The method of claim 5, wherein each event identifier further comprises a destination parameter that identifies where a report of an event associated with the event identifier was sent.

20. The method of claim 5, wherein each event identifier further comprises a service level agreement parameter that provides an index into a repository of service level agreements.

21. The method of claim 5, wherein providing the graphical representation of the hierarchy comprises arranging the separate graphical objects such that a graphical object representative of an event generated by one of an application probe or a component probe is graphically linked to a separate graphical object representative of one of a software or hardware component that generated the event.

---

Description

---

CROSS-REFERENCES TO RELATED APPLICATIONS, AND COPYRIGHT NOTICE

The present application is related to co-pending applications entitled Method and System for Probing in a Network Environment, application Ser. No. 10/062,329, filed on Jan. 31, 2002, Method and System for Performance Reporting in a Network Environment, application Ser. No. 10/062,369, filed on Jan. 31, 2002, and End to End Component Mapping and Problem--Solving in a Network Environment, filed on even date herewith. These co-pending applications are assigned to the assignee of the present application, and herein incorporated by reference. A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

FIELD OF THE INVENTION

The present invention relates generally to information handling, and more particularly to graphics for end to end component mapping and problem--solving, for information handling in a network environment.

BACKGROUND OF THE INVENTION

Various approaches have been proposed for monitoring, simulating, or testing web sites. Examples include U.S. Pat. No. 6,278,966 B1 (Howard, et al., Aug. 21, 2001), "Method and System for Emulating Web Site Traffic to Identify Web Site Usage Patterns." However, this example addresses substantially different problems (problems of simulation and hypothetical phenomena), and thus is significantly different from the present invention. Other examples include U.S. Pat. No. 6,078,956 (Bryant, et al., Jun. 20, 2000) and U.S. Pat. No. 5,787,254 (Maddalozzo, et al., Jul. 28, 1998). Other examples include services available from vendors such as Atesto Technologies Inc., Keynote Systems, and Mercury Interactive Corporation. These services may involve a script that runs on a probe computer. The examples mentioned above do not necessarily provide graphical tools for directing problem--solving efforts toward a component that is causing a problem.

When a problem occurs, lack of useful information can hamper efforts to restore the proper performance of an application in a network environment. These applications may involve many hardware and software components, so it may be difficult to quickly identify a component that is causing a problem. Thus there is a need for tools that quickly identify the cause of an outage at the component level, and properly focus problem--solving efforts for applications in a network environment, including but not limited to web sites and web services.

SUMMARY OF THE INVENTION

An example of a solution to problems mentioned above comprises: receiving as input at least one event (chosen from an event generated by an application probe, and an event generated by a component probe), and providing graphical output based on said inputs, whereby a user correlates a component problem with a performance problem affecting an application. Another example of a solution comprises: receiving component identifiers as input, receiving event identifiers as input, and providing a graphical representation of a hierarchy containing items chosen from:

a business process;

an application;

an event generated by an application probe;

a hardware component;

a software component; and

an event generated by a component probe.

The solutions provided here address the need to quickly understand the business impact of an outage, the need to quickly identify the cause of an outage at the component level, and the need to give high priority to problems with components that affect multiple business processes, for example.

BRIEF DESCRIPTION OF THE DRAWINGS

A better understanding of the present invention can be obtained when the following detailed description is considered in conjunction with the following drawings. The use of the same reference symbols in different drawings indicates similar or identical items.

FIG. 1 illustrates a simplified example of an information handling system that may be used to practice the present invention.

FIG. 2 is a block diagram illustrating one example of how the present invention was implemented in a data center that hosted a web site.

FIG. 3 is a diagram showing an example of identifying a problem with one or more components, according to the present invention.

FIG. 4 is a flow chart illustrating one example of how graphics for end to end component mapping and problem solving may be implemented, and used to direct problem--solving.

FIG. 5 shows one possible example of graphical output: a graphical representation of a hierarchy containing items such as a business process, an application, an event generated by an application probe, a hardware component, and an event generated by a component probe.

FIG. 6 shows another example of graphical output, whereby a user correlates a component problem with a performance problem affecting an application.

FIG. 7 shows another example of graphical output, providing an example of aggregating component status and an example involving performance degradation.

DETAILED DESCRIPTION

The examples that follow involve the use of one or more computers and may involve the use of one or more communications networks. The present invention is not limited as to the type of computer on which it runs, and not limited as to the type of network used. The present invention is not limited as to the type of medium used for graphics. Means for providing graphical output may include sketching diagrams by hand on paper, printing images on paper, displaying images on a screen, or some combination of these, for example. A model of a solution might be provided on paper, and later the model could be the basis for a design implemented via computer, for example.

The following are definitions of terms used in the description of the present invention and in the claims:

"Availability" means ability to be accessed or used.

"Business process" means any process involving use of a computer by any enterprise, group, or organization; the process may involve providing goods or services of any kind.

"Client-server application" means any application involving a client that utilizes a service, and a server that provides a service. Examples of such a service include but are not limited to: information services, transactional services, access to databases, and access to audio or video content.

"Comparing" means bringing together for the purpose of finding any likeness or difference, including a quantitative likeness or difference. "Comparing" may involve answering questions including but not limited to: "Is a measured response time greater than a threshold response time?" Or "Is a response time measured by a remote probe significantly greater than a response time measured by a local probe?"

"Component" means any element or part, and may include elements consisting of hardware or software or both.

"Computer-usable medium" means any carrier wave, signal or transmission facility for communication with computers, and any kind of computer memory, such as floppy disks, hard disks, Random Access Memory (RAM), Read Only Memory (ROM), CD-ROM, flash ROM, non-volatile ROM, and non-volatile memory.

"Measuring" means evaluating or quantifying.

"Event" means any action initiated by a computer or a user, including the sending of alerts, warnings, or other signals.

"Output" or "Outputting" means producing, transmitting, or turning out in some manner, including but not limited to printing on paper, or displaying on a screen, or using an audio device.

"Performance" means execution or doing; "performance" may refer to any aspect of an application's operation, including availability, response time, time to complete batch processing or other aspects.

"Probe" means any computer used in evaluating, investigating, or quantifying the functioning of a component or the performance of an application; for example a "probe", may be a personal computer executing a script, acting as a client, and requesting services a from a server.

"Response time" means elapsed time in responding to a request or signal.

"Script" means any program used in evaluating, investigating, or quantifying performance; for example a script may cause a computer to send requests or signals according to a transaction scenario. A script may be written in a scripting language such as Perl or some other programming language.

"Service level agreement" means any oral or written agreement between provider and user. For example, "service level agreement" includes but is not limited to an agreement between vendor and customer, and an agreement between an information technology department and an end user. For example, a "service level agreement" might involve one or more client-server applications, and might include specifications regarding availability, response times or problem--solving.

"Storing" data or information, using a computer, means placing the data or information, for any length of time, in any kind of computer memory, such as floppy disks, hard disks, Random Access Memory (RAM), Read Only Memory (ROM), CD-ROM, flash ROM, non-volatile ROM, and non-volatile memory.

"Structured identifier" means any definition, label, tag, or other means of identifying something, with a certain arrangement or order.

"Threshold value" means any value used as a borderline, standard, or target; for example, a "threshold value" may be derived from a service level agreement, industry norms, or other sources.

FIG. 1 illustrates a simplified example of an information handling system that may be used to practice the present invention. The invention may be implemented on a variety of hardware platforms, including embedded systems, personal computers, workstations, servers, and mainframes. The computer system of FIG. 1 has at least one processor 110. Processor 110 is interconnected via system bus 112 to random access memory (RAM) 116, read only memory (ROM) 114, and input/output (I/O) adapter 118 for connecting peripheral devices such as disk unit 120 and tape drive 140 to bus 112. The system has user interface adapter 122 for connecting keyboard 124, mouse 126, or other user interface devices such as audio output device 166 and audio input device 168 to bus 112. The system has communication adapter 134 for connecting the information handling system to a data processing network 150, and display adapter 136 for connecting bus 112 to display device 138. Communication adapter 134 may link the system depicted in FIG. 1 with hundreds or even thousands of similar systems, or other devices, such as remote printers, remote servers, or remote storage units. The system depicted in FIG. 1 may be linked to both local area networks (sometimes referred to as intranets) and wide area networks, such as the Internet.

While the computer system described in FIG. 1 is capable of executing the processes described herein, this computer system is simply one example of a computer system. Those skilled in the art will appreciate that many other computer system designs are capable of performing the processes described herein.

FIG. 2 is a block diagram illustrating one example of how the present invention was implemented in a data center that hosted a web site. FIG. 2 shows a simplified example of a typical e-business infrastructure, including a variety of network, server, and middleware components. These components are symbolized by server 270, server 280, and the boxes visible behind server 270 and server 280. As an overview, this example comprised: receiving as input events (symbolized by arrows pointing to console 205) generated by at least one application probe (shown at 221) and at least one component probe (shown at 271); and providing graphical output based on these inputs. FIG. 2 shows application probe 221 and component probe 271 providing input (symbolized by arrows) to console 205, which was used in providing graphical output, whereby a user could correlate a component problem (such as a problem with server 270) with a performance problem affecting an application (such as application 201).

Turning now to some details of the example implementation, application probes such as probe 221 measured response time for requests. The double-headed arrow connecting local application probe 221 with application 201 symbolizes requests and responses.

We located application probes locally at hosting sites (e.g. local application probe shown at 221, within data center 211) and remotely at relevant end-user sites (not shown in this diagram). This not only exercised the application code and application hosting site infrastructure, but also probed the ability of the application and network to deliver data from the application hosting site to the remote end-user sites. End-to-end measurement of IBM external applications (symbolized by application 201 with web pages 202) for customers or business partners, for example, involved remote application probes (RAP's) on the Internet (shown at 290). We also measured the availability and performance of the application at the location where it was deployed (local application probe shown at 221, within data center 211). This provided baseline performance measurement data, that could be used for analyzing the performance measurements from the remote probes (not shown in this diagram).

Local application probe 221 was implemented with a personal computer, utilizing IBM's Enterprise Probe Platform technology, but other kinds of hardware and software could be used. A local application probe 221 was placed on the IBM network just outside the firewall at the center where the web site was hosted. A local application probe 221 was used to probe one specific site per probe. There could be multiple scripts per site. A local application probe 221 executed the script every 20 minutes. Intervals of other lengths also could be used.

Component probe 271 could be implemented with a personal computer running a script, but other kinds of hardware and software could be used. Component probe 271 could be implemented with software products (such as those available from TIVOLI, for example, or other similar products). These products provide a framework for probing infrastructure components. These products are available for various operating systems and middle ware components.

Another aspect of this example in FIG. 2 was providing an alert (i.e. an event signaling a problem) when probe 221 or probe 271 detected an error. An example of an error in application 201 would be a measured response time value greater than a corresponding threshold value. For example, if a local application probe 221 encountered a problem (e.g., it was unable to access the site or unable to complete the script) on two consecutive executions of the script, local application probe 221 generated a real time alert (problem event, symbolized by arrow pointing to console 205), and sent it to a TIVOLI management system (shown as console 205). Another similar kind of management system could be used. Thus an alert was provided via a system management computer. An alert message via email also could be used. Similarly, component probe 271 generated a problem event (symbolized by arrow pointing to console 205) when a component problem was detected.

Turning now to some details of providing input from a plurality of probes, Component Probes measure availability, utilization and performance of infrastructure components, including servers, LAN, and services. Local component probes (LCPS) may be deployed locally in hosting sites, service delivery centers or data centers (e.g., at 211).

Network Probes measure network infrastructure response time and availability. Remote Network Probes (RNPS) may be deployed in a local hosting site or data center (e.g. at 211) if measuring the intranet or at Internet Service Provider (ISP) sites if measuring the Internet.

Application Probes measure availability and performance of applications and business processes.

Local Application Probe (LAP): Application probes deployed in a local hosting site or data center (e.g. at 211) are termed Local Application Probes.

Remote Application Probe (RAP): An application probe deployed from a remote location is termed a Remote Application Probe.

The concept of "probe", is a logical one. Thus for example, implementing a local component probe could actually consist of implementing multiple physical probes.

Providing a script for an application probe would comprise defining a set of transactions that are frequently performed by end users. Employing a plurality of application probes would comprise placing at least one remote application probe (not shown in FIG. 2) at each location having a relatively large population of end users. Note that the Remote Application Probe transactions and Local Application Probe transactions should be the same transactions. The example measured all the transactions locally (shown at 221), so that the local application response time can be compared to the remote application response time. This can provide insight regarding application performance issues. End-to-end measurement of an organization's internal applications for internal customers will involve a RAP on an intranet, whereas end-to-end measurement of an organization's external applications for customers, business partners, suppliers, etc. will involve a RAP on the Internet (shown at 290). The example involved defining a representative transaction set, and deploying remote application probes at relevant end-user locations. (This simplicity is something that can only be appreciated when this example is contrasted with other more complicated models.) A benefit following from the simplicity of this example is that it is easily generalized to other environments besides web based applications. Application 201 may be any client-server application. Some examples are a web site, a web application, database management software, a customer relationship management system, an enterprise resource planning system, or an opportunity management business process where a client directly connects to a server.

The example in FIG. 2 comprised providing an alert when an error occurred. The alert may be provided via email, for example, or may be provided in real time via a network and a system management computer 205. A clearing message may be provided when the error no longer is detected. In the example shown in FIG. 2, local application probe 221 generated a real time alert (problem event), and sent it to a TIVOLI management system (shown as console 205). Another similar kind of management system could be used.

The local application probe 221 automatically sent events to the management console 205 used by the operations department. In the example solution, integration was provided with the TIVOLI MANAGEMENT ENVIRONMENT and the TIVOLI EVENT CONSOLE product. The example solution generated events from the local application probe 221, and the events were generated after two consecutive errors on the same step in the business process. This could then be adjusted to send an event on the first error, for even faster notification. The recommendation is to send events on the second occurrence initially and then adjust to sending the event on the first occurrence as the environment becomes more stable and better understood by the operational staff. The reason for the recommendation is that in a Web environment there are a number of things that can cause intermittent problems, and it is ultimately a business decision when to invoke problem determination procedures.

Consider the following example of a condition where an event was generated. This example involved probing a web site for selling computer hardware. There were executions of the probe script that failed on step two. (Regarding the steps involved, see Table 1 below.) The associated event sent to the TIVOLI ENTERPRISE CONSOLE had a severity of "Warning," and documented the failure of step two, where the probe was unable to log on to the web site. Note that the date and time is the local time from the probe. In the examples below, "CRT" refers to a type of probe technology used by IBM. An example of an alert follows.

Tivoli alert for CRT probe failure: Tivoli CRT Alert--PC NA WARNING (NAQS2 [LogonFailed/1]) PCNa--Partner Commerce North America CRT Monitor

tag:auth=crtGwaFw

tag:message=PartnerCommerceNA https://ecna.partner.com Step-NAQS2-failed: Logon failed.

tag:severity=WARNING

tag:slot hostname=d03bpec18. pinfo.com

tag:slot mail svr=CVRM

tag:slot mta=ecna.partner.com

tag:slot probe_addr=NAQS2

tag:slot probe_date=07/21

tag:slot probe_time=19:58

tag:class=crt_event

tag:source=SENTRY

It is useful to automatically close opened events if a subsequent business process is executed successfully. This allows the operational staff to direct time and efforts to those events that remain in "open" status. Below is an example of such an event which was used to automatically close the previously opened event. The event was reported as severity HARMLESS and with the appropriate rules defined on the TIVOLI ENTERPRISE CONSOLE the previously opened event would be closed. This HARMLESS event was generated when the probe successfully executed the script and was able to log on to the web site. An example of such an event follows.

Tivoli alert for CRT probe failure: Tivoli CRT Alert--PC NA HARMLESS (NAQS2 [RecoveredZf/0]) PCNa--Partner Commerce North America CRT Monitor

tag:auth=crtGwaFw

tag:message=PartnerCommerceNA https://ecna.partner.com Step-NAQS2-failed: The problem causing the previous alert has been fixed.

tag:severity=HARMLESS

tag:slot hostname=d03bpec18. pinfo.com

tag:slot mail_svr=CVRM

tag:slot mta=ecna.partner.com

tag:slot probe_addr=NAQS2

tag:slot probe_date=07/21

tag:slot probe_time=21:43

tag:class=crt_event

tag:source=SENTRY

FIG. 3 is a diagram showing an example of identifying a problem with one or more components, according to the present invention. FIG. 3 illustrates how a user (e.g. operational staff) may establish relationships among a component problem 301, events 321 and 371 generated by probes, and performance problem 391 affecting an application (and thus affecting a customer or other end user of the application.) Methods and systems are provided herein for assisting operational staff in reducing mean time to repair a component problem 301, and thus solve a performance problem 391, for example. In FIG. 3, a component problem 301 is a root cause of a performance problem 391, affecting an application. Component problem 301 is associated with events generated by probes: event 321, generated by an application probe, and event 371, generated by a component probe.

Event 321 signals that performance problem 391 exists with an application. For example, event 321 might be similar to the problem event described above regarding FIG. 2, where a probe was unable to log on to a web site; or event 321 might be generated when a "time out" problem is encountered at some transaction step. In this example, event 371 might alert operational staff that a disk failure has occurred on a server. In that case, component problem 301 would be a disk failure. Methods and systems are provided herein for correlating ev