Ca, Inc.

Indranil Basak

Jeffrey Robert Cobb

Erhan Giral

Aaron Blackwell

Vladimir Umansky

Abhijit Sawant

Dipasoke Chattopadhyay

Abhijit Bhadra

Gurumurthy R

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

A method for diagnosing problems in a computer system by visualizing flows through applications and other subsystems in a directed graph on a user interface. The user interface represents multiple instances of each application or other subsystem by a respective node, and edges indicate which nodes depend on one another. Aggregate metrics which are based on the multiple instances, and associated alerts, can be provided for the nodes and edges. An aging process can indicate which nodes have not been recently invoked. The user interface can also indicate which nodes and edges are associated with a given business transaction. In a summary view, a node hides the identity of invoked components such as servlets of the application, while in a detailed view these details are provided.

Visualization of JVM and cross-JVM call stacks

A technique for updating agent software which controls an agent, including how the agent adds instrumentation to an application and how the agent process data from the instrumentation. A current configuration file and an updated configuration file are evaluated in view of rules, to create a merged configuration file. The files include metadata entries. The rules can include: delete a current configuration file, not merge a current configuration file with an updated configuration file, overwrite a current configuration file with an updated configuration file, delete a metadata entry, prefer an entry in the configuration file over a corresponding entry in the updated configuration file, and prefer an entry in the updated configuration file over the corresponding entry in the configuration file. Customized entries in the current configuration file can be maintained if appropriate. Entries which are not maintained are kept in the merged configuration file as inline comments for documentation.

Metadata merging in agent configuration files

Disclosed herein are techniques for generating data that describes dependencies between software components as transactions are processed, as well as displaying dependency maps based on the data. The data may be collected by agents that monitor or trace transactions being processed by the software components. The collected data may be aggregated to form a directed graph that describes the dependencies between the software components. A dependency map may be displayed based on the directed graph. The dependency map may show dependencies between software components as the transactions are processed. The dependency map may also show dependencies between applications that include the software components. The dependency map(s) may allow a user to easily and quickly ascertain where a problem is occurring. For example, the user might be able to quickly determine that a problem is at a backend database, as opposed to an application server at a frontend.

Growing community of inventors

West Linn, OR, United States of America

Indranil Basak