Node anomaly detection method and system, electronic equipment and storage medium

Abstract

The invention relates to the field of node anomaly detection, in particular to a node anomaly detection method and system, electronic equipment and a storage medium, and the method comprises the steps: presetting at least two application anomaly types; obtaining abnormal data of an abnormal application, and determining an application abnormal type of the abnormal application according to the abnormal data; acquiring operation information of a node deployed by the abnormal application; acquiring node analysis data related to the determined application exception type according to the operation information; and performing anomaly detection on the node according to the node analysis data to obtain an anomaly detection result. According to the method and the device, the node exception can be automatically and accurately sensed, and the high availability and the operation and maintenance efficiency of the node are remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of node anomaly detection, and more specifically, to a node anomaly detection method, system, electronic device, and storage medium. Background Technology

[0002] In distributed high-availability systems and networks, there exist multiple applications with service requirements and nodes deployed within these applications to fulfill those requirements. Nodes, as the core units of the service, undertake critical functions such as traffic processing, business logic execution, and data storage. When an application has a service requirement, it utilizes several pre-deployed nodes to distribute and complete the service. However, when the behavior, state, or performance of a node significantly deviates from the normal pattern or group expectations, exhibiting anomalous characteristics, it is considered an outlier. This outlier phenomenon can be caused by factors such as hardware failure, software errors, network problems, configuration errors, malicious attacks, or changes in the external environment. Node outliers directly undermine system or network stability: on the one hand, outlier nodes may cause request backlogs due to response delays or soaring error rates, thus affecting the overall service quality; on the other hand, if not isolated in time, their anomalous state may trigger a chain reaction of overload on peer nodes, or even cause cascading failures. Therefore, it is necessary to promptly identify outlier nodes to ensure system or network stability.

[0003] Existing technologies for detecting outlier nodes have significant shortcomings: First, manual operation and maintenance models are slow to respond, and relying on experience to judge node status is difficult to meet real-time requirements; second, traditional rule engines, based on static thresholds or simple month-on-month comparisons, cannot distinguish between global node operation fluctuations and single-point outlier anomalies, and lack fine-grained identification of different outlier scenarios, leading to blind or ineffective self-healing actions; while existing automatic detection systems generally suffer from core defects such as high false positive rates for outlier nodes and insufficient scenario differentiation, making it difficult to cope with complex outlier scenarios. Summary of the Invention

[0004] This invention provides a node anomaly detection method, system, electronic device, and storage medium, which enables automated and accurate perception of node anomalies, significantly improving node high availability and operational efficiency.

[0005] According to a first aspect of this application, a node anomaly detection method is provided, the method comprising: At least two application exception types are preset; Obtain abnormal data of abnormal applications, and determine the application abnormality type of the abnormal application based on the abnormal data; Obtain the runtime information of the nodes deployed by the abnormal application; Based on the operational information, obtain node analysis data related to the determined application anomaly type; Anomaly detection is performed on the nodes based on the node analysis data to obtain anomaly detection results.

[0006] Understandably, based on preset application anomaly types, it can accurately identify the failure modes of abnormal applications, providing a clear diagnostic direction for subsequent node analysis; by associating the operational information of the nodes deployed by the abnormal application and extracting node analysis data in combination with anomaly type characteristics, it can achieve penetrating tracing from application-layer symptoms to node-layer root causes; by dynamically adapting node analysis data and analysis strategies to different anomaly situations of different application anomaly types, it can effectively filter out interference from irrelevant operational information, quickly focus on real abnormal nodes in complex distributed environments, and reduce false alarm rates; the fully automated mechanism replaces traditional manual troubleshooting, compressing fault discovery time to the minute level, while reducing redundant operation and maintenance, significantly improving overall self-healing capabilities and service continuity assurance levels.

[0007] Optionally, the exception types include service timeout exception types and service timeout exception types; The step of obtaining node analysis data related to the determined application anomaly type based on the operational information includes: When the application anomaly type of the abnormal application is determined to be a service time consumption anomaly type based on the abnormal data, the maximum time consumption, average time consumption, and response status of the node in response to the service request are obtained as node analysis data related to the service time consumption anomaly type based on the running information. When the application exception type of the abnormal application is determined to be a service timeout exception type based on the abnormal data, the service processing time of the node is obtained based on the running information. Obtain the service timeout event based on the service processing time; Obtain the time when the service timeout event occurred and the number of service timeout events at each time. The time when the service timeout event occurred and the number of service timeout events at each time were used as node analysis data related to the service timeout exception type.

[0008] Understandably, by pre-setting two typical application anomaly scenarios—service latency anomalies and service timeout anomalies—a differentiated intelligent anomaly diagnosis system was constructed, significantly improving the efficiency of anomaly root cause localization. This system not only achieves millisecond-level discrimination of both types of anomalies but also significantly reduces the false alarm rate of anomaly detection. Through differentiated data analysis strategies targeting service latency anomalies and service timeout anomalies, accurate and efficient root cause localization was achieved. For service latency anomalies, the system extracts the maximum latency, average latency, and response status of a node in response to service requests as three core indicators to construct a multi-granularity performance description of the node: maximum latency exposes cases of extreme service processing latency, average latency reflects the overall efficiency of the service response, and response status identifies sudden changes in the node's error rate. The combination of these three effectively distinguishes between node-level performance degradation and sporadic fluctuations. For service timeout anomalies, service timeout event time-series analysis was introduced. By statistically analyzing the occurrence time and instantaneous frequency of service timeout events, transient anomaly characteristics such as sudden node traffic surges and resource exhaustion can be accurately captured. Trend analysis of the response performance of time-consuming anomaly-focused nodes, and judgment of the event density and timeliness of timeout anomaly-focused node processing tasks, thereby improving the accuracy of node anomaly detection and reducing the false alarm rate.

[0009] Optionally, before performing the step of obtaining the runtime information of the node where the abnormal application is deployed, the method further includes: Get the total number of timeout exceptions belonging to the service timeout exception type; When the total number of timeout exception applications is less than the timeout exception threshold, for exception applications belonging to the service timeout exception type, the step of obtaining the running information of the nodes deployed by the exception application is executed.

[0010] Understandably, this optimization mechanism significantly improves the efficiency of anomaly handling and the accuracy of alerts by introducing a threshold for the total number of timeout applications. When the total number of timeout applications is below the threshold, it indicates that the anomaly is minor and has a limited impact. Therefore, the step of obtaining the operational information of the nodes where the anomaly application is deployed is executed, and the nodes that experienced the anomaly are then automatically self-healed, completing the anomaly detection and automated operation and maintenance of the anomaly nodes. However, when the total number of timeout applications exceeds the threshold, it indicates that the anomaly is a major anomaly that may significantly affect the response and processing of the service. Specifically, an alert process can be immediately triggered to request manual intervention, minimizing the impact of the anomaly on the overall service response and processing tasks.

[0011] Optionally, before performing the step of obtaining the runtime information of the node where the abnormal application is deployed, the method further includes: Obtain the exception application that belongs to the service timeout exception type as the timeout exception application; From the timeout exception applications, obtain the number of the first exception applications belonging to the preset category of applications; When the number of the first abnormal applications is less than the first abnormal threshold, the step of obtaining the running information of the nodes deployed by the abnormal applications that belong to the preset category of applications is executed.

[0012] Understandably, by introducing a tiered management strategy for predefined application categories, the accuracy of anomaly handling and resource utilization efficiency are significantly improved. This application focuses on predefined application categories among timeout anomalies, such as core applications handling core business processes. By counting the number of first-order anomalies and comparing it with a first anomaly threshold, differentiated alarms and handling are achieved: if the number of first-order anomalies does not exceed the first anomaly threshold, it indicates that the anomaly only affects core business processes with relatively minor impact. Therefore, the step of obtaining the operational information of the nodes deployed by the anomaly application is executed, and subsequent automated self-healing is performed directly on the anomaly nodes, completing anomaly detection and automated operation and maintenance of anomaly nodes. This can improve the resilience of core business processes while shortening the mean time to recovery and reducing the manpower required for operation and maintenance. If the number of first-order anomalies exceeds the first anomaly threshold, an alarm process can be triggered to request manual intervention, minimizing the impact of the anomaly on overall service response and processing tasks, especially core business processes.

[0013] Optionally, before performing the step of obtaining the runtime information of the node where the abnormal application is deployed, the method further includes: Get the total number of applications with time-consuming exceptions that belong to the service time-consuming exception type; When the total number of time-consuming abnormal applications is less than the time-consuming abnormal threshold, the step of obtaining the running information of the nodes deployed by the abnormal application is executed for the abnormal application that belongs to the service time-consuming abnormal type.

[0014] Understandably, a preliminary screening is conducted based on the total number of applications with abnormal time consumption: when the total number of applications with abnormal time consumption is less than the time consumption exception threshold, only individual exception applications are analyzed and self-healed to complete the detection and repair of exception nodes; while when the total number of applications with abnormal time consumption reaches the time consumption exception threshold, an alarm process can be triggered to alert to the exception and request manual intervention to minimize the impact of the exception on service processing.

[0015] Optionally, when it is determined that the total number of time-consuming abnormal applications is greater than or equal to the time-consuming abnormal threshold, a second number of abnormal applications belonging to a preset category of applications is also obtained from the abnormal applications belonging to the service time-consuming abnormal type. When the number of the second abnormal applications is greater than the second abnormal threshold and less than the third abnormal threshold, then for the abnormal applications belonging to the preset category of applications, the step of obtaining the running information of the nodes deployed by the abnormal applications is executed.

[0016] Understandably, when the total number of time-consuming abnormal applications reaches the time-consuming abnormal threshold, in order to handle preset category applications, such as core applications, in a timely manner before manual intervention, this application achieves differentiated processing by statistically counting the number of second abnormal applications in the preset category and judging the interval between the second and third abnormal thresholds: if the number of second abnormal applications is within the interval between the second and third abnormal thresholds, it indicates that the number of preset category applications is not large, and the step of obtaining the running information of the nodes deployed by the abnormal applications can be performed on the preset category applications to quickly locate the root cause of the node abnormality, which facilitates the subsequent self-healing of the abnormal nodes based on the root cause; through an automated node self-healing process, the abnormal problems of the deployment nodes of the category applications can be quickly handled and resolved, ensuring the smooth operation of preset category applications, such as core applications, before manual intervention.

[0017] Optionally, the method further includes: When the corresponding node is determined to be an abnormal node based on the anomaly detection result, the abnormal node is self-healed according to the preset self-healing conditions. The self-healing process involves replacing the abnormal node with a new node, and the new node completes the service request of the abnormal node.

[0018] Understandably, the automated node replacement strategy enables seamless fault recovery and efficient resource utilization without the business being aware of it. When the anomaly detection result confirms a node anomaly, a self-healing process is triggered based on self-healing conditions, achieving a seamless switch between the new node and the abnormal node within seconds. This reduces node anomaly recovery time from the traditional hours to minutes, while significantly reducing the investment of operation and maintenance manpower, effectively ensuring the continuity of service response and processing.

[0019] According to a second aspect of this application, a node anomaly detection system is provided, the system comprising: An application exception type preset module is used to preset at least two application exception types; An application exception type determination module is used to acquire exception data of an abnormal application and determine the application exception type of the abnormal application based on the exception data. The runtime information acquisition module is used to acquire runtime information of the nodes deployed by the abnormal application; The node analysis data acquisition module is used to acquire node analysis data related to the determined application anomaly type based on the operation information. The detection module is used to perform anomaly detection on the node based on the node analysis data and obtain anomaly detection results.

[0020] According to a third aspect of this application, an electronic device is provided, comprising: Memory, used to store one or more computer programs; A processor, when the one or more computer programs are executed by the processor, implements the node anomaly detection method described in the first aspect above.

[0021] According to a fourth aspect of this application, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the node anomaly detection method described in the first aspect above.

[0022] Based on any of the above aspects, the node anomaly detection method, system, electronic device, and storage medium provided in this application embodiment preset at least two application anomaly types; acquires anomaly data of an abnormal application, determines the application anomaly type of the abnormal application based on the anomaly data; acquires the running information of the nodes deployed by the abnormal application; acquires node analysis data related to the determined application anomaly type based on the running information; performs anomaly detection on the nodes based on the node analysis data, and obtains anomaly detection results; the above method can achieve the following benefits: • Nodes achieve automated anomaly detection and self-healing, eliminating manual delays: By setting corresponding thresholds based on different node anomaly conditions, node anomaly detection and the entire process from anomaly to self-healing are achieved in seconds, eliminating the delays of traditional manual processing, improving the efficiency of handling abnormal nodes, and thus comprehensively enhancing overall disaster recovery capabilities and resource utilization efficiency.

[0023] • Improve the availability and reliability of response services: By monitoring application data and node data in real time, a self-healing mechanism is immediately triggered when an outlier node is detected as abnormal, effectively preventing the cascading impact of single node performance degradation, such as high latency and resource exhaustion, on the global service and avoiding the spread of local failures that lead to a decline in overall response capabilities; Automatically activate a backup new node for seamless replacement, achieving efficient resource reuse while ensuring that service capacity is not lost, and guaranteeing the availability and reliability of service response.

[0024] • Reduce node operation and maintenance costs and complexity: Based on automated anomaly detection and self-healing of nodes, it completely replaces traditional manual monitoring, fault diagnosis and emergency operation processes, effectively solving the manpower bottleneck problem in large-scale cluster management; it adopts multiple dynamic baselines and adaptive preset rules, eliminating the need to preset static thresholds or manually configure proportional rules, and can detect node status fluctuations in real time, such as the dynamic offset of the baseline during peak business periods, achieving zero manual maintenance of the rule base, and transforming operation and maintenance work from passive response to intelligent prediction, reducing node operation and maintenance costs and complexity while ensuring service stability. Attached Figure Description

[0025] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0026] Figure 1 This is a schematic application scenario diagram of a node anomaly detection method provided in this embodiment.

[0027] Figure 2 This is a flowchart of a node anomaly detection method provided in this embodiment.

[0028] Figure 3 This embodiment provides a process for handling timeout exceptions in applications. Figure 1 .

[0029] Figure 4 This embodiment provides a process for handling timeout exceptions in applications. Figure 2 .

[0030] Figure 5 This embodiment provides a process for handling time-consuming exceptions in applications. Figure 1 .

[0031] Figure 6 This embodiment provides a process for handling time-consuming exceptions in applications. Figure 2 .

[0032] Figure 7 This embodiment provides a flowchart for obtaining node analysis data related to the service timeout exception type.

[0033] Figure 8 This embodiment provides a functional module diagram of a node anomaly detection system.

[0034] Figure 9 This embodiment provides a schematic diagram of the electronic device. Detailed Implementation

[0035] The accompanying drawings are for illustrative purposes only and should not be construed as limiting the scope of this application. To better illustrate the following embodiments, some components in the drawings may be omitted, enlarged, or reduced, and do not represent the actual dimensions of the product; it is understandable to those skilled in the art that some well-known structures and their descriptions may be omitted in the drawings.

[0036] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0037] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0038] In distributed high-availability systems and networks, although basic disaster recovery and service processing capabilities are achieved through multi-node deployment and load balancing, traditional operation and maintenance models still face significant challenges. Manual operation and maintenance relies on experience to judge node status, resulting in delayed responses and susceptibility to subjective factors. Rule engines, based on static thresholds or simple month-on-month comparisons for alarm mechanisms, are prone to false alarms when global traffic fluctuations occur, such as when all nodes trigger rules simultaneously due to a sudden increase in traffic. Furthermore, they lack the ability to identify outlier scenarios such as slow degradation of a single node, where the latency of a single node does not exceed the static threshold but is significantly higher than that of other nodes. While existing threshold-based node self-healing systems can link monitoring and self-healing functions, they suffer from three major drawbacks: First, they have a high false positive rate. Global node anomalies, such as configuration changes or peak traffic periods, can lead to large-scale ineffective self-healing actions. Second, they may miss out on outliers, failing to differentiate between time-out outliers and those with excessive time consumption, resulting in a simplistic self-healing strategy. Third, their detection and location functions are disconnected from the self-healing process; the monitoring system only provides alerts without decision-making capabilities. The self-healing system relies on simple probes, potentially mistakenly identifying normal nodes while overlooking genuine outliers. This fragmented mechanism necessitates manual, sequential fault recovery, hindering real-time, closed-loop automation and making it inefficient in handling hidden faults like single-node outliers, severely impacting service continuity.

[0039] This embodiment provides a technical solution that can solve the above problems. The specific implementation of this application will be described in detail below with reference to the accompanying drawings.

[0040] An exemplary diagram illustrating an application scenario of a node anomaly detection method provided in this application embodiment is shown below. Figure 1 As shown, the application scenario includes at least a server 100 and a terminal 200 that can communicate with the server 100. The server 100 has functions such as data processing and data analysis; the terminal 200 has functions such as data acquisition, data processing, and data analysis.

[0041] Understandably, the server 100 can be an independent electronic device or a cluster of multiple electronic devices; the terminal 200 can be a smartphone terminal, personal computer, tablet computer, vehicle terminal, etc., but is not limited to these.

[0042] In one possible implementation, server 100 and terminal 200 may each execute a node anomaly detection method provided in the embodiments of this application. Alternatively, the node anomaly detection method provided in the embodiments of this application may be executed partly in server 100 and partly in terminal 200.

[0043] like Figure 2 As shown, this embodiment provides a node anomaly detection method, which can be further divided into the following steps: S100, Preset at least two application exception types; Understandably, in distributed high-availability architectures, multiple applications often exist to simultaneously complete different business services. Each application deploys multiple nodes to handle service requests. However, if an anomaly occurs while a node is processing a service request due to network failures, resource exhaustion, or other reasons, it will severely impact the stability of the service, potentially affecting the processing of other services and reducing overall efficiency. Therefore, timely repair of abnormal nodes or manual intervention to find solutions is crucial for the normal operation of distributed high-availability architectures.

[0044] Understandably, traditional anomaly detection typically only determines whether a node handling the service is an anomaly, and then performs simple self-healing on that node. This approach is not suitable for multiple anomaly scenarios and may also carry the risk of ineffective or excessive self-healing. In this embodiment, however, the problem is addressed by first judging the application deployed on the node. At least two application anomaly types are preset for each application, and the nodes deployed are analyzed according to different application anomaly types. This allows for accurate identification of the cause of node anomalies and the direction of repair, adapting to complex node anomaly scenarios and improving the efficiency and accuracy of node operation and repair.

[0045] Specifically, the exception types include service timeout exception types and service timeout exception types; In this embodiment, the application corresponding to the service timeout anomaly type refers to the situation where the time taken from receiving a service request to responding to the service request exceeds a preset timeout threshold. Applications with this situation will be judged to belong to the service timeout anomaly type. The application corresponding to the service timeout anomaly type refers to the situation where the time taken to process the service exceeds a preset timeout threshold. Applications with this situation will be judged to belong to the service timeout anomaly type.

[0046] Understandably, in this embodiment, abnormal applications are classified from two dimensions. Subsequently, based on the type of application abnormality, relevant node analysis data can be obtained from the node operation information to perform node abnormality analysis. This allows for accurate extraction of node analysis data to perform precise abnormality analysis on the nodes deployed by the abnormal application, enabling the identification of more accurate causes of node abnormalities, preventing misjudgments of node conditions, and facilitating subsequent self-healing repair.

[0047] S200. Obtain the abnormal data of the abnormal application, and determine the application abnormality type of the abnormal application based on the abnormal data; In this embodiment, different application anomaly types have pre-defined corresponding indicators. When an application meets the corresponding indicator, it belongs to the corresponding application anomaly type. Specifically, the anomaly data of the abnormal application needs to be compared with the indicators corresponding to each application anomaly type to find the matching application anomaly type. The anomaly data of the abnormal application can be obtained from a database that records application data. This database records in real time the circumstances under which an application becomes an abnormal application and the runtime data of the abnormal application. For example, if the time taken for an application to receive a service request and respond to that request is greater than the indicator corresponding to the service timeout anomaly type (which can be a timeout threshold), then the application belongs to the service timeout anomaly type. Similarly, if the time taken for an application to process a service is greater than the indicator corresponding to the service timeout anomaly type (which can be a timeout threshold), then the application belongs to the service timeout anomaly type. It is understood that if an application simultaneously meets the indicators corresponding to both the service timeout and service timeout anomalies, the application may belong to both types. Subsequent anomaly detection under both types is required to reduce the possibility of detection errors.

[0048] Specifically, such as Figure 3 As shown, for applications that fall under the service timeout exception type, the method further includes the following steps: S211. Obtain the total number of timeout exceptions belonging to the service timeout exception type; In this embodiment, S200 has already obtained the abnormal applications belonging to the service timeout exception type, and needs to obtain the total number of timeout exception applications belonging to the service timeout exception type as the data basis for subsequent detection.

[0049] S212. When the total number of timeout applications is less than the timeout threshold, for applications belonging to the service timeout exception type, the step of obtaining the running information of the nodes where the exception applications are deployed is executed. If the total number of timeout applications is greater than or equal to the timeout threshold, an alarm message is issued. In this embodiment, if the total number of timeout applications is greater than or equal to the timeout threshold, it indicates that the total number of timeout applications is large, and a large number of applications are exhibiting abnormal phenomena, far exceeding the processing capacity of the automated self-healing mechanism of this application, or that there is a global traffic fluctuation, and no special self-healing work is needed for individual nodes. In the above situations, alarm information needs to be issued and manual intervention is required to avoid the automated self-healing mechanism being unable to eliminate a large number of faults in a short time, and also to avoid blindly consuming unnecessary resources for self-healing in the face of global traffic fluctuations. If the total number of timeout applications is less than the timeout threshold, it indicates that the total number of timeout applications is small, and only a small number of applications are exhibiting abnormal phenomena. In this case, subsequent anomaly detection and processing can be performed on the nodes, and special self-healing work can be performed on individual nodes to enable the corresponding applications to quickly return to normal.

[0050] Understandably, the total number of timeout applications can be obtained by statistically analyzing the applications that fall under the service timeout exception type. The timeout exception threshold can be 50 or other numerical values, and can be adjusted appropriately based on actual circumstances.

[0051] Specifically, such as Figure 4 As shown, for applications that fall under the service timeout exception type, there is another implementation method, which includes the following steps: S221. Obtain the exception application that belongs to the service timeout exception type as the timeout exception application; S222. Obtain the number of first abnormal applications belonging to a preset category from the timeout abnormal applications; In this embodiment, the preset category application can be a core application. It is understood that different categories need to be preset for applications to highlight the importance of the business processed by the application. Different applications process different business tasks with varying importance, and the importance and timeliness of the service requests issued by these tasks will also differ. Preferably, the business processed by the application can be ordinary business or core business, and the category corresponding to applications processing ordinary business can be non-core applications, while the category corresponding to applications processing core business can be core applications. Preferably, core business is categorized by operations and maintenance personnel, who will pre-label applications as either "core application" or "non-core application" based on the core business. In cases of timeout exceptions, the number of the first exception applications belonging to the preset category (i.e., core applications) can be statistically obtained based on the label corresponding to each application.

[0052] S223. When the number of the first abnormal applications is less than the first abnormal threshold, for abnormal applications belonging to a preset category, the step of obtaining the running information of the nodes deployed by the abnormal applications is executed. If the number of the first abnormal applications is greater than or equal to the first abnormal threshold, an alarm message is issued.

[0053] In this embodiment, if the number of first abnormal applications is greater than or equal to the first abnormal threshold, it indicates that the number of core applications with timeout abnormalities is large, which may seriously affect core business. Using the automated self-healing mechanism of this application to process timeout preset category applications may not meet the timeliness requirements, or there may be global traffic fluctuations, and no special self-healing work is needed. In the above situation, an alarm message needs to be issued for manual intervention and judgment before processing, to avoid the automated self-healing mechanism being unable to eliminate a large number of faults in a short time, and also to avoid blindly consuming unnecessary resources for self-healing in the face of global traffic fluctuations. If the number of first abnormal applications is less than the first abnormal threshold, it indicates that the number of preset category applications with timeout abnormalities is not large. In this case, subsequent abnormal detection processing can be performed on the nodes, and special self-healing work can be performed on the nodes individually, so that the corresponding preset category applications can quickly return to normal.

[0054] It is understood that the first abnormal threshold can be 12 units or other numerical values, and the first abnormal threshold can be adjusted appropriately according to the actual situation.

[0055] Preferably, when using the method described in this application to detect and restore abnormal application deployment nodes, it is necessary to prioritize the detection and restoration of nodes deployed with preset application categories, so as to ensure that the preset application categories are processed in the shortest possible time and that the services of the preset application categories are restored to normal operation first.

[0056] Specifically, such as Figure 5As shown, for applications with abnormal service latency, the method further includes the following steps: S231. Obtain the total number of time-consuming exception applications belonging to the service time-consuming exception type; In this embodiment, S200 has already obtained the abnormal applications belonging to the service timeout abnormal type, and needs to obtain the total number of timeout abnormal applications belonging to the service timeout abnormal type as the data basis for subsequent detection.

[0057] S232. When the total number of time-consuming abnormal applications is less than the time-consuming abnormal threshold, for abnormal applications belonging to the service time-consuming abnormal type, the step of obtaining the running information of the nodes deployed by the abnormal application is executed. If the total number of time-consuming abnormal applications is greater than or equal to the time-consuming abnormal threshold, an alarm message is issued.

[0058] In this embodiment, if the total number of time-consuming abnormal applications is greater than or equal to the time-consuming abnormal threshold, it indicates that the total number of time-consuming abnormal applications is large, and a large number of applications are exhibiting abnormal phenomena, far exceeding the processing capacity of the automated self-healing mechanism of this application, or that there is a global traffic fluctuation, and no special self-healing work is required. In the above situations, alarm information needs to be issued for manual intervention to avoid the automated self-healing mechanism being unable to eliminate a large number of faults in a short time, and also to avoid blindly consuming unnecessary resources for self-healing in the face of global traffic fluctuations. If the total number of time-consuming abnormal applications is less than the time-consuming abnormal threshold, it indicates that the total number of time-consuming abnormal applications is small, and only a small number of applications are exhibiting abnormal phenomena. In this case, subsequent abnormal detection processing can be performed on the nodes, and special self-healing work can be performed on the nodes individually, so that the corresponding applications can quickly return to normal.

[0059] It is understood that the total number of applications with abnormal time consumption can be obtained by statistically analyzing the abnormal applications belonging to the service time consumption abnormality type. The time consumption abnormality threshold can be 6 or other numerical values, and the time consumption abnormality threshold can be adjusted appropriately according to the actual situation.

[0060] Specifically, such as Figure 6 As shown, for abnormal applications belonging to the service timeout exception type, there is another implementation method, which includes the following steps: S241. When it is determined that the total number of time-consuming abnormal applications is greater than or equal to the time-consuming abnormal threshold, the number of second abnormal applications belonging to a preset category of applications is obtained from the abnormal applications belonging to the service time-consuming abnormal type. In this embodiment, the preset category application can be a core application. According to the description in step S222, operations and maintenance personnel will pre-label applications as either "core applications" or "non-core applications" based on core business requirements. For applications with abnormal time consumption, the number of second abnormal applications belonging to the preset category (i.e., core applications) can be statistically obtained based on the label corresponding to each application.

[0061] S242. When the number of the second abnormal applications is greater than the second abnormal threshold and less than the third abnormal threshold, then for the abnormal applications belonging to the preset category of applications, the step of obtaining the running information of the nodes deployed by the abnormal applications is executed. Wherein the second abnormal threshold is less than the third abnormal threshold.

[0062] In this embodiment, if the number of second abnormal applications is greater than the second abnormal threshold and less than the third abnormal threshold, it indicates that the number of core applications included in the abnormal applications that prove to be of the service time consumption abnormal type is relatively small, and the core business affected is also relatively small. It can be directly determined that the above phenomenon is not caused by global traffic fluctuations. The number of preset category applications to be processed is within the processing capacity of the self-healing process. Therefore, the method described in this application can be used to detect anomalies in the nodes deployed by the preset category applications and perform self-healing on the abnormal nodes, which can restore the preset category applications and the corresponding abnormal nodes to a normal state.

[0063] Understandably, if the number of the second abnormal applications is less than the second abnormal threshold, it indicates that the abnormal applications belonging to the service timeout exception type contain very few core applications. In fact, when the second abnormal threshold is 0, the abnormal applications belonging to the service timeout exception type do not contain any core applications. Therefore, the scope of affected business is relatively small, and not handling the abnormal applications belonging to the service timeout exception type will not have a significant impact. Therefore, following the approach in step S232, only an alarm message is issued to remind operations personnel to monitor the situation closely. The processing and detection process will only proceed after other conditions are met.

[0064] Understandably, if the number of second-order abnormal applications exceeds the third-order threshold, it indicates that the abnormal applications belonging to the service timeout type include a large number of core applications. Therefore, the affected business scope, even the core business scope, is relatively large. Using the automated self-healing mechanism of this application to handle time-consuming pre-defined categories of applications may not meet the timeliness requirements, or may cause global traffic fluctuations, making it unnecessary to perform special self-healing work on individual nodes. In the above situations, alarm information needs to be issued for manual intervention to avoid the automated self-healing mechanism being unable to eliminate a large number of faults in a short time, and also to avoid blindly consuming unnecessary resources for self-healing during global traffic fluctuations.

[0065] It is understood that the second abnormal threshold can be 0 units or other numerical values, and the third abnormal threshold can be 6 units or other numerical values. The second and third abnormal thresholds can be adjusted appropriately according to the actual situation.

[0066] Understandably, if the judgment condition of S232 is not met in the abnormal applications belonging to the service time consumption anomaly type, it proves that the number of abnormal applications belonging to the service time consumption anomaly type is relatively small. It can be directly determined that the above phenomenon is not caused by global traffic fluctuations, and the number of abnormal applications to be processed is within the processing capacity of the self-healing process. Therefore, the method described in this application can be used to detect anomalies in the nodes where abnormal applications are deployed and to perform self-healing on the abnormal nodes, thereby restoring the abnormal application and the corresponding abnormal node to a normal state. Preferably, when using the method described in this application to detect and restore anomalies in the nodes where abnormal applications are deployed, priority should be given to detecting and restoring anomalies in the nodes where preset categories of applications are deployed, so as to ensure that the preset categories of applications are processed in the shortest possible time and that the service of the preset categories of applications is restored to normal.

[0067] S300: Obtain the running information of the nodes deployed by the abnormal application; In this embodiment, an application can deploy multiple nodes to complete service requests. When an application is determined to be an abnormal application, some of its deployed nodes may still be running normally. However, the abnormal nodes are affecting the application's normal service requests. Therefore, it is necessary to detect the abnormal nodes deployed in the abnormal application and obtain their corresponding operational information for subsequent self-healing and repair. In this embodiment, each node has a corresponding service that needs to be processed, so the operational information of each node is recorded. It is necessary to obtain the operational information of each deployed node in the abnormal application as the data basis for detecting that node.

[0068] S400. Obtain node analysis data related to the determined application anomaly type based on the operation information; In this embodiment, since the abnormal applications are classified as described above, including service timeout abnormality type and service timeout abnormality type, and the abnormal applications corresponding to different types may have different abnormalities and the time of occurrence of the abnormality, it is necessary to obtain relevant node analysis data according to the application abnormality type in order to determine whether the nodes deployed by the abnormal application have the corresponding abnormality type.

[0069] Specifically, the step of obtaining node analysis data related to the determined application anomaly type based on the operational information includes: When the application anomaly type of the abnormal application is determined to be a service time consumption anomaly type based on the abnormal data, the maximum time consumption, average time consumption, and response status of the node in response to the service request are obtained as node analysis data related to the service time consumption anomaly type based on the running information. In this embodiment, service time reflects the time an application takes from receiving a service request to responding to it. A service time anomaly occurs when the time taken from receiving a service request to responding to it exceeds a preset time threshold. Specifically, this can manifest as the time taken by the nodes deployed by the application from receiving a service request to responding to it exceeding the preset time threshold. Therefore, it is necessary to obtain the maximum time, average time, and response status of the nodes in responding to service requests based on the node's operational information as node analysis data related to the service time anomaly type.

[0070] It is understood that the maximum time, average time, and response status of the node in responding to service requests are based on a preset time interval, which is set by the operation and maintenance personnel as needed.

[0071] Specifically, such as Figure 7 As shown, the step of obtaining node analysis data related to the determined application anomaly type based on the operational information further includes the following steps: S410. When the application exception type of the abnormal application is determined to be a service timeout exception type based on the abnormal data, the service processing time of the node is obtained based on the running information. In this embodiment, service timeout reflects that the time required for an application to process a service exceeds a preset timeout threshold. Specifically, it can be manifested as the time required for the node deployed by the application to process the service exceeding the preset timeout threshold. Therefore, it is necessary to obtain the service processing time of the node based on the node's running information, and obtain node analysis data related to the service timeout exception type based on the service processing time.

[0072] S420. Obtain the service timeout event based on the service processing time; In this embodiment, when the service processing time of a node exceeds a preset timeout threshold, it is determined that the node has timed out and the event is identified as a service timeout event.

[0073] S430. Obtain the time when the service timeout event occurred and the number of service timeout events at each time. S440. The time when the service timeout event occurred and the number of service timeout events at each time were used as node analysis data related to the service timeout exception type.

[0074] In this embodiment, if a node experiences a small number of service timeout events at a given moment, this may be due to occasional errors. However, if a node experiences a large number of service timeout events at a given moment, it is necessary to pay attention to that node and determine whether an anomaly has occurred. Therefore, it is necessary to obtain the time when the service timeout events occurred and the number of service timeout events at each moment, and to count the number of service timeout events occurring at each moment for that node, using this as node analysis data related to the service timeout anomaly type.

[0075] S500. Based on the node analysis data, perform anomaly detection on the node to obtain anomaly detection results.

[0076] In this embodiment, the obtained node analysis data is analyzed to detect whether the node is an abnormal node. The abnormality of the abnormal node includes time consumption abnormality and timeout abnormality. Timeout abnormality can be further subdivided into continuous timeout abnormality and timeout spike abnormality.

[0077] Preferably, in one implementation, if the maximum time taken for a node to respond to a service request is greater than the maximum time-consuming threshold, and the average time taken for a node to respond to a service request is greater than the average time-consuming threshold, and the response status of the node to the service request is a service response timeout status, then the node is determined to have experienced a time-consuming anomaly.

[0078] It is understood that the response status of a node in response to a service request can include a normal service response status and a timeout service response status. In one implementation, if the time taken for a node to respond to a preset number of service requests exceeds a preset time threshold, the response status of the node in response to the service request is determined to be a timeout service response status. If the above condition is not met, the response status of the node in response to the service request is determined to be a normal service response status. It is understood that the preset number of time thresholds can be adjusted adaptively according to different applications and / or actual operating conditions.

[0079] In this embodiment, to determine if a node is abnormally timed, all three conditions mentioned above must be met simultaneously to avoid misjudgment due to a single condition: if only the maximum time taken for a node to respond to a service request is greater than the maximum time threshold, that is, only a single response to a single service is triggered with an excessively long time, it may be because the service has occasional big data request preparation or the service's temporary resources are contested. The above situation does not represent an abnormal node, but may be normal fluctuation.

[0080] If the average time taken for a node to respond to a service request is greater than the average time threshold, it may be because the average time taken for all nodes is high but has not reached the timeout state. It may be that the overall performance of all nodes has decreased due to excessive load, but has not reached the level of service failure. The above situation does not mean that the node is abnormal.

[0081] If the node's response status for a service request is "service response timeout," it may be due to network jitter, unreasonable client settings, or occasional errors. These situations do not necessarily indicate that the node is abnormal.

[0082] If all three conditions are met simultaneously, it is necessary to perform self-healing repair on the node, which can filter out occasional events, ensure that the anomaly is caused by a persistent problem due to insufficient processing capacity of the node.

[0083] For example, the maximum time threshold can be set to 40ms, and the average time threshold can be set to 10ms, wherein the maximum time threshold and the average time threshold can be adjusted appropriately according to the actual situation.

[0084] Preferably, in one implementation, if the number of service timeout events occurring at multiple times within a preset first time interval is greater than or equal to a preset number threshold, and the multiple times occur consecutively, then the node experiences a continuous timeout anomaly.

[0085] Understandably, to determine if a node is in a continuous timeout anomaly, all of the above conditions must be met simultaneously to avoid misjudgment due to a single condition: if only the number of service timeout events occurring at multiple times is greater than or equal to a preset threshold, but these multiple times occur sporadically and the interval between two adjacent times is far, then the concept of continuity is not met. This may be caused by network jitter of the node, contention for temporary resources required by the service, or other occasional factors, rather than a performance problem of the node itself.

[0086] For example, the preset first time interval can be set to 3 minutes, the number of multiple moments can be 3, and the preset number threshold can be set to 100. The preset first time interval, the number of multiple moments, and the preset number threshold can be adjusted appropriately according to the actual situation.

[0087] Preferably, in one implementation, if the number of service timeout events occurring at multiple times within a preset second time interval is greater than or equal to a preset threshold, then the node experiences a timeout spike anomaly.

[0088] Understandably, a timeout spike anomaly is characterized by a high density of service timeout events occurring within a short period, with the number of such events exceeding or equal to a preset threshold. Relying solely on the total number threshold might misclassify scattered service timeout events over a long period as timeout spike anomalies. The preset second time interval limits the time frame for anomaly occurrences, ensuring that service timeout events are dense and sudden, rather than scattered and isolated events. Since single or small numbers of service timeout events may be normal fluctuations such as network jitter or temporary load spikes, a preset second time interval is needed to distinguish these phenomena from timeout spike anomalies.

[0089] For example, the preset second time interval can be set to 6 minutes, the number of multiple moments can be 3, and the preset number threshold can be set to 100. The preset second time interval, the number of multiple moments, and the preset number threshold can be adjusted appropriately according to the actual situation.

[0090] Specifically, the method further includes: When the anomaly detection result determines that the corresponding node is an abnormal node, the abnormal node is self-healed according to the preset self-healing conditions. The self-healing process involves replacing the abnormal node with a new node, and the new node completes the service request of the abnormal node.

[0091] In this embodiment, when the anomaly detection result determines that the corresponding node is an abnormal node, the node needs to self-heal. Specifically, the detailed process of this self-healing repair is as follows: Check the application's elastic configuration. If elastic scaling is enabled, disable it to prevent the application from automatically optimizing scaling down during subsequent replacement processing. Perform scaling up on the application. After successful scaling up, remove abnormal nodes and introduce new normal nodes. Replace the network addresses of abnormal nodes with the network addresses of normal nodes, allowing the application to seamlessly switch to the new normal nodes while the abnormal nodes stop working and are removed. Finally, restore the application's elastic configuration to return the application to its normal state.

[0092] Preferably, in another embodiment, it also includes automated detection of node operation information, which can obtain the node's operation status in real time and verify the operation and repair of the self-healing process after the replacement of abnormal nodes, so as to ensure accurate grasp of the node's operation status at each moment.

[0093] Preferably, in a new embodiment, the self-healing process further includes a self-healing frequency control strategy. If the self-healing frequency is too high, frequent node replacements may affect normal operation and consume excessive computing resources; if the self-healing frequency is too low, it is not conducive to quickly repairing application anomalies. Therefore, the preset number of self-healing cycles satisfies the following formula: [max( a , floor(b* n )) / 1h ]&&[c times / d min] Where a is the number of normal self-healing cycles, b is the preset self-healing percentage, d is the time interval between c self-healing cycles, n is the total number of nodes deployed for the abnormal application, max(·) is the maximum value function, and floor(·) is the floor function.

[0094] For example, a can be 2, b can be 15%, c can be 1, and d can be 5. That is, each abnormal application can execute the node self-healing process at most once within 5 minutes, and at most max(2, floor(15%*n)) times within 1 hour.

[0095] Preferably, in another implementation, when the node self-healing process is executed for an abnormal application, if unexpected situations such as network anomalies or internal connection anomalies occur, errors may occur. Some of these errors require manual handling, while others do not. Therefore, in this embodiment, they will all be classified as suspected anomalies.

[0096] When a suspected anomaly occurs, we will place the abnormal application that is undergoing node self-healing into the blocking center. If necessary, we will stop its self-healing process until the suspected anomaly is confirmed to be harmless or has been repaired, and then we will unblock the application.

[0097] This application employs different application and node metrics, combined with node anomaly characteristics, to accurately identify abnormal nodes, achieving second-level node fault detection and isolation. It also ensures self-healing effectiveness and prevents "ineffective repairs" by automatically monitoring node traffic performance after switching. Regarding service stability, rapid replacement of abnormal nodes prevents the spread of single-point node failures. In terms of operational costs, the fully automated design replaces manual monitoring and operation, saving significant manpower for node maintenance. Technically, this method has multi-scenario scalability, supports the identification of novel outlier features such as disk I / O anomalies and memory leaks, and achieves seamless integration. This application overcomes the three major pain points of traditional node self-healing: high false positive rate, response delay, and fragmented processes, forming a complete closed loop of "detection, location, self-healing, and verification." Node anomaly detection provides a three-in-one solution of accurate second-level self-healing, unmanned operation and maintenance, and high availability assurance.

[0098] like Figure 8 As shown in the illustration, this application also provides a node anomaly detection system. Optionally, the system includes: The application exception type preset module 611, the application exception type determination module 612, the operation information acquisition module 613, the node analysis data acquisition module 614, and the detection module 615, wherein: Application exception type preset module 611 is used to preset at least two application exception types; In this embodiment, the application exception type preset module 611 can be used to execute... Figure 2 For a detailed description of the application exception type preset module 611 shown in step S100, please refer to the description of step S100.

[0099] Application anomaly type determination module 612 is used to acquire anomaly data of an abnormal application and determine the application anomaly type of the abnormal application based on the anomaly data; In this embodiment, the application exception type determination module 612 can be used to perform... Figure 2 For a detailed description of the application exception type determination module 612, see step S200 shown below. For a detailed description of step S200, please refer to the description of step S200.

[0100] The runtime information acquisition module 613 is used to acquire runtime information of the nodes deployed by the abnormal application; In this embodiment, the running information acquisition module 613 can be used to execute... Figure 2 For a detailed description of the operation information acquisition module 613, please refer to the description of step S300 shown.

[0101] The node analysis data acquisition module 614 is used to acquire node analysis data related to the determined application anomaly type based on the operation information. In this embodiment, the node analysis data acquisition module 614 can be used to perform... Figure 2 For a detailed description of the node analysis data acquisition module 614, see step S400 shown below. For a detailed description of step S400, please refer to the description of step S400.

[0102] The detection module 615 is used to perform anomaly detection on the node based on the node analysis data and obtain anomaly detection results.

[0103] In this embodiment, the detection module 615 can be used to perform... Figure 2 For a detailed description of the detection module 615, please refer to the description of step S500 shown.

[0104] This application also provides an electronic device, the structure of which is as follows: Figure 9 As shown, the electronic device includes a memory 711, a processor 712, a communication module 713, and an input / output interface 714, etc. Optionally, the memory 711, the processor 712, the communication module 713, and the input / output interface 714 can be connected and communicate with each other through a bus 715.

[0105] The memory 711 is used to store one or more computer programs and to transfer the code of the computer programs to the processor 712; when the one or more computer programs are executed by the processor 712, a node anomaly detection method in this application embodiment is implemented.

[0106] Optionally, the electronic device can be connected to a network via the communication module 713 to communicate with other devices, such as terminals or servers, and to interact with data. The electronic device can be various forms of digital computers, exemplarily such as desktop computers, servers, workbenches, mainframes, or other types of computers. The electronic device can also be various forms of mobile terminals, exemplarily such as smartphones, tablets, wearable devices (such as helmets, glasses, watches, etc.), and other similar mobile terminals.

[0107] Optionally, the electronic device can connect to desired input / output devices, such as a keyboard or display device, via the input / output interface 714. The electronic device itself may have a display device, and other display devices can also be connected externally via the input / output interface 714. Optionally, a storage device, such as a hard disk, can also be connected via the input / output interface 714 to store data from the electronic device, read data from the storage device, or store data from the storage device in the memory 711. It is understood that the input / output interface 714 can be a wired interface or a wireless interface. Depending on the actual application scenario, the device connected to the input / output interface 714 can be a component of the electronic device or an external device connected to the electronic device when needed.

[0108] Optionally, the memory 711 may be a volatile memory and / or a non-volatile memory. The volatile memory may be a random access memory, etc., and the non-volatile memory may be a read-only memory, a programmable read-only memory, an erasable programmable read-only memory, an electrically erasable programmable read-only memory, or a flash memory, etc.

[0109] Optionally, the computer program stored in the memory 711 can be divided into one or more modules, which are stored in the memory 711 and executed by the processor 712 to perform the method provided in this embodiment. The one or more modules can be a series of computer program instruction segments capable of performing specific functions, which describe the execution process of the computer program in the electronic device.

[0110] Optionally, the processor 712 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the processor 712 include, but are not limited to, a central processing unit, a graphics processing unit, a digital signal processor, various special-purpose artificial intelligence computing chips, various processors running machine learning model algorithms, and can also be any suitable controller, microcontroller, processor, etc. The processor 712 executes the various methods and processes of this embodiment, exemplarily, such as a node anomaly detection method according to an embodiment of this application.

[0111] Optionally, the bus 715 may include a path for transmitting information. Depending on its function, the bus 715 may be classified as an address bus, a data bus, a control bus, etc.

[0112] In an optional implementation, this application embodiment also provides a computer storage medium storing a computer program thereon, which, when executed by a computer, enables the computer to perform the methods described in the above-described method embodiments. Part or all of the computer program can be loaded and / or installed on the memory 711 of an electronic device. When the computer program is executed by the processor 712, one or more steps of a node anomaly detection method according to this application embodiment can be performed.

[0113] Optionally, the computer-readable storage medium may be a random access memory, a read-only memory, a programmable read-only memory, an erasable programmable read-only memory, an electrically erasable programmable read-only memory, etc.

[0114] Obviously, the above embodiments of the present invention are merely examples for clearly illustrating the technical solution of the present invention, and are not intended to limit the specific implementation of the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the claims of the present invention should be included within the protection scope of the claims of the present invention.

Claims

1. A method for detecting node anomalies, characterized in that, The method includes: At least two application exception types are preset; Obtain abnormal data of abnormal applications, and determine the application abnormality type of the abnormal application based on the abnormal data; Obtain the runtime information of the nodes deployed by the abnormal application; Based on the operational information, obtain node analysis data related to the determined application anomaly type; Anomaly detection is performed on the nodes based on the node analysis data to obtain anomaly detection results.

2. The method according to claim 1, characterized in that, The exception types include service timeout exception types and service timeout exception types; The step of obtaining node analysis data related to the determined application anomaly type based on the operational information includes: When the application anomaly type of the abnormal application is determined to be a service time consumption anomaly type based on the abnormal data, the maximum time consumption, average time consumption, and response status of the node in response to the service request are obtained as node analysis data related to the service time consumption anomaly type based on the running information. When the application exception type of the abnormal application is determined to be a service timeout exception type based on the abnormal data, the service processing time of the node is obtained based on the running information. Obtain the service timeout event based on the service processing time; Obtain the time when the service timeout event occurred and the number of service timeout events at each time. The time when the service timeout event occurred and the number of service timeout events at each time were used as node analysis data related to the service timeout exception type.

3. The method according to claim 2, characterized in that, Before performing the step of obtaining the runtime information of the node where the abnormal application is deployed, the method further includes: Get the total number of timeout exceptions belonging to the service timeout exception type; When the total number of timeout exception applications is less than the timeout exception threshold, for exception applications belonging to the service timeout exception type, the step of obtaining the running information of the nodes deployed by the exception application is executed.

4. The method according to claim 2, characterized in that, Before performing the step of obtaining the runtime information of the node where the abnormal application is deployed, the method further includes: Obtain the exception application that belongs to the service timeout exception type as the timeout exception application; From the timeout exception applications, obtain the number of the first exception applications belonging to the preset category of applications; When the number of the first abnormal applications is less than the first abnormal threshold, the step of obtaining the running information of the nodes deployed by the abnormal applications that belong to the preset category of applications is executed.

5. The method according to claim 2, characterized in that, Before performing the step of obtaining the runtime information of the node where the abnormal application is deployed, the method further includes: Get the total number of applications with time-consuming exceptions that belong to the service time-consuming exception type; When the total number of time-consuming abnormal applications is less than the time-consuming abnormal threshold, the step of obtaining the running information of the nodes deployed by the abnormal application is executed for the abnormal application that belongs to the service time-consuming abnormal type.

6. The method according to claim 5, characterized in that, When it is determined that the total number of time-consuming abnormal applications is greater than or equal to the time-consuming abnormal threshold, the number of second abnormal applications belonging to a preset category of applications is also obtained from the abnormal applications belonging to the service time-consuming abnormal type. When the number of the second abnormal applications is greater than the second abnormal threshold and less than the third abnormal threshold, then for the abnormal applications belonging to the preset category of applications, the step of obtaining the running information of the nodes deployed by the abnormal applications is executed.

7. The method according to any one of claims 1 to 6, characterized in that, The method further includes: When the corresponding node is determined to be an abnormal node based on the anomaly detection result, the abnormal node is self-healed according to the preset self-healing conditions. The self-healing process involves replacing the abnormal node with a new node, and the new node completes the service request of the abnormal node.

8. A node anomaly detection system, characterized in that, The system includes: An application exception type preset module is used to preset at least two application exception types; An application exception type determination module is used to acquire exception data of an abnormal application and determine the application exception type of the abnormal application based on the exception data. The runtime information acquisition module is used to acquire runtime information of the nodes deployed by the abnormal application; The node analysis data acquisition module is used to acquire node analysis data related to the determined application anomaly type based on the operation information. The detection module is used to perform anomaly detection on the node based on the node analysis data and obtain anomaly detection results.

9. An electronic device, characterized in that, include: Memory, used to store one or more computer programs; A processor, when the one or more computer programs are executed by the processor, implements a node anomaly detection method as described in any one of claims 1-7.

10. A computer-readable storage medium storing computer instructions for causing a processor to execute and implement a node anomaly detection method as described in any one of claims 1-7.

Images