Abstract: A topology-based transversal analysis service has been created that correlates topologies of different domains of a distributed application and creates cross-domain “stories” for the different types of transactions provided by the distributed application. A “story” for a transaction type associates an event(s) with a node in an execution path of the transaction type. This provides context to the event(s) with respect to the transaction type (“transaction contextualization”) and their potential business impact. The story is a journal of previously detected events and/or information based on previously detected events. The events have been detected over multiple instances of a transaction type and the journal is contextualized within an aggregate of execution paths of the multiple instances of the transaction type. The story can be considered a computed, ongoing narrative around application and infrastructure performance events, and the narrative grows as more performance-related events are detected.

Abstract: A topology-based transversal analysis service has been created that correlates topologies of different domains of a distributed application and creates cross-domain “stories” for the different types of transactions provided by the distributed application. A “story” for a transaction type associates an event(s) with a node in an execution path of the transaction type. This provides context to the event(s) with respect to the transaction type (“transaction contextualization”) and their potential business impact. The story is a journal of previously detected events and/or information based on previously detected events. The events have been detected over multiple instances of a transaction type and the journal is contextualized within an aggregate of execution paths of the multiple instances of the transaction type. The story can be considered a computed, ongoing narrative around application and infrastructure performance events, and the narrative grows as more performance-related events are detected.

Abstract: A topology-based transversal analysis service has been created that correlates topologies of different domains of a distributed application and creates cross-domain “stories” for the different types of transactions provided by the distributed application. A “story” for a transaction type associates an event(s) with a node in an execution path of the transaction type. This provides context to the event(s) with respect to the transaction type (“transaction contextualization”) and their potential business impact. The story is a journal of previously detected events and/or information based on previously detected events. The events have been detected over multiple instances of a transaction type and the journal is contextualized within an aggregate of execution paths of the multiple instances of the transaction type. The story can be considered a computed, ongoing narrative around application and infrastructure performance events, and the narrative grows as more performance-related events are detected.

Abstract: A topology-based transversal analysis service has been created that correlates topologies of different domains of a distributed application and creates cross-domain “stories” for the different types of transactions provided by the distributed application. A “story” for a transaction type associates an event(s) with a node in an execution path of the transaction type. This provides context to the event(s) with respect to the transaction type (“transaction contextualization”) and their potential business impact. The story is a journal of previously detected events and/or information based on previously detected events. The events have been detected over multiple instances of a transaction type and the journal is contextualized within an aggregate of execution paths of the multiple instances of the transaction type. The story can be considered a computed, ongoing narrative around application and infrastructure performance events, and the narrative grows as more performance-related events are detected.

Abstract: 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).

Abstract: Changes in application topology can be determined, stored, analyzed and presented for evaluation as event journals. The information about inter-component calls can be recorded at multiple time instances, and then the component call information can be aggregated in different ranges or windows of time. Each aggregation of component call information can be used to determine different states of application topology, and the different states can be analyzed to determine changes between the application topology states and their relationship with performance degradations.

Abstract: 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).