Application fault repair result determination method, storage medium, and electronic device

Abstract

The application discloses a kind of applied fault repair result determination method, storage medium and electronic equipment.The method comprises: based on the multiple sets of target monitoring data of target application in current period, determine the fault detection result of target application in current period;In the case where the fault detection result is target application in current period exists fault, based on the multiple sets of historical monitoring data and multiple sets of target monitoring data of target application in historical period, determine the change characteristics of multiple sets of target monitoring data;Based on change characteristics, determine the target fault reason of target application in current period;Based on target fault reason, repair target application, determine the target repair monitoring data of target application;Target repair monitoring data is verified, and the fault repair result of target application is determined.The application solves the problems of insufficient fault reason diagnosis accuracy and insufficient fault repair result reliability in the application of related technology in the fault repair.

Description

Technical Field

[0001] This invention relates to the field of application operation monitoring technology, and more specifically, to a method for determining the fault repair results of an application, a storage medium, and an electronic device. Background Technology

[0002] The availability of modern distributed applications no longer depends solely on whether processes are alive or ports are accessible. An application that can still return Hypertext Transfer Protocol (HTTP) responses may already be experiencing states such as continuously increasing heap memory usage, database connection waiting, thread pool queuing, exhaustion of container worker threads, continuously deteriorating interface response time, or a rapid increase in business failure rate. These states typically do not immediately lead to process termination in the initial stages, but rather evolve gradually along the path of "increased resource pressure—request queuing—slower response—business failure—service unavailability." Related technologies have significant shortcomings in application fault diagnosis and recovery techniques, mainly in the following aspects:

[0003] Application internal runtime information exhibits significant heterogeneity. For example, Java Virtual Machine (JVM) heap memory usage is typically expressed as a percentage, while garbage collection (GC) is expressed as cumulative counts or cumulative time. Database connection pools include the number of active connections, idle connections, connection limit, and waiting threads. Thread pools include active threads, core threads, maximum threads, and queue length. Application Programming Interface (API) monitoring values ​​include response time, slow request ratio, HTTP status, and business response codes. The units, numerical ranges, sampling periods, and fault meanings of different monitoring values ​​vary, making it difficult to establish a unified assessment of application health by simply displaying them side-by-side. Root cause diagnosis relies solely on synchronous changes in monitoring values ​​or threshold alarms, easily confusing prior resource pressure with subsequent slow response and other consequential monitoring values, leading to a misrepresentation of root cause and symptom. Recovery verification lacks rigorous validation of continuous and stable improvement in root cause-related monitoring values. In summary, related technologies suffer from problems such as misinterpreting consequential monitoring values ​​as root causes and mistaking natural fluctuations for recovery during application fault repair.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This invention provides a method, storage medium, and electronic device for determining the results of fault repair in an application, in order to at least solve the technical problems that, in the process of fault repair, the result monitoring values ​​are mistakenly identified as the root cause and natural fluctuations are mistakenly identified as recovery.

[0006] According to one aspect of the present invention, a method for determining the fault repair result of an application is provided, comprising: determining a fault detection result of the target application in the current time period based on multiple sets of target monitoring data of the target application in the current time period, wherein the fault detection result is used to indicate whether the target application has a fault in the current time period, the multiple sets of target monitoring data correspond one-to-one with multiple health detection units in the target application, and the multiple sets of target monitoring data are obtained by standardizing the initial monitoring data output by the corresponding health detection units; if the fault detection result indicates that the target application has a fault in the current time period, determining the change characteristics of the multiple sets of target monitoring data based on multiple sets of historical monitoring data of the target application in historical time periods and the multiple sets of target monitoring data, wherein the multiple sets of historical monitoring data correspond one-to-one with the multiple sets of target monitoring data; determining the target fault cause of the target application in the current time period based on the change characteristics; repairing the target application based on the target fault cause and determining the target repair monitoring data of the target application; verifying the target repair monitoring data and determining the fault repair result of the target application, wherein the fault repair result is used to indicate whether the fault has been successfully repaired.

[0007] According to another aspect of the present invention, an application fault repair result determination device is also provided, comprising: a fault detection result determination module, configured to determine a fault detection result of the target application in the current time period based on multiple sets of target monitoring data of the target application in the current time period, wherein the fault detection result is used to indicate whether the target application has a fault in the current time period, the multiple sets of target monitoring data correspond one-to-one with multiple health detection units in the target application, and the multiple sets of target monitoring data are obtained by standardizing the initial monitoring data output by the corresponding health detection units; and a change feature determination module, configured to determine the change features of multiple sets of target monitoring data based on multiple sets of historical monitoring data of the target application in historical time periods and multiple sets of target monitoring data when the fault detection result indicates that the target application has a fault in the current time period, wherein the multiple sets of historical monitoring data correspond one-to-one with multiple sets of target monitoring data. The target fault cause determination module is used to determine the target fault cause of the target application in the current time period based on the change characteristics; the target repair monitoring data determination module is used to repair the target application based on the target fault cause and determine the target repair monitoring data of the target application; the fault repair result determination module is used to verify the target repair monitoring data and determine the fault repair result of the target application, wherein the fault repair result is used to indicate whether the fault was repaired successfully.

[0008] According to another aspect of the present invention, a non-volatile storage medium is also provided, which stores a plurality of instructions adapted for a method for determining the fault repair result of an application, any one of which is loaded and executed by a processor.

[0009] According to another aspect of the present invention, an electronic device is also provided, including one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement a method for determining the fault repair result of any one of the applications.

[0010] In this embodiment of the invention, a fault detection result for the target application in the current time period is determined based on multiple sets of target monitoring data. The fault detection result indicates whether a fault exists in the target application during the current time period. Each set of target monitoring data corresponds one-to-one with multiple health monitoring units within the target application. The multiple sets of target monitoring data are obtained by standardizing the initial monitoring data output by the corresponding health monitoring units. If the fault detection result indicates a fault in the target application during the current time period, the variation characteristics of the multiple sets of target monitoring data are determined based on multiple sets of historical monitoring data from previous time periods and the multiple sets of target monitoring data. Each set of historical monitoring data corresponds one-to-one with the multiple sets of target monitoring data. Based on these variation characteristics, the target application's fault in the current time period is determined. The system identifies the cause of the fault; based on the cause of the target fault, it repairs the target application and determines the target repair monitoring data for the target application; it then verifies the target repair monitoring data to determine the fault repair result of the target application. The fault repair result indicates whether the fault was successfully repaired. This achieves the goal of using multiple sets of standardized target monitoring data of the target application to determine the fault detection result of the target application in the current time period, so as to accurately determine the cause of the target fault and repair the target application. The system also verifies the repair monitoring data to determine whether the repair was successful. This achieves the technical effect of accurately diagnosing the cause of the fault and improving the reliability of the fault repair result in application fault repair, thereby solving the technical problems of insufficient accuracy in fault cause diagnosis and insufficient reliability of fault repair result in related technologies. Attached Figure Description

[0011] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0012] Figure 1 This is a flowchart of a method for determining fault repair results according to an embodiment of the present invention;

[0013] Figure 2 This is an optional application fault diagnosis and recovery verification overall technical architecture diagram according to an embodiment of the present invention;

[0014] Figure 3This is a flowchart of an optional application of a fault repair result determination method according to an embodiment of the present invention;

[0015] Figure 4 This is a schematic diagram of a fault repair result determination device according to an embodiment of the present invention;

[0016] Figure 5 This is a schematic diagram of an electronic device according to an embodiment of the present invention. Detailed Implementation

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

[0018] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention 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 the invention 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 a 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.

[0019] First, to facilitate understanding of the embodiments of the present invention, some terms or nouns involved in the present invention will be explained below:

[0020] The health monitoring unit is an independent component that performs monitoring on specific operational dimensions such as Java Virtual Machine (JVM), database connection pool, thread pool, application programming interface (API) response time, or business results.

[0021] Intervention identifiers are action identifiers and action times registered by humans or external automated systems when the intervention is completed, and are used to distinguish between pre-intervention and post-intervention samples.

[0022] According to an embodiment of the present invention, a method embodiment for determining the fault repair result of an application is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0023] Figure 1 This is a flowchart of a method for determining fault repair results according to an embodiment of the present invention, such as... Figure 1 As shown, the method includes the following steps:

[0024] Step S102: Based on multiple sets of target monitoring data of the target application in the current time period, determine the fault detection result of the target application in the current time period. The fault detection result is used to indicate whether there is a fault in the target application in the current time period. Multiple sets of target monitoring data correspond one-to-one with multiple health detection units in the target application. The multiple sets of target monitoring data are obtained by standardizing the initial monitoring data output by the corresponding health detection units.

[0025] Optionally, by collecting operational data from different dimensions within the application in parallel or independently through multiple independent health monitoring units, the raw data with varying formats output by different monitoring units can be converted into unified, standardized operational monitoring values. This solves the problem of heterogeneous data being unable to be directly compared and calculated. Using multiple sets of target monitoring data, combining standardized data from multiple dimensions avoids false alarms or missed alarms from single sets of data, improving the accuracy and comprehensiveness of fault detection. Standardization processing refers to the mapping and conversion process from heterogeneous data to unified, standardized monitoring values. Standardizing multiple sets of target monitoring data output by multiple health monitoring units can eliminate dimensional differences caused by different data sources, facilitating subsequent health status analysis and root cause analysis input. Using multiple sets of target monitoring data from the target application in the current time period ensures that the diagnosis is based on the latest system status, enabling the capture of recently occurred faults or deterioration in status. This step standardizes the initial monitoring data output by the health monitoring unit to generate standardized monitoring values ​​in a uniform format. This may include, but is not limited to, the following steps: recursively expanding the detail structure using the component name as the root path; standardizing the key path to a dot-separated format; converting 80.00% to 0.8; converting 1200ms to 1200; selecting the maximum value or summing similar monitoring values ​​from multiple data sources and multiple thread pools; and mapping to predefined standardized monitoring value keys. Table 1 shows an example of an optional standardization process for initial monitoring data (i.e., standardized indicator keys) according to an embodiment of the present invention.

[0026] Table 1

[0027]

[0028] In one optional embodiment, when multiple sets of target monitoring data each include multiple monitoring values, the fault detection result of the target application in the current time period is determined based on the multiple sets of target monitoring data for the current time period. This includes: determining the fault risk value corresponding to each of the multiple monitoring values ​​included in any set of target monitoring data in the current time period; determining the comprehensive fault risk value of any set of target monitoring data in the current time period based on the fault risk values ​​corresponding to each of the multiple monitoring values ​​in the current time period; determining the target fault risk value of the target application in the current time period based on the comprehensive fault risk value corresponding to each of the multiple sets of target monitoring data; and determining the fault detection result based on the target fault risk value.

[0029] Optionally, multiple sets of different target monitoring data can be quantified into fault risk values, thereby transforming them into a fault detection result that reflects the overall health status of the application. Specifically, firstly, multiple monitoring values ​​in a set of data are quantified into a standardized risk value. For any monitoring value included in any set of target monitoring data, the fault risk value can be obtained using the following piecewise function. :when When ≤0: =0; when 0 < ≤ hour: =a× / ;when < < hour: =a+b×( - ) / ( - );when ≥ hour: =1, where a represents the first preset weight coefficient and b represents the second preset weight coefficient. Represents any monitoring value, Indicates the early warning baseline. Indicates a severe baseline. > Next, based on the fault risk values ​​corresponding to each of the multiple monitoring values, the comprehensive fault risk value for the current period is obtained. Subsequently, the comprehensive fault risk values ​​corresponding to each group of targets are normalized and weighted to obtain the target fault risk value for the current period. The target fault risk value can be obtained in the following way. ,in, This represents the comprehensive fault risk value of any set of target monitoring data in the current time period. This represents the index of any set of target monitoring data. Indicates the index of the current time period. This indicates the total number of sets of target monitoring data. This represents the weighting coefficient of any set of target monitoring data. Finally, based on the target fault risk value, the fault detection result is determined according to the health level scoring standard. For example, if the target fault risk value is within the first preset risk value range, the fault detection result is determined to be in a healthy state; if the target fault risk value is within the second preset risk value range, the fault detection result is determined to be in a warning state; if the target fault risk value is within the third preset risk value range, the fault detection result is determined to be in a risk state; if the target fault risk value is within the fourth preset risk value range, the fault detection result is determined to be in a fault state. Here, the first preset risk value range is smaller than the second preset risk value range, the second preset risk value range is smaller than the third preset risk value range, the third preset risk value range is smaller than the fourth preset risk value range, and the first, second, third, and fourth preset risk value ranges do not overlap. This embodiment uses a fault risk value mapping function to reflect the gradual deterioration of the application. At the same time, by determining the comprehensive fault risk value, it can identify which specific set of target monitoring data has a problem, ensuring the dominance of critical faults. This avoids missing critical faults and false alarms, while ensuring that key dimensions have a decisive impact on the final result, and that fluctuations in non-key dimensions are reasonably filtered or have their weight reduced, thereby improving the sensitivity and accuracy of fault detection.

[0030] In one optional embodiment, determining the comprehensive fault risk value of any set of target monitoring data in the current time period based on the fault risk values ​​corresponding to each of the multiple monitoring values ​​in the current time period includes: determining the comprehensive fault risk value of any set of target monitoring data in the current time period based on the fault risk values ​​corresponding to each of the multiple monitoring values ​​in the current time period in the following manner:

[0031] ;

[0032] in, This represents the comprehensive fault risk value of any set of target monitoring data in the current time period. This represents the index of any set of target monitoring data. Indicates the index of the current time period. This represents the fault risk value of any monitoring value in any set of target monitoring data during the current time period. Represents the index of any monitored value.

[0033] Optionally, by aggregating multiple fault risk values ​​from the same set of target monitoring data, a comprehensive fault risk value function can be constructed, which can greatly improve the data processing efficiency. At the same time, the comprehensive fault risk value output by the comprehensive fault risk value function is a dimensionless, standardized value, making the scores of different technical dimensions comparable, thereby providing efficient data support for subsequent health status analysis.

[0034] Step S104: If the fault detection result indicates that the target application has a fault in the current time period, based on multiple sets of historical monitoring data of the target application in historical time periods and multiple sets of target monitoring data, determine the change characteristics of multiple sets of target monitoring data, wherein multiple sets of historical monitoring data correspond one-to-one with multiple sets of target monitoring data.

[0035] Optionally, by introducing historical monitoring data for comparison and change characteristic analysis, risks can be detected in advance. Calculating the start time of changes allows for the determination of temporal relationships, thus addressing the problem of simultaneously rising multiple monitoring values ​​failing to distinguish between root causes and symptoms, effectively reducing false alarms and improving the sensitivity and accuracy of fault detection. Retrieving historical monitoring data from different time periods as a reference elevates fault detection from static threshold judgment to dynamic trend analysis, thereby capturing the slope, confidence level, and key start times of changes in monitoring values, ultimately identifying progressive faults that are easily overlooked in related technical methods.

[0036] In one optional embodiment, when the fault detection result indicates that the target application is faulty in the current time period, the variation characteristics of multiple sets of target monitoring data are determined based on multiple sets of historical monitoring data of the target application in historical time periods and multiple sets of target monitoring data. This includes: when the fault detection result indicates that the target application is faulty in the current time period, determining the historical change slope corresponding to each of the multiple sets of historical monitoring data based on the multiple sets of historical monitoring data and the normalized historical time periods; determining the current change slope corresponding to each of the multiple sets of target monitoring data based on the multiple sets of target monitoring data and the normalized current time periods; and determining the change direction corresponding to each of the multiple sets of target monitoring data based on the historical change slope corresponding to each of the multiple sets of historical monitoring data and the current change slope corresponding to each of the multiple sets of target monitoring data, wherein the change direction is any one of the following: upward direction, downward direction, or stable direction; the variation characteristics include the change direction and current change slope corresponding to each of the multiple sets of target monitoring data.

[0037] Optionally, by calculating the slope of change in target monitoring data, the changing trend of target detection data is quantified. Then, the historical and current slopes of change for the same set of target monitoring data are compared to determine the direction of change for that set of target monitoring data, thus identifying the changing characteristics of that set of target detection data. Simultaneously, by introducing a time normalization mechanism, sampling points with unequal intervals are mapped to a unified time axis, ensuring the accuracy of the slope calculation. This allows for accurate quantification of the minute-by-minute change in monitored values ​​at any sampling frequency, overcoming the limitations of fixed-step-size calculations in related technologies. The normalized historical time period can be obtained as follows: ,in, This indicates the sampling duration corresponding to the historical time period. This represents the baseline sampling duration. The normalized current time period can be obtained by using a method that yields normalized historical time periods. Subsequently, the direction of change is determined based on the numerical relationship between the historical and current slopes. This embodiment identifies the directions of increase, stability, and decrease by calculating the slope, predicting risks, and issuing early warnings, thereby significantly improving the foresight of fault detection.

[0038] Optionally, the change characteristics are not limited to the change direction and current slope of each set of target monitoring data, but may also include: the absolute deviation of each set of target monitoring data from the historical baseline, the start time of change that led to the significant change in each set of target monitoring data, and the fitting confidence level reflecting the reliability of the trend. Specifically, by setting a minimum deviation threshold and a continuous sample number constraint, the critical moment when the monitored value changes from normal fluctuation to significant deviation from the baseline (i.e., the start time of change) is identified. Combined with the trend confidence level obtained from regression analysis, these characteristics constitute a complete set of change features describing the evolution of the monitored value, thus providing multidimensional evidence with temporal causal attributes to support subsequent root cause inference based on temporal sequence relationships. The start time of change for any set of target monitoring data can be calculated as follows: ,in, This represents the historical baseline of any set of target monitoring data. Indicates the relative deviation ratio. This represents the preset minimum deviation of any set of target monitoring data. This represents the index of any set of target monitoring data.

[0039] In one optional embodiment, the direction of change for each of the multiple sets of target monitoring data is determined based on the historical slope of change corresponding to each of the multiple sets of historical monitoring data and the current slope of change corresponding to each of the multiple sets of target monitoring data. This includes: determining the direction of change for any set of target monitoring data as a stable direction when the confidence level of the historical slope of any set of historical monitoring data is less than a preset confidence threshold, or when the confidence level of the current slope of any set of target monitoring data is less than a preset confidence threshold; or determining the direction of change for any set of target monitoring data as a stable direction when the confidence level of both the historical slope of change and the current slope of change of any set of historical monitoring data is greater than or equal to a preset confidence threshold, and the current slope of change of any set of target monitoring data is greater than the historical slope of change of any set of historical monitoring data. The direction is determined as upward; or, if the confidence levels of the historical slope and the current slope of any set of historical monitoring data are both greater than or equal to a preset confidence threshold, and the current slope of any set of target monitoring data is less than the historical slope of any set of historical monitoring data, then the direction of change for any set of target monitoring data is determined as downward; or, if the confidence levels of the historical slope and the current slope of any set of historical monitoring data are both greater than or equal to a preset confidence threshold, and the current slope of any set of target monitoring data is equal to the historical slope of any set of historical monitoring data, then the direction of change for any set of target monitoring data is determined as stable; by using the method of obtaining the direction of change for any set of target monitoring data, the direction of change for each of multiple sets of target monitoring data is obtained.

[0040] Optionally, by introducing a slope confidence threshold and a comparison mechanism between historical and current slope changes, a rigorous logic for determining the direction of change is constructed: when the confidence of the slope change at any stage is lower than a preset confidence threshold, it is uniformly determined to be a stable direction to avoid noise interference; only when the confidence of both sides meets the standard is the upward, downward, or stable state further distinguished based on the relationship between the current slope and the historical slope, thereby effectively filtering out misjudgments caused by data fluctuations or unreliable fitting, ensuring the accuracy of the direction of change identification, and providing reliable trend feature input for subsequent root cause inference based on time-series propagation evidence. This embodiment introduces a confidence threshold, and only performs direction determination when the statistical results are significantly reliable. If the data fluctuation is too large and a reliable trend cannot be fitted, it is directly determined to be stable, thereby effectively filtering sampling noise and random jitter, and avoiding misjudgments caused by discontinuous or unstable data.

[0041] Step S106: Based on the change characteristics, determine the cause of the target application's failure in the current time period.

[0042] Optionally, by utilizing the change characteristics to determine the cause of the target fault, this step can effectively overcome the technical defects in related technologies that rely solely on synchronous changes or statistical correlations of monitoring values, leading to misjudgments of the resulting monitoring values ​​as the root cause, and significantly improve the interpretability and accuracy of fault diagnosis.

[0043] In one optional embodiment, determining the target failure cause of the target application in the current time period based on the change characteristics includes: determining multiple initial failure causes of the target application in the current time period based on the change characteristics and a preset failure cause template library; determining a first monitoring value and a second monitoring value corresponding to each of the multiple initial failure causes, wherein the first monitoring value is used to indicate the failure source of the corresponding initial failure cause, and the second monitoring value is used to indicate the failure consequence of the corresponding initial failure cause; determining the failure propagation delay corresponding to each of the multiple initial failure causes based on the change start time of the first monitoring value and the change start time of the second monitoring value corresponding to each of the multiple initial failure causes; determining the initial failure causes within the preset propagation delay range among the failure propagation delays corresponding to each of the multiple initial failure causes as candidate failure causes; and determining the target failure cause based on the candidate failure causes.

[0044] Optionally, the initial fault cause and its corresponding fault propagation delay can be determined by identifying change characteristics, thereby identifying the target fault cause. Specifically, firstly, using the obtained change characteristics and a preset fault cause template library, multiple initial fault causes are initially listed. For each initial fault cause, the source of the fault is identified as the first monitoring value, and the fault consequence caused by the root cause is identified as the second monitoring value. Subsequently, the start time of the change of the first and second monitoring values ​​is determined, and the time difference between them is quantified to obtain the fault propagation delay. When the fault propagation delay falls within the preset propagation delay range, i.e., the cause occurs first and the time interval is reasonable, the initial fault cause can enter the next round of screening and become a candidate fault cause. Conversely, if the result monitoring value changes before the cause monitoring value, or the fault propagation delay is too long, the fault cause is excluded. Finally, the final target fault cause is determined from the candidate fault causes screened by the fault propagation delay.

[0045] In this embodiment, by forcibly filtering the fault propagation delay—that is, requiring the start time of the change in the cause monitoring value to be earlier than or equal to the delay of the result monitoring value, and the time interval to be within a reasonable range—it can be ensured that the target fault cause is logically valid in time, greatly improving the accuracy of the target fault cause diagnosis. During the target fault cause judgment process, the preset fault cause template library includes, but is not limited to: root cause code and name, current value condition, trend condition, temporal sequence condition, evidence weight of each condition, necessary condition identifier, minimum matching ratio, treatment suggestions, and a root cause-specific recovery monitoring value list.The root cause coding and naming are used to uniquely identify specific failure modes (such as database connection pool exhaustion or JVM memory leaks), and to achieve automated classification and retrieval of failure types through a standardized coding system. The current value condition defines the static threshold boundary required for a candidate root cause to be established, requiring the relevant monitoring value to be in an abnormal state in the current health snapshot (such as exceeding the warning baseline or severe baseline), used to exclude potential risks that, although showing a deteriorating trend, have not yet caused substantial impact. The trend condition, based on the historical slope and confidence level of the monitoring value, determines whether the monitoring value is continuously deteriorating (such as a continuous increase in connection pool utilization or a continuous rise in slow response ratio), aiming to capture the dynamic evolution of failures and distinguish between brief, transient fluctuations. The system addresses progressive failures with sustained destructive power, thereby enhancing early warning capabilities for potential risks. The temporal sequence condition is the core logic for distinguishing between root causes and symptoms. It requires that the change in the candidate cause's monitoring value must begin earlier than the resulting monitoring value, and that the failure propagation delay between the two falls within a preset range. By verifying this causal rule that causes precede results, it effectively prevents the erroneous attribution of slow response times or increased error rates in downstream operations to upstream resource pressures, thus solving the technical challenge of reversing root causes and symptoms. The evidence weights for each condition assign different confidence coefficients to different dimensions of judgment conditions, such as monitoring values, trends, and temporal sequences. This allows for dynamic adjustment of the evidence in the final diagnostic conclusion based on the importance or stability of the monitoring values. The contribution ratio in the evidence is adjusted, for example, by assigning higher weight to time-series evidence to enhance the reliability of causal inference, thereby achieving a more refined comprehensive confidence calculation; the necessary condition identifier clearly identifies which conditions in the root cause rule are hard constraints that must be strictly met. Failure to meet any necessary condition will directly lead to the exclusion of the candidate root cause, regardless of whether other supplementary conditions match. This mechanism ensures the rigor of the diagnostic logic and avoids false alarms caused by minor feature matching; the minimum matching ratio sets a lower threshold for the comprehensive evidence matching degree. Only when the weighted evidence matching ratio exceeds this threshold is the current root cause considered valid. This mechanism is used to filter out weakly correlated candidates with insufficient evidence or ambiguity, ensuring that the final output root cause has sufficient statistical significance. The system possesses significant and business-relevant value; the handling recommendations, based on the identified root cause type, provide standardized operation and maintenance guidelines or remediation strategies (such as increasing the database connection pool size or investigating code memory leaks), helping operations and maintenance personnel quickly understand the fault mechanism and implement corresponding intervention measures, thus shortening the average repair time; the root cause-specific recovery monitoring value list is subordinate to the main root cause rule, clearly listing the set of key monitoring values ​​that need to be monitored and verified after the handling is completed. These monitoring values ​​not only include core monitoring values ​​that directly reflect the root cause of the fault (such as connection pool utilization), but also result-oriented monitoring values ​​affected by them (such as interface response time), providing clear observation objects and judgment criteria for subsequent recovery verification steps, ensuring the pertinence and effectiveness of recovery effect verification.

[0046] In one optional embodiment, when there are multiple candidate fault causes, the target fault cause is determined based on the candidate fault causes, including: determining the fault confidence level corresponding to each of the multiple candidate fault causes; and determining the candidate fault cause whose fault confidence level is greater than a preset fault confidence level threshold among the multiple candidate fault causes as the target fault cause.

[0047] Optionally, the final target fault cause can be selected by quantifying the probability of each candidate fault cause being the root cause and comparing its corresponding confidence level with a preset confidence threshold. For example, the fault confidence level of any candidate fault cause can be obtained in the following way. ,in, The rule-based evidence matching ratio represents the probability of finding the cause of any candidate failure. This represents the total number of rule conditions in the rule condition set, where j represents the index of any one of the rule conditions. This represents any rule condition. This represents the weight of any rule condition. This represents the matching function. This represents the evidence matching ratio for any candidate fault cause, where m represents the index of any time series condition among multiple time series conditions. The weight represents any time-series condition. This represents any temporal condition. In this embodiment, threshold filtering can filter out candidate fault causes that, while conforming to temporal logic, lack sufficient evidence and have low reliability. This allows for precise identification of the most critical and well-supported fault source, thereby improving the accuracy, feasibility, and operational efficiency of root cause diagnosis. It also avoids indiscriminate treatment of multiple potential causes or misjudgment of low-confidence causes. Furthermore, confidence level is a comprehensive measurement combining current monitoring evidence, trend evidence, and temporal propagation evidence. This means that the root cause determination can be dynamically adjusted based on the strength of the evidence. This multi-dimensional weighted evaluation improves the reliability of root cause determination.

[0048] Step S108: Based on the cause of the target failure, repair the target application and determine the target repair monitoring data of the target application.

[0049] Optionally, based on the identified cause of the target failure, corresponding repair strategies (such as adjusting connection pool parameters and clearing thread backlog) are executed to eliminate the root cause of the failure. After the repair action is completed, the health monitoring unit continuously collects the target application's running status data during the post-repair period to form target repair monitoring data. This process not only enables closed-loop management from fault diagnosis to disposal execution, but also provides an objective data basis for subsequent recovery verification with the acquired target repair monitoring data, ensuring the authenticity and stability of the target application's health status, and ultimately achieving accurate quantification and automatic verification of the fault disposal effect.

[0050] In one optional embodiment, based on the cause of the target failure, the target application is repaired to determine the target repair monitoring data of the target application, including: determining the target application's monitoring data to be repaired based on the cause of the target failure; obtaining the intervention identifier and intervention duration of the target application, wherein the intervention identifier is used to indicate the repair action of the monitoring data to be repaired, and the intervention duration is used to indicate the execution duration of the repair action; repairing the monitoring data to be repaired based on the intervention identifier and intervention duration to obtain the first repair monitoring data of the target application; determining the target monitoring data other than the first repair monitoring data from multiple sets of target monitoring data as the second repair monitoring data; and obtaining the target repair monitoring data based on the first repair monitoring data and the second repair monitoring data.

[0051] Optionally, by introducing external intervention identifiers and intervention durations as time boundary markers, the application repair process is strictly divided into two independent data intervals: before and after repair. The intervention identifier clarifies the specific treatment action, while the intervention duration defines the effective time window for the repair operation. Based on this, monitoring data whose timestamps are later than the intervention duration after the repair action is completed are identified as the first repair monitoring data reflecting the repair effect. Simultaneously, other background monitoring data not directly altered by the repair action or used as a control are retained as the second repair monitoring data, thus constructing the target repair monitoring data. This embodiment, by establishing strict data verification boundaries between pre- and post-treatment data, ensures that subsequent recovery verification is based solely on data samples verified by the repair action, effectively eliminating interference from natural load fluctuations or irrelevant dimensional improvements on the diagnostic results. Furthermore, by distinguishing between direct repair monitoring values ​​(first repair monitoring data) and indirectly related monitoring values ​​(second repair monitoring data), a refined evaluation of the repair effect can be achieved, ensuring the objectivity, accuracy, and traceability of the fault recovery determination.

[0052] Step S110: Verify the target repair monitoring data to determine the fault repair result of the target application, wherein the fault repair result is used to indicate whether the fault has been successfully repaired.

[0053] Optionally, to comprehensively evaluate the fault repair results of the target application, multi-level recovery verification logic is executed. Specifically, in judging the overall status improvement, the post-treatment snapshot must simultaneously meet three core conditions: the improvement in the comprehensive score is not less than the preset minimum improvement value; the current health level is improved compared to the abnormal baseline; and the predicted health level is in a healthy or warning state, excluding the possibility of still being in a risky or faulty state. To verify whether the core monitoring values ​​have been successfully repaired and to confirm that no new faults have appeared in the background monitoring values, one of two judgment mechanisms is adopted for the root cause-specific recovery monitoring values: one is value improvement judgment, that is, the post-treatment monitoring value is not higher than the pre-treatment monitoring value multiplied by the minimum improvement ratio coefficient; the other is slope improvement judgment, that is, the pre-treatment monitoring value shows an upward trend, and the post-treatment monitoring value slope drops to zero, a negative value, or does not exceed the pre-treatment slope multiplied by the allowed retained slope ratio. The root cause evidence recovery ratio is calculated by the ratio of the number of evaluable recoverable monitoring values ​​to the number of monitoring values ​​that meet the improvement conditions. Only when the root cause evidence recovery ratio is not lower than the preset threshold is the root cause evidence monitoring value condition considered to be met. Finally, the fault repair results are encapsulated into a standard health response body. While retaining the original basic fields such as timestamp, overall status, number of components, and details, new intelligent analysis fields are added to provide in-depth insights: displaying the comprehensive health level; providing standardized monitoring values, dimensional scores, and comprehensive score details; revealing the current and predicted levels, score trends, monitoring value trends, and risk arrival time; presenting the primary root cause, candidate root causes, multi-dimensional evidence chains (current value, trend, time-series propagation), and treatment suggestions; and recording the primary root cause, intervention identifier, number of consecutive passes, root cause evidence recovery ratio, and current recovery status (including not tracked, awaiting intervention, under verification, under observation, recovered, or worsened).

[0054] Through the above steps S102 to S110, the goal is to use multiple sets of target monitoring data that have been standardized to determine the fault detection results of the target application in the current time period, so as to accurately determine the cause of the target fault and repair the target application. The purpose is to verify the repair monitoring data to determine whether the repair is successful. This achieves the technical effect of accurately diagnosing the cause of the fault and improving the reliability of the fault repair results in application fault repair, thereby solving the technical problems of insufficient accuracy in fault cause diagnosis and insufficient reliability of fault repair results in related technologies.

[0055] Based on the above embodiments and optional embodiments, the present invention proposes an optional technical architecture. Figure 2 This is an optional application fault diagnosis and recovery verification overall technical architecture diagram according to an embodiment of the present invention, such as... Figure 2 As shown in the diagram, this illustrates a complete automated process for monitoring and verifying the health status of a business application system. Specifically, it includes:

[0056] The entire process begins with the top-level entity of the business application system, representing any running Spring Boot application or other similar application. Runtime data is collected internally by a runtime state awareness layer module. This runtime state awareness layer is a comprehensive data collector that gathers information from multiple key dimensions: the JVM layer, monitoring heap memory, garbage collection, and CPU usage; the database connection pool, focusing on its utilization and the number of waiting threads; the thread pool, monitoring its activity and queue length; the web container, collecting connection counts and worker thread status; and API and business results, recording API latency, response delays, and the number of business failures. All this raw monitoring data is aggregated into a standardized metrics processing module, where it undergoes unified path standardization, unit conversion, and aggregation of similar resources to ensure data standardization and comparability. The standardized data is then fed into the HealthSnapshot building module, which is responsible for a comprehensive assessment of the system's health status. It performs dimensional scoring, comprehensive scoring, and ultimately determines the system's health level, generating a health snapshot representing the system's current state. These snapshots are stored in a fixed-length historical state repository, forming a continuous, time-ordered HealthSnapshot trajectory. This historical data warehouse serves as the foundation for subsequent analysis and verification.

[0057] From the historical data repository, the system begins in-depth intelligent analysis. First, the evolution and change event analysis module identifies the evolving trend of the system's health status, analyzing the slope, confidence level, and the start time of the change to determine whether the state is deteriorating or recovering. Based on these analysis results, the system enters the time-series propagation evidence root cause inference stage. This stage infers the root cause of the current state by analyzing the current intensity, trend, and related constraints. Subsequently, the system enters the root cause-specific recovery verification template stage. Based on the inferred root cause, it invokes a preset verification template, which includes specific evidence indicators, the expected recovery direction, and a window period for determining whether the recovery is stable.

[0058] Guided by the verification template, the system performs continuous recovery verification, including reverse evidence verification (confirming the fault has been resolved), state safety checks (ensuring system stability), and multiple consecutive verifications (e.g., K times) (confirming the problem has been completely resolved). Simultaneously, the system performs post-processing snapshots on data in a fixed-length historical state repository and, through a mechanism of continued writing after verification, writes the new snapshots (including the post-processing state) back to the historical repository, forming a closed loop. If verification is successful, the system passes the result recovery criteria to the enhanced health service interface, which not only accommodates state and diagnostic evidence but also provides recovery results. Finally, all processing actions (whether automated or manual intervention) are recorded on the monitoring platform, maintenance platform, or automated processing system. Furthermore, the system creates an external processing marker to record key time boundary points in manual or automated processes. The entire process forms a complete automated closed loop from data acquisition, state construction, root cause analysis, verification recovery to result output and recording.

[0059] Based on the above embodiments and optional embodiments, the present invention proposes an optional implementation method. Figure 3 This is a flowchart of an optional application of the fault repair result determination method according to an embodiment of the present invention, such as... Figure 3 As shown, the method includes:

[0060] S1: Obtain health detection results from multiple operational dimensions and perform normalization processing. Specifically, this includes: receiving health detection requests, or periodically executing health detection by internal timed tasks to collect information, extracting standardized monitoring values ​​and standardizing numerical values ​​to obtain multiple sets of target monitoring data for the target application. The specific implementation process is the same as in the aforementioned embodiments and will not be repeated here.

[0061] S2: Determine the fault detection results corresponding to each of the multiple sets of target monitoring data. Specifically, this includes: obtaining risk values ​​from multiple sets of different target monitoring data using a piecewise function, calculating the corresponding fault risk values, and then obtaining the fault detection results. The specific implementation process is the same as in the aforementioned embodiment, and will not be repeated here.

[0062] S3: Based on multiple sets of historical monitoring data and multiple sets of current monitoring data of the target application, obtain the slope and direction of change of multiple sets of target monitoring data. The specific implementation process is the same as the aforementioned embodiment, and will not be repeated here.

[0063] S4: Based on the slope and direction of change, determine the target failure cause of the target application in the current time period. Specifically, this includes: determining multiple initial failure causes based on a preset failure cause template library, and after calculating the failure propagation delay, filtering out candidate failure causes within the preset propagation delay range, and then performing failure confidence calculation to determine the target failure cause. The specific implementation process is the same as the aforementioned embodiment and will not be repeated here.

[0064] S5: Repair the target application and determine the fault repair result of the target application. Specifically, when the cause of the target fault is determined, the target repair monitoring data is obtained by using the intervention identifier and intervention duration, and the target repair monitoring data is repaired to determine the fault repair result. The specific implementation process is the same as the above embodiment, and will not be repeated here.

[0065] This embodiment also provides an application fault repair result determination device, which is used to implement the above embodiments and preferred embodiments, and will not be repeated as already described. As used below, the terms "module" and "device" can refer to a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0066] According to embodiments of the present invention, an apparatus embodiment for determining the fault repair result method for implementing the above-described application is also provided. Figure 4 This is a schematic diagram of a fault repair result determination device according to an embodiment of the present invention, as shown below. Figure 4 As shown, the fault repair result determination device for the above application includes: a fault detection result determination module 200, a change characteristic determination module 202, a target fault cause determination module 204, a target repair monitoring data determination module 206, and a fault repair result determination module 208, wherein:

[0067] The fault detection result determination module 200 is used to determine the fault detection result of the target application in the current period based on multiple sets of target monitoring data of the target application in the current period. The fault detection result is used to indicate whether there is a fault in the target application in the current period. The multiple sets of target monitoring data correspond one-to-one with multiple health detection units in the target application. The multiple sets of target monitoring data are obtained by standardizing the initial monitoring data output by the corresponding health detection units.

[0068] The change feature determination module 202 is connected to the fault detection result determination module 200. It is used to determine the change features of multiple sets of target monitoring data based on multiple sets of historical monitoring data of the target application in historical periods and multiple sets of target monitoring data when the fault detection result indicates that the target application has a fault in the current period. The multiple sets of historical monitoring data correspond one-to-one with the multiple sets of target monitoring data.

[0069] The target failure cause determination module 204 is connected to the change feature determination module 202 and is used to determine the target failure cause of the target application in the current time period based on the change features.

[0070] The target repair monitoring data determination module 206 is connected to the target fault cause determination module 204 and is used to repair the target application based on the target fault cause and determine the target repair monitoring data of the target application.

[0071] The fault repair result determination module 208 is connected to the target repair monitoring data determination module 206. It is used to verify the target repair monitoring data and determine the fault repair result of the target application. The fault repair result is used to indicate whether the fault has been successfully repaired.

[0072] According to an embodiment of the present invention, a system embodiment for determining the fault repair result for implementing the above-described application is also provided. The system includes: a set of health monitoring units, a standardized monitoring value extraction module, a health status snapshot construction module, a health status history repository, a health status evolution analysis module, a monitoring value change event analysis module, a time-series propagation root cause reasoning module, a root cause-specific recovery template module, an intervention marking module, a continuous recovery verification module, and a health service interface module, wherein:

[0073] The system comprises the following modules: a health monitoring unit set for collecting monitoring data across various technical dimensions and maintaining anomaly isolation between units; a standardized monitoring value extraction module for recursive flattening, unit parsing, monitoring value path mapping, and aggregation of similar resources; a health status snapshot construction module for risk normalization, dimension scoring, missing dimension re-normalization, and comprehensive scoring; a health status history repository for storing continuous snapshots in a fixed-length structure; a health status evolution analysis module for calculating scoring trends, monitoring value trends, future states, and risk arrival times based on actual sampling times; a monitoring value change event analysis module for calculating baselines, significant deviations, continuous samples, and change start times; a time-series propagation root cause inference module for generating candidate root causes and evidence chains based on current intensity, trends, and sequential time delays; a root cause-specific recovery template module for determining the monitoring values ​​to be tracked and the expected improvement direction from the main root cause rules; an intervention marking module for registering external treatment action identifiers and times, and classifying samples before and after treatment; a continuous recovery verification module for comparing root cause monitoring values, overall state, and future state, requiring a continuous and stable window; and a health service interface module for compatible output, intervention registration, and access control.

[0074] It should be noted that the above modules can be implemented by software or hardware. For example, for the latter, it can be implemented in the following ways: the above modules can be located in the same processor; or the above modules can be located in different processors in any combination.

[0075] It should be noted that the fault detection result determination module 200, change feature determination module 202, target fault cause determination module 204, target repair monitoring data determination module 206, and fault repair result determination module 208 mentioned above correspond to steps S102 to S110 in the embodiments. The instances and application scenarios implemented by the above modules and corresponding steps are the same, but are not limited to the content disclosed in the above embodiments. It should be noted that the above modules, as part of the device, can run in a computer terminal.

[0076] It should be noted that the optional or preferred implementation methods of this embodiment can be found in the relevant descriptions in the embodiments, and will not be repeated here.

[0077] The fault repair result determination device described above may also include a processor and a memory. The fault detection result determination module 200, the change feature determination module 202, the target fault cause determination module 204, the target repair monitoring data determination module 206, and the fault repair result determination module 208 are all stored in the memory as program modules. The processor executes the program modules stored in the memory to realize the corresponding functions.

[0078] The processor contains a core that retrieves the corresponding program modules from memory. One or more cores may be configured. Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory includes at least one memory chip.

[0079] According to an embodiment of this application, an embodiment of a non-volatile storage medium is also provided. Optionally, in this embodiment, the non-volatile storage medium includes a stored program, wherein, when the program runs, it controls the device where the non-volatile storage medium is located to execute any of the above-mentioned application's fault repair result determination method.

[0080] Optionally, in this embodiment, the non-volatile storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals, and the non-volatile storage medium includes stored programs.

[0081] Optionally, during program execution, the device containing the non-volatile storage medium is controlled to perform the following: Based on multiple sets of target monitoring data for the target application in the current time period, determine the fault detection result of the target application in the current time period. The fault detection result indicates whether a fault exists in the target application in the current time period. Each set of target monitoring data corresponds one-to-one with multiple health monitoring units in the target application. Each set of target monitoring data is obtained by standardizing the initial monitoring data output by the corresponding health monitoring unit. If the fault detection result indicates that a fault exists in the target application in the current time period, based on multiple sets of historical monitoring data for the target application in historical time periods, and multiple sets of target monitoring data, determine the change characteristics of the multiple sets of target monitoring data. Each set of historical monitoring data corresponds one-to-one with multiple sets of target monitoring data. Based on the change characteristics, determine the target fault cause of the target application in the current time period. Based on the target fault cause, repair the target application and determine the target repair monitoring data for the target application. Verify the target repair monitoring data to determine the fault repair result of the target application. The fault repair result indicates whether the fault was successfully repaired.

[0082] According to an embodiment of this application, an embodiment of a processor is also provided. Optionally, in this embodiment, the processor is used to run a program, wherein the program executes the fault repair result determination method of any of the above applications.

[0083] According to an embodiment of this application, an embodiment of a computer program product is also provided, which, when executed on a data processing device, is suitable for executing a program that initializes the fault repair result determination method steps of any of the above-described applications.

[0084] Optionally, when the aforementioned computer program product is executed on a data processing device, it is suitable to execute an initialization program with the following method steps: Based on multiple sets of target monitoring data for the target application in the current time period, determine the fault detection result of the target application in the current time period, wherein the fault detection result is used to indicate whether the target application has a fault in the current time period, the multiple sets of target monitoring data correspond one-to-one with multiple health detection units in the target application, and the multiple sets of target monitoring data are obtained by standardizing the initial monitoring data output by the corresponding health detection units; if the fault detection result indicates that the target application has a fault in the current time period, based on multiple sets of historical monitoring data of the target application in historical time periods and multiple sets of target monitoring data, determine the change characteristics of the multiple sets of target monitoring data, wherein the multiple sets of historical monitoring data correspond one-to-one with the multiple sets of target monitoring data; based on the change characteristics, determine the target fault cause of the target application in the current time period; based on the target fault cause, repair the target application and determine the target repair monitoring data of the target application; verify the target repair monitoring data and determine the fault repair result of the target application, wherein the fault repair result is used to indicate whether the fault has been successfully repaired.

[0085] like Figure 5 As shown, an embodiment of the present invention provides an electronic device 10, which includes a processor, a memory, and a program stored in the memory and executable on the processor. When the processor executes the program, it implements the steps of the fault repair result determination method for any of the above applications.

[0086] The order of the above embodiments of the present invention is merely for description and does not represent the superiority or inferiority of the embodiments.

[0087] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0088] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of modules described above can be a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between modules, and may be electrical or other forms.

[0089] The modules described above as separate components may or may not be physically separate. Similarly, the components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple modules. Some or all of the modules can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0090] Furthermore, the functional modules in the various embodiments of the present invention can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0091] If the aforementioned integrated modules are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable non-volatile storage medium. Based on this understanding, the technical solution of this invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a non-volatile storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned non-volatile storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0092] The above are merely preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for determining the result of fault repair in an application, characterized in that, include: Based on multiple sets of target monitoring data of the target application in the current time period, the fault detection result of the target application in the current time period is determined. The fault detection result is used to indicate whether the target application has a fault in the current time period. The multiple sets of target monitoring data correspond one-to-one with multiple health detection units in the target application. The multiple sets of target monitoring data are obtained by standardizing the initial monitoring data output by the corresponding health detection units. If the fault detection result indicates that the target application has the fault in the current time period, the change characteristics of the multiple sets of target monitoring data are determined based on multiple sets of historical monitoring data of the target application in historical time periods and the multiple sets of target monitoring data, wherein the multiple sets of historical monitoring data correspond one-to-one with the multiple sets of target monitoring data; Based on the aforementioned change characteristics, determine the cause of the target application's failure in the current time period; Based on the cause of the target failure, the target application is repaired, and the target repair monitoring data of the target application is determined; The target repair monitoring data is verified to determine the fault repair result of the target application, wherein the fault repair result is used to indicate whether the fault has been successfully repaired.

2. The method according to claim 1, characterized in that, When the multiple sets of target monitoring data each include multiple monitoring values, determining the fault detection result of the target application in the current time period based on the multiple sets of target monitoring data for the current time period includes: Determine the fault risk value corresponding to each of the multiple monitoring values ​​included in any set of target monitoring data in the current time period; Based on the fault risk values ​​corresponding to the multiple monitoring values ​​in the current time period, determine the comprehensive fault risk value of any set of target monitoring data in the current time period; Based on the comprehensive fault risk value corresponding to each of the multiple sets of target monitoring data, the target fault risk value applied to the target in the current time period is determined; The fault detection result is determined based on the target fault risk value.

3. The method according to claim 2, characterized in that, The determination of the comprehensive fault risk value of any set of target monitoring data in the current time period based on the fault risk values ​​corresponding to the multiple monitoring values ​​in the current time period includes: Based on the fault risk values ​​corresponding to the multiple monitoring values ​​in the current time period, the comprehensive fault risk value of any set of target monitoring data in the current time period is determined in the following manner: ； in, This represents the comprehensive fault risk value of any set of target monitoring data in the current time period. This represents the index of any set of target monitoring data. Indicates the index of the current time period. This represents the fault risk value of any monitoring value in any set of target monitoring data during the current time period. The index representing any of the monitored values.

4. The method according to claim 1, characterized in that, When the change characteristics include the change direction and current change slope corresponding to each of the multiple sets of target monitoring data, and when the fault detection result indicates that the target application has a fault in the current time period, the step of determining the change characteristics of the multiple sets of target monitoring data based on multiple sets of historical monitoring data of the target application in historical time periods, and the multiple sets of target monitoring data, includes: If the fault detection result indicates that the target application has the fault in the current time period, the historical change slope corresponding to each of the multiple sets of historical monitoring data is determined based on the multiple sets of historical monitoring data and the normalized historical time period. Based on the multiple sets of target monitoring data and the normalized current time period, the current change slope corresponding to each of the multiple sets of target monitoring data is determined; Based on the historical change slope corresponding to each of the multiple sets of historical monitoring data and the current change slope corresponding to each of the multiple sets of target monitoring data, the change direction corresponding to each of the multiple sets of target monitoring data is determined, wherein the change direction is any one of the following: upward direction, downward direction, or stable direction.

5. The method according to claim 4, characterized in that, The step of determining the change direction of each of the multiple sets of target monitoring data based on the historical change slope corresponding to each of the multiple sets of historical monitoring data and the current change slope corresponding to each of the multiple sets of target monitoring data includes: If the confidence level of the historical change slope of any set of historical monitoring data is less than a preset confidence threshold, or if the confidence level of the current change slope of any set of target monitoring data is less than the preset confidence threshold, then the change direction of the target monitoring data is determined to be the stable direction; or If the confidence level of the historical slope and the confidence level of the current slope of any set of historical monitoring data are both greater than or equal to the preset confidence threshold, and the current slope of the target monitoring data is greater than the historical slope of any set of historical monitoring data, then the direction of change of the target monitoring data is determined to be the upward direction; or If the confidence level of the historical slope and the confidence level of the current slope of any set of historical monitoring data are both greater than or equal to the preset confidence threshold, and the current slope of the target monitoring data is less than the historical slope of any set of historical monitoring data, then the direction of change of the target monitoring data is determined to be the downward direction; or If the confidence level of the historical change slope and the confidence level of the current change slope of any set of historical monitoring data are both greater than or equal to the preset confidence threshold, and the current change slope of any set of target monitoring data is equal to the historical change slope of any set of historical monitoring data, then the change direction of any set of target monitoring data is determined to be the stable direction. The change direction corresponding to each of the multiple sets of target monitoring data is obtained by using the method of obtaining the change direction of any one set of target monitoring data.

6. The method according to claim 1, characterized in that, The process of determining the cause of the target application's failure in the current time period based on the changing characteristics includes: Based on the aforementioned change characteristics and a preset fault cause template library, multiple initial fault causes for the target application in the current time period are determined. Determine a first monitoring value and a second monitoring value corresponding to each of the plurality of initial fault causes, wherein the first monitoring value is used to indicate the fault source of the corresponding initial fault cause, and the second monitoring value is used to indicate the fault consequence of the corresponding initial fault cause; Based on the start time of the change of the first monitoring value and the start time of the change of the second monitoring value corresponding to each of the plurality of initial fault causes, the fault propagation delay corresponding to each of the plurality of initial fault causes is determined; Among the fault propagation delays corresponding to each of the multiple initial fault causes, the initial fault causes that fall within the preset propagation delay range are determined as candidate fault causes. Based on the candidate fault causes, the target fault cause is determined.

7. The method according to claim 6, characterized in that, When there are multiple candidate fault causes, determining the target fault cause based on the candidate fault causes includes: Determine the fault confidence level corresponding to each of the multiple candidate fault causes; Among the multiple candidate fault causes, the candidate fault cause whose fault confidence level is greater than a preset fault confidence threshold is determined as the target fault cause.

8. The method according to claim 1, characterized in that, The process of repairing the target application based on the cause of the target failure and determining the target repair monitoring data for the target application includes: Based on the cause of the target failure, determine the monitoring data to be repaired for the target application; Obtain the intervention identifier and intervention duration of the target application, wherein the intervention identifier is used to indicate the repair action of the monitoring data to be repaired, and the intervention duration is used to indicate the execution duration of the repair action; Based on the intervention identifier and the intervention duration, the monitoring data to be repaired is repaired to obtain the first repaired monitoring data of the target application; Among the multiple sets of target monitoring data, the target monitoring data other than the first repair monitoring data are determined as the second repair monitoring data; The target repair monitoring data is obtained based on the first repair monitoring data and the second repair monitoring data.

9. A non-volatile storage medium, characterized in that, The non-volatile storage medium stores multiple instructions adapted for loading by a processor and executing the fault repair result determination method of the application according to any one of claims 1 to 8.

10. An electronic device, characterized in that, It includes one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the fault repair result determination method of the application according to any one of claims 1 to 8.

Images