Ca, Inc.

Computer Associates Think, Inc.

Lucent Technologies Inc.

Ling Thio

Jeffrey Robert Cobb

Brian Zuzga

Jyoti Bansal

Ramesh Mani

Jon Ruiz

Daryl L Puryear

Patrick Charles O'Sullivan

Instrumentation points are selected for an application by running the application with comprehensive instrumentation of its components in a development mode. The application can be run by a human operator and/or load simulator which provides requests to the application. The instrumented components are monitored as the application runs. A subset of the components is selected based on criteria such as an order in which the instrumented components are invoked, whether resource utilization, such as consumption of processor cycles, exceeds a threshold, or a frequency with which components are called or call other components, and only that subset is instrumented in a production mode of the application. In one approach, the subset includes components which are invoked when traffic to/from the application matches a pattern provided by an interaction model. As a result, relevant instrumentation points can be identified.

Selecting instrumentation points for an application

Multiple transaction components that comprise a transaction are correlated using a GUID generated at a browser application. The transaction components may occur asynchronously or synchronously between a network browser and one or more applications. An identifier is generated for a set of network browser requests corresponding to a single user input or some other event and the identifier is included in each request. Server traffic and the servers processing the request are monitored and data which includes the identifier is generated. Data for the transaction with multiple transaction components is reported using the GUID associated with the transaction.

Monitoring related content requests

Information is obtained from an application monitoring system which monitors the execution of an application and a traffic monitoring system which monitors traffic between clients and the application. The clients interact with the application to perform transactions or other tasks. Traffic monitoring data, such as information regarding defects and incidents, and application runtime data, such as traces of invoked application components, can be integrated in an output such as an interface to provide an enhanced understanding of system performance. Related traffic monitoring data and application runtime data can be linked by a request-response pair identifier associated with a request provided to the application and a response provided by the application.

Integrating traffic monitoring data and application runtime data

Synthetic transactions for a network system are generated based on monitoring of the network system to determine whether the network system may be blind to traffic. A process determines whether an application within an application server in a network system is processing traffic received by the application server, and whether a web server within the network system and in communication with the application server is receiving traffic that requires processing by the application. The process determines that the network system may be blind to the traffic, and, in response, generates a synthetic transaction instruction and a corresponding synthetic transaction to test whether the network system is blind to the traffic. Based on a response of the network system to the synthetic transaction, the process determines whether there is a malfunction of the application server or a period of low traffic activity of the application server.

Synthetic transactions to test blindness in a network system

Data collected during runtime and associated with a service level agreement and operating level agreement for a network service are automatically correlated together. A network monitoring system monitors the network service during runtime to determine SLA and OLA violations. An SLA is tested against traffic monitoring data derived from monitoring traffic between a network service system and one or more users of the system. An OLA is tested against application runtime data generated from monitoring a transaction occurring between an application server and a backend or other internal entity of the network service system. The data collected during runtime can be correlated using a hierarchy based on business transactions or in some other manner. Because the traffic monitoring data and application runtime data are organized using a similar data hierarchy, the traffic monitoring data corresponding to an SLA may be correlated to the application runtime data corresponding to the same business transaction and one or more OLAs.

Automatic correlation of service level agreement and operating level agreement

Application runtime data is obtained from an application monitoring system which monitors execution of an application, and traffic monitoring data is obtained from a traffic monitoring system which monitors traffic to/from the application as the clients interact with the application. Corresponding application runtime data and traffic monitoring data can be selectively output to assist an operator in investigating an anomalous condition. The data can be classified and selectively output according to one or more hierarchies which characterize the interactions. The hierarchies can include a domain level, a business process level (where a domain is made up of a number of business processes), a business transaction level (where a business process is made up of different business transactions), an individual transaction level (where a business transaction is made up of different transactions), and a transaction component level (where a transaction is made up of one or more transaction components).

Hierarchy for characterizing interactions with an application

Synthetic transactions for a network system are generated based on monitoring of the network system. One or more network system monitoring systems receive network system traffic, traffic monitoring data and/or application runtime data during a monitoring process. The traffic monitoring data may be derived from network system traffic and the application runtime data may be data associated with application transactions. The traffic, traffic monitoring data and application runtime data may contain information regarding the scope and frequency of the functionality tested by the actual traffic received by the network system. Synthetic transactions may be generated and transmitted to test the network system based on the scope and frequency of the functionality tested by actual traffic.

Synthetic transactions based on system history and load

A system and method is provided for measuring network round trip time by monitoring fast-response operations at one network endpoint, typically a client computer. A client computer of the system includes a network monitoring and analysis engine which monitors a sent packet for a fast-response operation. If a fast-response operation is detected, then the client computer assumes a server computer processed the packet substantially instantaneously. Thus, the processing time at the server computer is neglected as zero. The round trip time can then be approximated as the difference in time between when the client computer sent the packet and when the client computer received the response packet.

Growing community of inventors

Sunnyvale, CA, United States of America

Ling Thio