Network anomaly event repair method and related apparatus

Abstract

The application discloses a network abnormal event repairing method and a related device, wherein the network abnormal event repairing method comprises the following steps: in response to detecting an abnormal event, constructing an operation call path graph of the abnormal event based on operation data of the abnormal event; identifying a candidate abnormal module in the operation call path graph, and calculating a confidence degree of the candidate abnormal module; selecting a repairing strategy matched with the abnormal event from preset repairing strategies based on the confidence degree, and executing the repairing strategy. Through the above method, the application can perform intelligent repairing on the abnormal event in a refined, hierarchical and verifiable manner.

Description

Technical Field

[0001] This application is applied to the field of network fault diagnosis, and in particular relates to a method for repairing network anomalies and related devices. Background Technology

[0002] Currently, Android systems primarily handle crashes by combining exception capture with post-crash analysis, such as offline investigation of Java stack traces, Native Crash Dumps, or ANR (Application Not Responding) logs. This exception data is typically exported offline and manually analyzed by developers using methods like stack analysis and symbol table restoration to pinpoint the root cause of the failure. For fault recovery, existing solutions mostly employ coarse-grained methods such as service restarts, process restarts, or even system reboots. A few systems incorporate watchdog mechanisms to achieve simple automatic recovery based on preset thresholds or fixed rules.

[0003] However, this method relies primarily on log information from a single source, making it difficult to accurately distinguish between the root cause module and the affected modules, which can easily lead to misjudgments. Furthermore, due to its reliance on manual offline analysis, the cycle from fault occurrence to location and repair is lengthy, making real-time response impossible. Therefore, existing technologies are insufficient to meet the stability assurance requirements of today's highly complex Android systems in terms of location accuracy, response time, self-healing capabilities, and repair security. Summary of the Invention

[0004] This application provides a method for repairing network anomalies, an electronic device, and a computer-readable storage medium to address the technical problem that automatic recovery mechanisms are based on fixed rules and lack comprehensive analysis capabilities.

[0005] To address the aforementioned technical problems, this application provides a network anomaly event repair method, electronic device, and storage medium, comprising: in response to detecting an anomaly event, constructing an operational call path graph of the anomaly event based on the operational data of the anomaly event; identifying candidate anomaly modules in the operational call path graph and calculating the confidence level of the candidate anomaly modules; selecting a repair strategy matching the anomaly event from preset repair strategies based on the confidence level, and executing the repair strategy.

[0006] The steps of identifying candidate abnormal modules in the runtime call path graph and calculating the confidence level of the candidate abnormal modules include: analyzing the runtime call path graph using a rule engine and statistical model to identify abnormal propagation nodes; identifying candidate abnormal modules based on the abnormal propagation nodes; and calculating the confidence level of the candidate abnormal modules based on a preset model.

[0007] The steps of identifying candidate abnormal modules based on abnormal propagation nodes and calculating the confidence level of candidate abnormal modules based on a preset model include: obtaining the evaluation parameters of the candidate abnormal modules, and performing a weighted summation of each evaluation parameter to obtain the confidence level.

[0008] The steps of selecting a matching repair strategy from the preset repair strategies based on confidence level and executing the repair strategy include: selecting the repair strategy with the least damage in the corresponding interval according to the preset mapping relationship between confidence level interval and the damage level of repair strategies; storing the running status of the candidate abnormal module in metadata and saving it as the target module; executing the repair strategy and verifying the repair effect of the candidate abnormal module.

[0009] The steps of executing the repair strategy and verifying the repair effect of the candidate abnormal module include: detecting whether the monitoring indicators after the execution of the repair strategy have recovered to the preset threshold; wherein the monitoring indicators include at least one of the following: average communication latency, core interface response time, CPU utilization and resident memory set size, and input / output waiting time; if it is detected that the recovery has reached the preset threshold, the repair effect has reached the preset standard, and the candidate abnormal module is determined to be repaired successfully; if it is detected that the recovery has not reached the preset threshold, the repair effect has not reached the preset standard, and a rollback repair strategy or an upgrade repair strategy based on the target module is triggered.

[0010] If it is detected that the recovery has not reached the preset threshold, the repair effect has not reached the preset standard, triggering the steps of a rollback repair strategy or an upgrade repair strategy based on the target module. These steps include: in response to the repair effect not reaching the preset standard, adopting an upgrade repair strategy, obtaining the destructive level of the currently executed repair strategy, and adopting a repair strategy with a destructive level one level higher than the currently executed repair strategy within the corresponding interval; or adopting a rollback repair strategy, reconstructing the runtime call path graph based on the target module, recalculating the confidence level, and matching the repair strategy according to the new confidence level.

[0011] The steps for determining that a candidate abnormal module has been successfully repaired include: in response to the repair effect reaching the preset threshold, generating audit logs for the candidate abnormal module and the repair strategy, and uploading the audit logs to the repair strategy database to optimize the repair strategy.

[0012] The step of constructing a runtime call path graph of an abnormal event in response to the detection of an abnormal event includes: collecting runtime data of the abnormal event within a preset time window in response to the detection of an abnormal event, and constructing a runtime call path graph based on the runtime data.

[0013] To address the aforementioned technical problems, this application provides an electronic device comprising: a memory and a processor coupled to each other, wherein the processor is configured to execute program instructions stored in the memory to implement the network anomaly event repair method as described above.

[0014] To address the aforementioned technical problems, this application provides a computer-readable storage medium storing program data that can be executed to implement the network anomaly event repair method described above.

[0015] The beneficial effects of this application are as follows: This application provides a method for repairing network anomaly events. In response to the detection of an anomaly event, it constructs an operational call path graph of the anomaly event based on the operational data of the anomaly event; identifies candidate anomaly modules in the operational call path graph and calculates the confidence level of the candidate anomaly modules; selects a repair strategy that matches the anomaly event from preset repair strategies based on the confidence level, and executes the repair strategy. This can improve the accuracy of identifying the root cause of the fault, make the selection of repair strategies more precise, and optimize system stability. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating one implementation method of the network anomaly event repair method provided in this application; Figure 2 This is a flowchart illustrating another implementation of the network anomaly event repair method provided in this application; Figure 3 This is a schematic diagram of one embodiment of the electronic device provided in this application; Figure 4 This is a schematic diagram of an embodiment of the computer-readable storage medium provided in this application. Detailed Implementation

[0017] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0018] It should be noted that if the embodiments of this application involve directional indicators (such as up, down, left, right, front, back, etc.), the directional indicators are only used to explain the relative positional relationship and movement of each component in a certain specific posture (as shown in the figure). If the specific posture changes, the directional indicators will also change accordingly.

[0019] Furthermore, if the embodiments of this application involve descriptions such as "first" or "second," these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, features defined with "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the technical solutions of various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. If the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed in this application.

[0020] Please see Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the network anomaly event repair method provided in this application.

[0021] S11: In response to the detection of an abnormal event, construct an execution call path graph of the abnormal event based on the execution data of the abnormal event.

[0022] An exception event capture unit is constructed to access various exception signals from the system to detect exception events and standardize and encapsulate the exception data to generate structured exception event objects. Each exception event object contains at least a timestamp, process identifier, thread information, and triggering context.

[0023] The timestamp indicates the point in time when the abnormal event occurred, used for event sorting, timing analysis, and correlation with other system logs. The process identifier includes at least one of the following: process ID, process name, and user ID. The process ID is a unique numerical number assigned by the system; the process name identifies the package name or executable file name corresponding to the process; and the user ID identifies the user to whom the process belongs. This field is used to locate the faulty process and distinguish between system processes and application processes. Thread information includes at least one of the following: thread ID, thread name, and thread state. The thread ID is a unique number assigned by the system; the thread name identifies the specific thread (e.g., main thread or worker thread); and the thread state reflects the thread's running state at the time of the crash (e.g., runnable, waiting, or native). This field is used to determine whether the crash occurred on the main thread and to identify inter-thread contention or deadlock. The triggering context includes at least one of the following: exception type, call stack, register state, system load, and associated transaction ID. The exception event capture unit listens for various abnormal signals during system runtime. The scope of exceptions listened to includes, but is not limited to, Java exceptions, Native Crash, Kernel Signals, Binder exceptions, and ANR. Specifically, Java exceptions can be monitored by setting a global "thread uncaught exception handler." When an uncaught exception occurs in any thread, the JVM (Java Virtual Machine) or ART (Android Runtime) will automatically call back the handler, from which the exception object and its stack information can be obtained. Kernel Signals can receive exception signals and kernel exception notifications from the Hardware Abstraction Layer, the driver layer, and the kernel mode by monitoring kernel interfaces or registering a kernel error notification chain. Binder exceptions can be detected in real time by detecting abnormal states such as Binder transaction return values, long-term blocking, and transaction timeouts to obtain exception events. ANR can be detected by listening to ANR trigger signals broadcast by the Activity Manager service and / or monitoring the generation events of trace files in the system directory to capture the main thread stack and system load information when the application is unresponsive. The exception event capture unit uniformly categorizes and prioritizes all exception signals. For example, the uniform categorization is based on the source and type of the exception, dividing it into crash-type exceptions (such as Java exceptions and native crashes), unresponsive exceptions (such as ANR), communication exceptions (such as Binder exceptions), and system-level exceptions (such as kernel exceptions). Priorities are divided into levels according to the severity, scope of impact, and recoverability of the exception. For example, P0 level is for fatal exceptions, such as kernel exceptions or HAL (Hardware Abstraction Layer) crashes; P1 level is for serious exceptions, such as system service crashes or Binder thread pool exhaustion; P2 level is for general exceptions, such as third-party application crashes; and P3 level is for minor exceptions, such as single transaction timeouts.In addition, the exception event capture unit can be deployed as a high-privilege component, which can run inside the system service process or run independently as a privileged native daemon process.

[0024] In response to the crash event capture unit detecting an abnormal event and generating a structured abnormal event object, a runtime path backtracking unit collects runtime data of the abnormal event and constructs a runtime call path graph to reconstruct the abnormal propagation chain and potential causal relationships. Specifically, the runtime path backtracking unit obtains the precise call stack of the crash point using the native stack backtracking library to reconstruct the function call path; then, it captures gluer transaction chain information using Binder kernel hooks or tracepoints, including key data such as caller, callee, interface name, call duration, and serialization time, thereby reconstructing the complete interaction process of cross-process communication; subsequently, it parses system trace or performance tracer data to recover thread scheduling, competition state, CPU (Central Processing Unit) load changes, and IO (Input / Output) behavior within the time window before and after the crash, to reveal the abnormal causes at the system resource level; finally, it collects the CPU utilization, RSS (Resident Set Size), and FD (File Descriptor) usage of the abnormal-related processes. After parsing the above information, the runtime path backtracking unit constructs a runtime call path graph. For example, the runtime call path graph can be represented as a directed graph, where nodes represent processes, threads, or function call points, and edges represent call relationships or communication links (such as Binder transactions, function calls, thread wake-ups, etc.). Attributes such as timestamps, execution time, and parameters can be attached to the edges. The call stack obtained from the native stack backtracking library is parsed into a function call chain, forming the execution path within a thread. The transaction link information captured by the gluer kernel hook is parsed into cross-process communication edges, connecting the caller process and the callee process. Scheduling events and lock events in system traces or performance tracer data are parsed into waiting relationships and resource contention edges between threads. Simultaneously, CPU usage, resident memory size, and file descriptor usage are attached as node attributes to the corresponding process nodes. Furthermore, the runtime path backtracking unit can deploy an independent native daemon process to reduce the performance impact on system service processes.

[0025] S12: Identify candidate abnormal modules in the runtime call path graph and calculate the confidence level of the candidate abnormal modules.

[0026] By constructing a strategy decision engine, the runtime call path graph is structurally analyzed to identify candidate abnormal modules and calculate their confidence levels. The strategy decision engine includes at least a decision module and a confidence module. Specifically, the decision module performs structural analysis on the graph, focusing on factors such as the in-degree and out-degree of nodes, the length of the anomaly propagation path, the existence of loops, and key bridge nodes connecting multiple subgraphs, thereby locating candidate abnormal modules that may cause anomalies. The decision engine uses a rule engine to filter based on predefined rules, such as detecting if a specific Binder interface fails a set number of times consecutively within a time window, or if a process's file descriptor usage exceeds a threshold. This is combined with statistical models such as decision trees and logistic regression, using node characteristics such as call count, failure rate, time consumption, and resource usage. Using source usage as input, the candidate set output by the rule engine is scored and verified a second time, outputting the probability value of each node as an anomalous module. Finally, the decision module identifies nodes that meet preset conditions as candidate anomalous modules, such as when the rule engine hits the target and the statistical model outputs a probability exceeding a preset threshold (e.g., 0.7, 0.75, 0.8); or when the rule engine misses the target but the statistical model outputs a probability exceeding a higher threshold (e.g., 0.9, 0.95); or when a single node deviates from the normal baseline in multiple dimensions of features simultaneously, such as when the call failure rate, resource utilization, and response time all exceed 1.5 times their respective thresholds. Gradient boosting models or lightweight neural networks can be introduced later to further improve the accuracy and generalization ability of the identification. For example, gradient boosting models, by integrating multiple decision trees, can automatically learn complex nonlinear interaction relationships between features, effectively handling edge scenarios that are difficult for the rule engine to cover.

[0027] After identifying candidate anomaly modules, the decision engine calculates the confidence score of each module using a confidence module. Confidence score calculation can be based on locally stored model parameters or rule sets, weighted by multiple evaluation factors. Specifically, the confidence score is calculated by weighting factors such as historical frequency, stack consistency, transaction matching degree, and system load. The historical frequency factor calculates the frequency of similar or identical anomalies occurring within a defined time period; higher frequency results in higher confidence. The stack consistency factor compares the matching degree between the current anomaly call stack and historical anomaly events; higher matching degree indicates stronger reproducibility. The transaction matching degree factor assesses the fit between the current anomaly and the associated Binder transaction chain, such as whether the anomaly point and the transaction timeout point are adjacent on the call path. The system load factor considers the CPU, memory, and I / O pressure at the time of the anomaly occurrence; for example, anomalies occurring under high load may be non-root cause, occasional problems, and the confidence score should be appropriately lowered. After each factor is scored, they are weighted and fused according to preset weights to finally output the comprehensive confidence score for each candidate anomaly module. Alternatively, a weighted fusion of three dimensions can be used: the rule engine hit score, the statistical model output probability, and the dynamic feature deviation score. The rule engine hit score is assigned based on the severity of the hit rule; for example, a higher severity is indicated by more than 5 consecutive failures of a specific Binder interface. The statistical model probability score directly uses the probability values ​​output by decision trees or logistic regression. The dynamic feature deviation score measures the degree to which features such as node call failure rate, resource utilization, and response time deviate from the normal baseline. The scores from these three dimensions are then weighted and summed according to preset weights to output the overall confidence score of the candidate anomaly module.

[0028] S13: Select a repair strategy that matches the abnormal event from the preset repair strategies based on the confidence level, and execute the repair strategy.

[0029] The strategy decision engine sorts the set of repair strategies according to their degree of destructiveness. Based on confidence levels, it selects a repair strategy that matches the abnormal event from the generated repair strategies and executes the repair strategy through the recovery execution unit. The strategy decision engine also includes a strategy list module and a configuration module. Specifically, the strategy list module sorts the set of repair strategies according to their degree of destructiveness, for example, from low to high: logging or alarm only, Binder channel rebinding, service soft restart, HAL reload, subsystem restart, and system restart. The strategy engine selects the least destructive strategy that meets the conditions for execution based on the candidate abnormal modules and their confidence scores output by the decision module, through confidence interval mapping. For example, taking a confidence level range of 0 to 1, a confidence level of 0.3 or lower corresponds to only logging or alarming; a confidence level greater than 0.3 and less than or equal to 0.5 corresponds to Binder channel rebinding, within which Binder channel rebinding, Binder thread pool expansion, and Binder transaction queue cleanup can be configured in ascending order of destructiveness; a confidence level greater than 0.5 and less than or equal to 0.7 corresponds to service soft restart, within which service soft restart, service process restart, and cascading restart of the service and its dependent services can be configured in sequence; a confidence level greater than 0.7 and less than or equal to 0.9 corresponds to HAL reload or subsystem restart, within which HAL reload, HAL process restart, and subsystem restart can be configured in sequence; a confidence level above 0.9 corresponds to a complete system restart. The configuration module provides a configuration interface, supporting whitelisted services, cooldown time, enabling or disabling automatic self-healing mode, and "log only, do not execute" mode. Configuration changes take effect in real time. The whitelist service allows users or vendors to specify certain critical services that should not participate in automatic repair, preventing secondary failures caused by misjudgments leading to abnormal restarts of core functions. A cooldown period limits the frequency at which the same module repeatedly executes repair strategies within a short period, preventing a vicious cycle of repeated restarts during frequent crashes. An automatic self-healing mode can be enabled or disabled, allowing for temporary shutdown of automatic repair in debugging or special scenarios, necessitating manual intervention. A "record-only" mode records only the repair actions that should be performed and the confidence assessment results, without actually executing any repair operations, facilitating the evaluation of the strategy's rationality and accuracy. Furthermore, the strategy decision engine can be deployed as a system service process or another high-privilege process, supporting repair strategy loading and hot updates.

[0030] After the strategy decision engine selects the repair strategy for the corresponding abnormal event of the candidate abnormal module, the recovery execution unit executes the repair action. The recovery execution unit includes at least a snapshot and rollback module and a rate limiting and loop detection module, and may also include a shadow space module. Specifically, before executing a potentially destructive repair strategy, the snapshot and rollback module saves a lightweight state snapshot. The snapshot content includes a service status table, a list of process PIDs (Process Identifiers), a Binder handle summary, a file descriptor list, and key system attribute values, and stores this snapshot content as metadata for the target module. When executing within the same confidence interval, the snapshot and rollback module prioritizes the least disruptive strategy. If this strategy fails or the conditions are not met, an upgraded strategy is employed, attempting the next level of strategy sequentially until success or the highest level within the interval is reached. If all levels of strategies within the current interval fail, the snapshot and rollback module uses a rollback strategy. Based on the saved target module snapshot information, combined with the runtime path backtracking module's reconstruction of the runtime call path graph and the confidence assessment results output by the strategy decision engine, a new repair strategy is dynamically generated and executed. During the execution of the repair strategy, the rate limiting and loop detection module counts the number of times the same module is repaired within a unit time window. If the number exceeds a preset threshold, further automatic repair is suppressed, and an alarm or manual intervention mechanism is triggered. This effectively avoids a repair-crash loop caused by repeated repair failures, preventing the system from falling into a state of ineffective restarts. Furthermore, a shadow space module can be set as an optional isolated execution environment for pre-validating alternative modules or high-risk repair strategies. For example, before the formal repair is executed, the shadow space module will simulate the execution of the target repair strategy to verify its security and effectiveness. Only after the verification is passed will it be officially implemented. This is applicable to destructive strategies in the high confidence range, such as HAL reload, subsystem restart or whole machine restart, which can effectively reduce the risk of secondary failures caused by policy misjudgment or abnormal execution environment.

[0031] In addition, a status verification unit and an audit closed-loop optimization module can be set up. The status verification unit is used to determine whether the execution of the repair strategy is successful and whether the repair effect meets the expected conditions after the snapshot and rollback modules in the recovery execution unit execute the repair strategy. Specifically, the status verification unit determines whether the repair is effective by detecting whether key evaluation parameters have returned to the normal threshold range. If the detection result shows that the abnormal indicators have fallen back to the normal threshold range, the repair is determined to be successful; if the detection result shows that the key evaluation parameters have not yet returned to the normal threshold range, and / or the repair effect does not meet the preset conditions, such as Binder transactions still time out, CPU utilization remains high, and service response latency has not decreased, the repair is determined to be unsuccessful or insufficient. The status verification unit notifies the recovery execution unit to trigger subsequent upgrade repair strategies or rollback repair strategies. The key evaluation parameters include at least one of the following: average Binder communication latency, core interface response time, CPU utilization, resident memory set size, and IO wait time. If the abnormal event is that the service process is unresponsive or frequently crashes, the key evaluation parameters may also include the target service heartbeat frequency. For example, the target service may define a dedicated heartbeat command word and send this command word to the system at fixed time intervals to indicate that it is in normal operating condition. The status verification unit counts the frequency of this "heartbeat signal." The audit closed-loop optimization module is responsible for recording all abnormal events and repair strategy behaviors in the system. After privacy anonymization, these are securely uploaded to the remote repair strategy database for model retraining, strategy optimization, and root cause analysis, forming a continuously evolving closed-loop optimization mechanism. Specifically, the audit log module monitors the exception event capture unit and the recovery execution unit in real time, collecting exception event information (including exception type, occurrence time, process ID, thread information, trigger context, and runtime call path graph, etc.) and repair behavior information (including the executed repair strategy, confidence score, execution result, execution time, rollback record, and upgrade path, etc.), and encapsulates it in a structured manner according to a preset format to generate unified audit log entries; before uploading the logs, the content undergoes privacy desensitization processing, including removing or replacing personal identification information in process names, filtering file paths and device unique identifiers, and desensitizing sensitive data in Binder transaction parameters. The system performs obfuscation processing while retaining key technical features required for fault analysis, ensuring that uploaded data complies with privacy and security regulations. The de-identified audit logs are securely uploaded to a remote database via an encrypted transmission channel. Upload strategies can be configured in real-time or batch mode. The remote database is indexed and stored by dimensions such as time, anomaly type, device model, and system version. The audit logs in the remote database are used as training data for model retraining and strategy optimization, including incremental training of gradient boosting models or lightweight neural networks to improve anomaly identification accuracy, and dynamically adjusting the confidence interval mapping relationship, strategy priority, and rate limiting threshold in the strategy list based on the success rate statistics of repair behavior.

[0032] Through the above steps, this embodiment improves the accuracy and real-time performance of fault location by constructing a runtime call path graph and fusing multi-source data. It calculates confidence based on mechanisms such as historical frequency, stack consistency, and system load, and achieves precise and intelligent self-healing by combining a graded repair strategy. At the same time, it saves a lightweight snapshot before executing destructive strategies, and cooperates with rollback, upgrade, rate limiting detection, and shadow space pre-verification to ensure the safety and recoverability of the repair process.

[0033] Please see Figure 2 , Figure 2 This is a flowchart illustrating another embodiment of the network anomaly event repair method provided in this application.

[0034] S21: In response to the detection of an abnormal event, collect the runtime data of the abnormal event within a preset time window, and construct a runtime call path graph based on the runtime data.

[0035] In response to an anomaly detected by the anomaly capture unit, the runtime path backtracking unit collects runtime data of the anomaly based on a preset time window and constructs a runtime call path graph. The preset time window refers to a fixed or configurable time period for data collection, such as 100 milliseconds to 1 second, which can be dynamically adjusted based on device performance. The runtime path backtracking unit connects to the process stack capturer, Binder transaction monitor, and system trace parser, ensuring data integrity by synchronously collecting process stacks, Binder transaction relationships, and system-level trace data before and after the crash. For example, a preset time window of 100 milliseconds can be used to match typical crash response times, ensuring rapid capture of runtime data within milliseconds of the anomaly's occurrence; it can also be configured as a variable time window, automatically expanding to 500 milliseconds based on system load to adapt to situations with significant data collection latency under high load. Furthermore, it supports dynamically adjusting the time window size based on the anomaly type, such as using a longer window (e.g., 1 second) for ANR anomalies to capture the complete blocking process, and a shorter window (e.g., 50 milliseconds) for native crashes to focus on precise instantaneous crash state data.

[0036] In a specific application scenario, after the exception event capture unit detects an application unresponsive event (an exception event), the runtime path backtracking unit immediately collects data using a preset 200-millisecond time window (dynamically adjusted to 200 milliseconds based on the current CPU load). Within this window, the process stack capturer collects the call stacks of the main thread and critical worker threads, finding that the main thread is blocked on the Binder's waitForResponse call; the Binder transaction monitor captures the call chain of this transaction, showing that the caller is the social application process and the callee is the media service interface in the system service process; the system trace parser simultaneously collects thread scheduling data, finding that the media service thread has been unresponsive for a long time due to waiting for file I / O operations. The runtime path backtracking unit merges the above multi-source data to construct a runtime call path graph, visually displaying the exception propagation path: social application main thread → Binder driver → system media service thread → file I / O blocking.

[0037] S22: Use a rule engine and statistical model to analyze the runtime call path graph and identify abnormal propagation nodes; identify candidate abnormal modules based on the abnormal propagation nodes, and calculate the confidence level of the candidate abnormal modules based on the preset model.

[0038] A rule engine and statistical model are used to perform structured analysis of the runtime call path graph, identify key nodes on the anomaly propagation path, and locate candidate anomaly modules based on these nodes. Then, a pre-defined model is used to calculate the confidence level of each candidate module. Specifically, the rule engine processes the topology of the runtime call path graph, quickly identifying anomaly propagation nodes through pre-defined rules such as three consecutive failures of the Binder interface or an anomaly call chain length exceeding a threshold. The statistical model calculates the probability distribution of anomaly propagation nodes based on historical crash frequency, stack consistency, and system load data, for example, using a logistic regression model for weighted summation to obtain the anomaly propagation probability distribution. Anomaly propagation nodes are located according to the rule engine's pre-defined rules, and the statistical model performs probability scoring based on the historical crash frequency, stack consistency, and system load characteristics of the anomaly propagation nodes. Finally, nodes that are hit by the rule engine and whose statistical model probability exceeds a threshold, or whose statistical model probability exceeds a higher threshold, are identified as anomaly propagation nodes. A decision tree rule engine combined with a logistic regression statistical model can be used, with the rule engine handling explicit rules and the statistical model handling historical data. Historical crash log data can also be used to train the statistical model to improve the accuracy of node probability calculation. The preset model can use a pre-trained machine learning model to perform weighted fusion of evaluation factors from multiple dimensions, such as historical frequency, stack consistency, transaction matching degree and system load. Finally, the confidence of candidate anomaly modules is calculated based on the preset model.

[0039] In a specific application scenario, the decision engine performs a structured analysis of the runtime call path graph of the abnormal event and finds that the crashing thread is a Binder worker thread, and the call stack points to the WindowManagerService.relayoutWindow interface. The rule engine detects that this interface has failed 3 times in the past hour, hitting the preset rule. The statistical model calculates the anomaly probability as 0.88 based on historical crash frequency, stack consistency, and system load. The preset model takes a weighted average of historical frequency, stack consistency, transaction matching score, system load, rule hit, and statistical model probability to obtain a comprehensive confidence level of 0.84.

[0040] S23: Based on the preset confidence interval and the mapping relationship between the destructive level of the repair strategy, select the repair strategy with the least destructiveness within the corresponding interval.

[0041] The strategy decision engine can set the confidence interval to multiple preset ranges. For example, the confidence score range of 0~1 can be set to preset ranges such as 0-0.3, 0.3-0.6, 0.6-0.8, and 0.8-0.9. The destructive level mapping refers to the ordering of repair strategies from least to most destructive, such as recording alarms corresponding to the lowest destructiveness, followed by Binder rebinding, and then service restart, in ascending order. The strategy decision engine first determines the confidence interval, and then selects the least destructive repair strategy from the corresponding strategy set in order of least destructiveness.

[0042] S24: Store the runtime status of the candidate abnormal module in metadata and save it as the target module; execute the repair strategy and verify the repair effect of the candidate abnormal module.

[0043] Before executing the repair strategy, the system stores the current running state of the candidate abnormal modules as metadata, saving it as a snapshot of the target module. The target module's metadata includes a service status table (recording whether the service is currently running, stopped, or in an abnormal state), a process PID list (recording the process identifiers of related processes), a Binder handle digest (recording handle information for cross-process communication), a file descriptor list (recording the number and type of file handles opened by processes), and key system attribute values ​​(such as system configuration parameters and service flags). Based on the repair strategy selected by the strategy decision engine, the corresponding repair strategy is executed on the candidate abnormal modules. The status verification unit then verifies the repair effect of the candidate abnormal modules by checking whether key evaluation parameters have returned to the normal threshold range to determine if the repair was successful. If the verified repair effect does not meet the preset standard, an upgrade repair strategy is triggered, upgrading to a repair strategy with a higher level of destructiveness within the same confidence range; or a rollback repair strategy is triggered, using the previously stored metadata to restore the target module to its state before repair, reconstructing the runtime call path graph, calculating the confidence level, and selecting a repair strategy. If the verification of the repair effect meets the preset standard, the audit and closed-loop optimization module records the abnormal event and the successful repair strategy, generates a structured audit log, and uploads it to the repair strategy database after privacy anonymization processing for subsequent model retraining and strategy optimization.

[0044] Through the above steps, this embodiment constructs a runtime call path graph and integrates multi-source runtime data to reconstruct the abnormal propagation path, thereby improving the accuracy of fault root cause identification. It also calculates confidence based on mechanisms such as historical crash frequency and system load, making the selection of recovery strategies more accurate. Furthermore, it saves a lightweight snapshot before executing destructive strategies, allowing for upgrades or rapid rollbacks when repairs fail. Finally, it uses closed-loop feedback from audit logs to optimize repair strategies, forming a virtuous cycle of continuous evolution of self-healing capabilities.

[0045] Based on the same concept, this application also proposes an electronic device capable of executing the network anomaly repair method of any of the above embodiments. Please refer to [link to relevant documentation]. Figure 3 , Figure 3 This is a schematic diagram of an embodiment of the electronic device provided in this application. The electronic device includes a processor 31 and a memory 32.

[0046] The processor 31 is used to execute the program instructions stored in the memory 32 to implement the steps of any of the above-described network anomaly repair methods. In a specific implementation scenario, the electronic device may include, but is not limited to, a microcomputer or a server. In addition, the electronic device may also include mobile devices such as laptops and tablets, which are not limited here.

[0047] Specifically, processor 31 controls itself and memory 32 to implement the steps of any of the above embodiments. Processor 31 may also be referred to as a CPU (Central Processing Unit). Processor 31 may be an integrated circuit chip with signal processing capabilities. Processor 31 may also be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. A general-purpose processor may be a microprocessor or any conventional processor. Furthermore, processor 31 may be implemented using integrated circuit chips.

[0048] Based on the same concept, this application also proposes a computer-readable storage medium, please refer to... Figure 4 , Figure 4 This is a schematic diagram of an embodiment of the computer-readable storage medium provided in this application. The computer-readable storage medium 40 stores at least one program data 41, which is used to implement any of the methods described above. In one embodiment, the computer-readable storage medium 40 includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0049] In the several embodiments provided in this application, it should be understood that the disclosed methods and apparatus can be implemented in other ways. For example, the apparatus implementations described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units 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; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

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

[0051] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0052] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, 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, which is stored in a storage medium.

[0053] The above are merely embodiments of this application and do not limit the scope of this patent application. Any equivalent structural or procedural changes made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of this application.

Claims

1. A method for repairing network anomaly events, characterized in that, include: In response to the detection of an abnormal event, a runtime call path graph of the abnormal event is constructed based on the runtime data of the abnormal event; Identify candidate abnormal modules in the execution call path graph and calculate the confidence level of the candidate abnormal modules; Based on the confidence level, a repair strategy matching the abnormal event is selected from the preset repair strategies, and the repair strategy is executed.

2. The network anomaly event repair method according to claim 1, characterized in that, The step of identifying candidate abnormal modules in the runtime call path graph and calculating the confidence level of the candidate abnormal modules includes: The execution call path graph is analyzed using a rule engine and statistical model to identify abnormal propagation nodes; The candidate abnormal modules are identified based on the abnormal propagation nodes, and the confidence level of the candidate abnormal modules is calculated based on a preset model.

3. The network anomaly event repair method according to claim 2, characterized in that, The step of identifying the candidate abnormal module based on the abnormal propagation node and calculating the confidence level of the candidate abnormal module based on a preset model includes: The evaluation parameters of the candidate anomaly module are obtained, and the confidence level is obtained by weighted summation of each evaluation parameter.

4. The network anomaly event repair method according to claim 1, characterized in that, The step of selecting a matching repair strategy from preset repair strategies based on the confidence level and executing the repair strategy includes: Based on the preset confidence interval and the destructive level mapping relationship between the repair strategy, the repair strategy with the least destructiveness within the corresponding interval is selected; The running status of the candidate abnormal module is stored in metadata and saved as the target module; Execute the repair strategy and verify the repair effect of the candidate abnormal modules.

5. The network anomaly event repair method according to claim 4, characterized in that, The steps of executing the repair strategy and verifying the repair effect of the candidate abnormal modules include: The system detects whether the monitoring indicators after the repair strategy is executed have recovered to the preset threshold; wherein the monitoring indicators include at least one of the following: average communication latency, core interface response time, CPU utilization and resident memory set size, and input / output wait time. If the recovery to the preset threshold is detected, the repair effect has reached the preset standard, and the candidate abnormal module is determined to have been successfully repaired. If it is detected that the recovery has not reached the preset threshold, the repair effect has not reached the preset standard, triggering a rollback repair strategy or an upgrade repair strategy based on the target module.

6. The network anomaly event repair method according to claim 5, characterized in that, The step of triggering a rollback or upgrade repair strategy based on the target module if the target module is not detected to have recovered to the preset threshold, indicating that the repair effect has not reached the preset standard, includes: In response to the fact that the repair effect does not meet the preset standard, the upgraded repair strategy is adopted, the level of damage of the currently executed repair strategy is obtained, and the repair strategy with a level of damage one level higher than the currently executed repair strategy in the corresponding interval is adopted. Alternatively, the rollback repair strategy can be adopted, which involves reconstructing the runtime call path graph based on the target module, recalculating the confidence level, and matching the repair strategy according to the new confidence level.

7. The network anomaly event repair method according to claim 5, characterized in that, The step of determining that the candidate abnormal module has been successfully repaired if the detected recovery reaches a preset threshold and the repair effect reaches a preset standard includes: In response to the repair effect reaching a preset standard, an audit log is generated for the candidate abnormal module and the repair strategy, and the audit log is uploaded to the repair strategy database to optimize the repair strategy.

8. The network anomaly event repair method according to claim 1, characterized in that, The step of constructing the runtime call path graph of the abnormal event in response to the detection of the abnormal event includes: In response to the detection of the abnormal event, the runtime data of the abnormal event is collected within a preset time window, and the runtime call path map is constructed based on the runtime data.

9. An electronic device, characterized in that, The electronic device includes a memory and a processor coupled to each other, the processor being configured to execute program instructions stored in the memory to implement the network anomaly event repair method as described in any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores program data that can be executed to implement the network anomaly event repair method as described in any one of claims 1 to 8.

Images