Ca, Inc.

Andreas Gerhard Reiss

Erhan Giral

Corey Cohen

Mark Jacob Addleman

Marco Gagliardi

Michael Steven Walker

Tomas Kolda

David Brooke Martin

Zaneta Svozilova

Martin Janda

A system, method, and computer-readable storage medium are provided to automatically detect a root cause for an error that occurred during execution of functionality in a system. When a request is executed, a log associated with the execution of the request may be stored at the storage. The log may include information associated with a component associated with the execution of the request. Logs related to the same type of request may be compared with the executed request. Specifically, information associated with a component of the executed request may be compared with information associated with a component of the identified stored requests. When information associated with a component of the executed request does not match information associated with a component of the identified stored requests, a root cause for an error is associated with the associated component of the executed request.

System and method for automatic root cause detection

For each event detected during execution of a monitored application comprising a plurality of application components, a determination is made of which of the plurality of application components corresponds to the detected event. Also, a dependency subgroup that includes the application component that corresponds to the detected event is identified, wherein a dependency subgroup indicates dependencies among a subgroup of the plurality of application components. A location within the dependency subgroup of the application component corresponding to the detected event is determined. An order of correction for the application components determined to correspond to detected events are determined based, at least in part, on the determined location. Correction of the application components determined to correspond to detected events are initiated according to the determined order of correction.

Ordered correction of application based on dependency topology

Tracking health of component in a computer system is disclosed. A health score for software components is determined for each of a plurality of time periods. The computing system determines a problem software component whose health score indicates the unhealthy status at a certain point in time. The computing system determines a set of software components that are linked by dependency relationships to the problem software component. The computing system tracks events at which software components in the set have a health score that went from the healthy status to the unhealthy status. The computing system rolls back in time through the events to locate a software component in the set that was first in time to have its health score go from the healthy status to the unhealthy status.

Tracking health status in software components

Numerous alerts may be received by a management system, potentially making it difficult to determine which alerts indicate events that are potentially more harmful. To identify alerts that indicate harmful events, a damage index for each of the alerts may be determined. Determining an alert damage index facilitates the ranking, sorting, or graphical representation of alerts. The alert damage index can indicate the potential damage or harm an event associated with the alert may cause if left unaddressed. For example, a low memory event has the potential to cause an application or server to respond slowly or not at all. The alert damage index may be determined by processing metrics that indicate the potential harm or severity of the event. For example, the alert damage index may be determined by processing an alert duration factor, an alert threshold breach factor, and a component load factor (damage factors).

Alert damage index

A technique for detecting patterns in the execution of an application. The technique identifies a sequence of methods which are invoked and obtains information regarding attributes of the methods. For example, attribute information such as a class hierarchy can be obtained from an instrumentation API. A data structure representing a hierarchy of the attributes can be created and compared to one or more reference data structures which describe patterns of interest. A decision can be made to provide instrumentation for the methods having the matching attributes. The decision can consider how frequently the pattern is detected and overhead costs of the instrumentation.

Growing community of inventors

Frankfurt am Main, Germany

Andreas Gerhard Reiss