Abstract: A failure analysis of a cloud based service is provided using synthetic measurements of the cloud based service. The synthetic measurements associated with a customer experience is executed on the cloud based service to determine a health of the cloud based service. The synthetic measurements simulate the customer experience which includes a use scenario of a customer of the cloud based service. Failures associated with the health of the cloud based service are aggregated, where the failures are detected from the synthetic measurements. A distribution is generated from the failures. The distribution is presented to a stakeholder.

Abstract: Systems, methods, and software are provided for dynamically escalating service conditions associated with data center failures. In one implementation, a monitoring system detects a service condition. The service condition may be indicative of a failure of at least one service element within a data center monitored by the monitoring system. The monitoring system determines whether or not the service condition qualifies for escalation based at least in part on an access condition associated with the data center. The access condition may be identified by at least another monitoring system that is located in a geographic region distinct from that of the first monitoring system. Upon determining that the service condition qualifies for escalation, the monitoring system escalates the service condition to an escalated condition and initiates an escalated response.

Abstract: Systems, methods, and software are provided for dynamically escalating service conditions associated with data center failures. In one implementation, a monitoring system detects a service condition. The service condition may be indicative of a failure of at least one service element within a data center monitored by the monitoring system. The monitoring system determines whether or not the service condition qualifies for escalation based at least in part on an access condition associated with the data center. The access condition may be identified by at least another monitoring system that is located in a geographic region distinct from that of the first monitoring system. Upon determining that the service condition qualifies for escalation, the monitoring system escalates the service condition to an escalated condition and initiates an escalated response.

Abstract: A failure analysis of a cloud based service is provided using synthetic measurements of the cloud based service. The synthetic measurements associated with a customer experience is executed on the cloud based service to determine a health of the cloud based service. The synthetic measurements simulate the customer experience which includes a use scenario of a customer of the cloud based service. Failures associated with the health of the cloud based service are aggregated, where the failures are detected from the synthetic measurements. A distribution is generated from the failures. The distribution is presented to a stakeholder.

Abstract: Technologies are generally provided for correlation of system alerts via deltas. Alert pairs may be generated by comparing each alert to the alerts surrounding it in time, up to a particular time window. The deltas for each pair may then be computed, and those sets of deltas analyzed to determine difference values in numeric terms. A threshold may be applied to the numeric values and alerts within a certain distance of each other may be considered to represent a correlation. Each alert may then be provided with all other related alerts, thus reducing a monitoring noise and making identification of the root cause of the alerts easier.

Abstract: Alerts based on detected hardware and/or software problems in a complex distributed application environment are mapped to recovery actions for automatically resolving problems. Non-mapped alerts are escalated to designated individuals or teams through a cyclical escalation method that includes a confirmation hand-off notice from the designated individual or team. Information collected for each alert as well as solutions through the escalation process may be recorded for expanding the automated resolution knowledge base.

Abstract: A multi-level monitoring system is provided for monitoring multiple performance aspects of a cloud service concurrently in order to generate a full and reliable performance analysis of the cloud service. The multi-level monitoring system may include a set of components for carrying out the performance analysis of the cloud service which may be deployed together to operate externally, internally, or concurrently with the cloud service. The component framework of the multi-level monitoring system may include a main component, a plug-in associated with the main component, a definition database, a log database, and an output database. The main components of an example multi-level monitoring framework may include a probe runner component for probing the cloud service, a monitor component for generating alerts based on probe results, and a responder component for processing the alerts and taking appropriate actions to improve the cloud service performance.

Abstract: Systems, methods, and software are provided for dynamically escalating service conditions associated with data center failures. In one implementation, a monitoring system detects a service condition. The service condition may be indicative of a failure of at least one service element within a data center monitored by the monitoring system. The monitoring system determines whether or not the service condition qualifies for escalation based at least in part on an access condition associated with the data center. The access condition may be identified by at least another monitoring system that is located in a geographic region distinct from that of the first monitoring system. Upon determining that the service condition qualifies for escalation, the monitoring system escalates the service condition to an escalated condition and initiates an escalated response.

Abstract: Architecture for aggregating health alerts from a number of related components into a single aggregated health state that can be analyzed to isolate the component responsible for the fault condition. In a hierarchy of related components within various component groups in a computer system, a number of health indicators can indicate alerts occurring in one or more of the related components whereas the fault condition occurs in only one component upon which the other components depend. The health indicators of related components are aggregated into an aggregated health state for each component group. These aggregated health states are analyzed to identify the related component associated with a root cause of the alert condition for an affected component group.

Abstract: A multi-level monitoring system is provided for monitoring multiple performance aspects of a cloud service concurrently in order to generate a full and reliable performance analysis of the cloud service. The multi-level monitoring system may include a set of components for carrying out the performance analysis of the cloud service which may be deployed together to operate externally, internally, or concurrently with the cloud service. The component framework of the multi-level monitoring system may include a main component, a plug-in associated with the main component, a definition database, a log database, and an output database. The main components of an example multi-level monitoring framework may include a probe runner component for probing the cloud service, a monitor component for generating alerts based on probe results, and a responder component for processing the alerts and taking appropriate actions to improve the cloud service performance.

Abstract: Architecture for aggregating health alerts from a number of related components into a single aggregated health state that can be analyzed to isolate the component responsible for the fault condition. In a hierarchy of related components within various component groups in a computer system, a number of health indicators can indicate alerts occurring in one or more of the related components whereas the fault condition occurs in only one component upon which the other components depend. The health indicators of related components are aggregated into an aggregated health state for each component group. These aggregated health states are analyzed to identify the related component associated with a root cause of the alert condition for an affected component group.

Abstract: Architecture for aggregating health alerts from a number of related components into a single aggregated health state that can be analyzed to isolate the component responsible for the fault condition. In a hierarchy of related components within various component groups in a computer system, a number of health indicators can indicate alerts occurring in one or more of the related components whereas the fault condition occurs in only one component upon which the other components depend. The health indicators of related components are aggregated into an aggregated health state for each component group. These aggregated health states are analyzed to identify the related component associated with a root cause of the alert condition for an affected component group.

Abstract: Alerts based on detected hardware and/or software problems in a complex distributed application environment are mapped to recovery actions for automatically resolving problems. Non-mapped alerts are escalated to designated individuals or teams through a cyclical escalation method that includes a confirmation hand-off notice from the designated individual or team. Information collected for each alert as well as solutions through the escalation process may be recorded for expanding the automated resolution knowledge base.

Abstract: Architecture for aggregating health alerts from a number of related components into a single aggregated health state that can be analyzed to isolate the component responsible for the fault condition. In a hierarchy of related components within various component groups in a computer system, a number of health indicators can indicate alerts occurring in one or more of the related components whereas the fault condition occurs in only one component upon which the other components depend. The health indicators of related components are aggregated into an aggregated health state for each component group. These aggregated health states are analyzed to identify the related component associated with a root cause of the alert condition for an affected component group.

Abstract: Automated multiple step tasks are executed on a computing device to analyze a computer system. A step engine performs a complex task such as troubleshooting, performance analysis, or disaster recovery as defined by an input file. The step engine parses the input file into individual steps and dispatches actions of the steps to another device for execution. The device returns a file with the results of the action. The step engine progresses through the list of steps and generates a log file representative of the actions taken and data collected during performance of the task.

Abstract: A flexible, extensible, uniform, and efficient framework for retrieving and analyzing data from a number of different data sources is disclosed. Instructions for retrieving and analyzing data are provided in a configuration file that is defined in a common format irrespective of the different data sources. The configuration file is submitted to a dispatcher, which uses the information therein to dispatch a number of data source collectors. Each such data source collector is unique to a corresponding data source and is able to formulate an efficient method for retrieving the necessary data from its corresponding data source. An analyzer then analyzes the retrieved data according to the instructions in the configuration file.

Abstract: A mechanism is described for allowing third party client applications to affect how high-level document commands are implemented in a database. After a high-level document command meeting certain criteria is received in a database management system, the system identifies one or more third party client application that are to be notified when such high-level document commands are received. The client applications are then notified allowing the client application to return implementation instructions which are used by the database management system in determining how to implement the high-level document command. The instruction may be to prevent implementation altogether, to somehow change the implementation, or even to perform high-level document commands in addition to the original high-level document command.

Abstract: A mechanism is described for the reliable notification to client applications of the implementation of predefined high-level document commands in a database. The database management system is issued a number of high-level document commands such as “move electronic mail message” or “add folder” which are to be implemented in the underlying database. As each high-level document command is implemented, an entry representing the high-level document command is set in a notification table stored in a persistent memory such as the database. The appropriate notification is then dispatched to any subscribing client applications. The client application then acknowledges to the database application that the notification has been received. In response, the entry is deleted in the notification table in the database. If the database management system were to fail, the system would check the notification table to see what notification it should send upon restarting.