Techniques are described herein for probabilistic monitoring of high-frequency, low-latency database queries. In some embodiments, a probabilistic query monitoring system periodically samples active database sessions. For example, the system may generate sample data every one second or at some other sampling rate for each database session that is currently active. The sample data may include a mapping between query identifiers to sample counter values that are extracted at different sample intervals. The system may then estimate performance metrics for the set of active database based on the counter values sampled across consecutive sample intervals.

In an example embodiment, a solution is provided that detects performance degradation of a particular functionality or an overall system problem using machine learning, Mann-Kendall tests, and correlation tests. After a problem has been automatically detected, the first steps of a root cause analysis may be automatically performed, indicating whether, for example non-optimal ABAP coding, a database issue, or hardware or software bottleneck, or some combination thereof. This approach allows a system to rapidly identify a system performance problem and its root cause by combing several data sources. One can see immediately, for example, whether an ABAP code change, an expensive SQL statement, or the combination of both led to an increase in the average response times of a transaction over time.

A method and system for detecting anomaly transition point candidates in performance metadata. The method can be applied to computer system performance monitoring. Anomaly candidates, indicative of a possible transition, of a process generating the performance metadata, to or from an anomalous behavior mode are identified, for example by comparing z-scores to the left and right of various timestamps and identifying anomaly candidates when the z-scores are significantly different. Anomaly candidates occur singularly rather than as pairs of endpoints of an anomaly interval. For at least one of the anomaly candidates, an explanatory predicate, indicative of a human-readable explanation of behavior of the process, can be generated. The set of anomalies can then be filtered, for example by removing those without explanatory predicates or replacing clusters of anomalies with a most relevant anomaly.

The present approach relates to event monitoring and management of an instance using a generated service map, allowing monitoring of CIs (e.g., applications) and connections that are currently active in a user's specific instance. A self-monitoring solution is generated for a user (e.g., via an application) that depicts status, configuration, and errors related to the user's instance. In certain implementations, the present techniques involve applying internal knowledge of the working of a user's instance and applications to perform the self-monitoring, and determine when an alert should be generated. Further, the present techniques may involve making a determination to provide a user with a self-help solution in addition or based on the self-monitoring of the user's instance.

A method for contactless payment relay attack protection includes receiving an online authorization request including a cryptogram, a measured processing time, and a reference processing time from a terminal. The cryptogram is verified, and a determination is performed as to whether the measured processing time exceeds the reference processing time. An online authorization response authorizing or declining a monetary transaction is transmitted, based on the determination. An artificial intelligence transaction analysis can be performed based on past and current conditions (e.g., battery level, operating system, open applications) of a payment device such as a mobile phone, past and current conditions of a terminal, and/or a monetary amount. The online authorization response can be based on the artificial intelligence transaction analysis.

An information processing system including Application Platform capable of communicating with Edge1 connected to each other to be able to communicate each other, in which Application Platform includes a second processor, information on microservices and data possessed by Edge1, and performance information describing the performance of Edge1, and the second processor uses predetermined data to combine a plurality of predetermined microservices and causes Edge1 to execute them in a predetermined order. When executing the application, microservices and data are moved between Edge1 based on the information of the microservices and the data possessed by Edge1, and the performance information.

Systems and methods for performance monitoring of distributed ledger nodes by data intake and query systems. An example method includes: receiving, by an application performance monitoring engine, from a distributed ledger node, values of a plurality of metrics reflecting operational parameters of one or more tasks performed by the distributed ledger node; determining, by analyzing a data set comprising the values of the plurality of metrics, a value of a performance parameter of the distributed ledger node; and generating an alert responsive to determining that the value of the performance parameter satisfies an alert triggering condition.

Examples described herein relate to method, resource management system, and non-transitory machine-readable medium for redeploying a computing resource. Data related to a performance parameter corresponding to a plurality of computing resources deployed on a plurality of host-computing nodes may be received. The performance parameter is associated with one or both of: communication between computing resources of the plurality of computing resources, or communication of the plurality of computing resources with a network device. Further, for a computing resource of the plurality of computing resources, a candidate host-computing node is determined from the plurality of host-computing nodes based on the data related to the performance parameter and the computing resource may be redeployed on the candidate host-computing node.

Example implementations relate to consensus protocols in a stretched network. According to an example, a distributed system includes continuously monitoring network performance and/or network latency among a cluster of a plurality of nodes in a distributed computer system. Leadership priority for each node is set based at least in part on the monitored network performance or network latency. Each node has a vote weight based at least in part on the leadership priority of the node. Each node's vote is biased by the node's vote weight. The node having a number of biased votes higher than a maximum possible number of votes biased by respective vote weights received by any other node in the cluster is selected as a leader node.

A testing system and method for testing application code against various failure scenarios. The testing system and method generate a test workflow including test source code implementing a series of actions that affect an application component and or an infrastructure component included in application code. The testing system and method execute the test workflow to determine the performance of the application code during one or more failure scenarios caused by the series of actions included in the test workflow. Performance data generated by the test code is analyzed by a performance analysis service or method to identify limitations of the application code and build resiliency patterns that address the limitations and improve the performance of the application code.