Apple Inc.

Ca, Inc.

Computer Associates Think, Inc.

Wily Technology, Inc.

Jeffrey Robert Cobb

Lewis K Cirne

Ling Thio

Daryl L Puryear

Eric Schlegel

Robert R Ulrich

Robert G Johnston, Jr

Gabriel J Vanrenen

Timothy J Craycroft

Jyoti Bansal

Ramesh M Gupta

Dylan B Ashe

Bhaskar Sunkara

Erik L Eidt

Brian Zuzga

James E Palmer

Aaron Blackwell

Alan W Lillich

Robert T Bowers

Indranil Basak

Vladimir Umansky

Gregory George Scown

Abhijit Sawant

Patrick Charles O'Sullivan

Wayne N Meretsky

B Winston Hendrickson

New code is added to existing object code in order to add new functionality. For example, a call to start a profiler function can be added at the beginning of a Java method and a call to stop the profiler function can be added at the exits of the Java method. A method may have many different exits. To insure that the profiler process is stopped regardless of which exit is performed, the byte code and exception table are modified.

Adding functionality to existing code at exits

A model is used to provide a user interface to track flows through at least one application of a computer system. The model relates the structural aspects of the at least one application to a behavioral model such as a business transaction hierarchy. The structural part of the model includes linked Vertex and Edge records. Vertex records for different instances of a component can be aggregated to provide a single vertex or node for display in a user interface. A Vertex record is linked to an Agent record and a Metric Path record. The Edge records identify tail and head components of a call. A set of Edge records can be associated with a Transaction record in the behavioral part of the model. A Transaction record can be associated with a Business Transaction Record, and a Business Transaction record can be associated with a Business Service Record.

Transaction model with structural and behavioral description of complex transactions

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

A method and apparatus for routing an event to a human interface object in a computer system. A routing type is assigned to each event type which may be received. The event is received and the routing type assigned to the event is determined. The event is then routed based on the routing type. In embodiments of the invention, the routing type may be geometric, focus, or broadcast, but is extensible. The routing types may be added or removed from a list of routing types, at request of processes.

Event routing mechanism in a computer system

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

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

Data relating to execution flows at a computer system is aggregated across multiple execution flows by categorizing each execution flow into an execution flow shape. The execution flows may represent sequences of software components that are invoked or other computer system resources that are consumed. The execution flow shapes are developed by observing and recording the execution flows at the computer system and applying lossy compression rules. Execution flows are categorized into an execution flow shape which is a closest match. The execution flow data may be aggregated by an agent at the computer system, and communicated to a manager for subsequent use. The aggregation combines the information from all execution flows into a small enough data set that can be reported without consuming unduly large processing overhead while still preserving as many of the interesting aspects of the execution flows as possible.

Use of execution flow shape to allow aggregate data reporting with full context in an application manager

Data relating to execution flows at a computer system is compressed and aggregated across multiple execution flows by categorizing each execution flow into an execution flow shape. The execution flows may represent sequences of software components that are invoked. The execution flow shapes are developed by observing the execution flows at the computer system and applying lossy compression rules, such as representing multiple iterations of a loop as a single iteration, skipping certain types of software components, such as those having a specified call stack depth, treating some of the software components as being optional, and ignoring recursive calls by the software components. The aggregation and compression allow the information from all execution flows to be combined into a small enough data set that can be reported without consuming unduly large processing overhead while still preserving as many of the interesting aspects of the execution flows as possible.

Execution flow shape compression for aggregate data reporting in an application manager

Instrumentation is dynamically added to application components during runtime. An interestingness engine receives inputs from various sources which identify software components such as classes for which it is desired to provide instrumentation. The sources can include a heuristics engine which receives performance data from already-instrumented components, a user interface from which a user identifies component to be instrumented or de-instrumented, and a static list of components to be instrumented. During the runtime, instrumentation can be added to components which become interesting, or removed from components which become not interesting. When loading or redefining a component, if a component type matches rules, it is eligible for instrumentation, and the interestingness engine is consulted to determine whether the component is of interest, in which case instrumentation is added. If a component type does not match rules, but the component is interesting, the rules can be updated to include the component type.

Intelligent engine for dynamic and rule based instrumentation of software

Data relating to execution flows running on different processes or threads at a computer system is correlated. The execution flows may represent sequences of software components that are invoked or other computer system resources that are consumed. A first execution flow fulfills a first request by transmitting a second request which initiates a second execution flow, such as at another computer system. The second request includes meta data which identifies a context of the first request, such as a URL, an agent which monitors the first execution flow, and the component in the first execution flow which initiated the second request. A manager receives information regarding the first execution flow from the first agent, and information regarding the second execution flow, along with the meta data, from a second agent, for correlating the first and second execution flows. The received information may include execution flow shape data.

Correlating cross process and cross thread execution flows in an application manager

A method and system are provided for developing images for use in a graphical user interface. In one implementation, the method includes displaying a graphical user interface on a display device, and providing an operating system on a computer that is in communication with the display device. The operating system includes an imaging object structure that is an abstract base class from which subclasses of text imaging objects, picture imaging objects, and pattern imaging objects are derivable. The subclasses of text imaging objects, picture imaging objects, and pattern imaging objects are used to respectively generate text imaging objects, picture imaging objects, and pattern imaging objects for display in the graphical user interface.

Method and system for image rendering including polymorphic image data in a graphical user interface

A system is disclosed that can determine whether a routine is stalled. The system does not require the developer of the routine to add code for the purpose of detecting whether the routine is stalled. Furthermore, the system can be used to monitor various routines at different levels of granularity, such as at the thread level, method level, or other levels. One embodiment of the present invention allows a user to specify a method and an expected time frame. Code for that method is modified to add additional code that implements a timing mechanism. The timing mechanism is used to detect when a thread enters that method and does not return within an approximation of the expected time frame. Other embodiments are also within the scope of the present invention.

Growing community of inventors

Belmont, CA, United States of America

Jeffrey Robert Cobb