A service exception processing method, device, equipment and medium

Abstract

The application belongs to the field of artificial intelligence, and relates to a service exception processing method and device, equipment and medium, which comprises the following steps: collecting performance indexes, link tracking and business log data of a target service from a service cluster, comparing the performance indexes with a threshold set, and judging whether the service is abnormal. If it is determined that there is an exception, link tracking data is analyzed to construct a service dependency graph, and an abnormal propagation path is located. Then, the business log matching the current exception, the code change record and the resource state data are retrieved, multi-dimensional fault information is extracted and a prompt word is generated by template splicing. The prompt word is input into a pre-trained exception root cause analysis model, and an exception root cause set containing classification labels is inferred, and a repair decision instruction corresponding to each root cause is matched synchronously. Finally, according to the instructions corresponding to various faults, targeted governance operations are performed on the target service to eliminate the service exception. The application can be applied to business fields such as finance and insurance, medical treatment and the like, and can automatically eliminate the abnormal state.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology and is applied to online processing business scenarios such as finance, insurance, and healthcare. In particular, it relates to a service anomaly handling method, device, equipment, and medium. Background Technology

[0002] In the cloud-native microservice architecture, insurance underwriting and claims processing, medical treatment and settlement, and other businesses all adopt a distributed multi-service cluster deployment architecture. The links between various business services are intertwined and the call coupling is high. Any service failure will propagate and spread along the call link. The stability of the system directly determines whether core businesses such as insurance policy issuance and medical settlement can be carried out normally.

[0003] Currently, the industry-standard microservice governance methods heavily rely on pre-configured static judgment rules and manual intervention by operations and maintenance (O&M) personnel. O&M personnel need to continuously poll and collect operational data from various business services. Once anomalies such as interface response delays or sudden increases in service error rates occur, manual analysis of the call chain and investigation of various related data is necessary to clarify the fault propagation flow, manually identify the underlying cause of the fault, and then manually issue governance commands. This entire process is slow, and the effectiveness of fault handling depends entirely on the accumulated business and O&M experience of the O&M personnel. When facing complex, concurrent chain-like sudden failures in insurance and healthcare scenarios, manual investigation is prone to oversights.

[0004] In addition, existing service mesh and microservice governance platforms mostly focus on basic traffic control such as traffic forwarding and traffic limiting. They lack the complete capabilities of automatic anomaly identification, root cause intelligent determination, and automatic fault repair. They cannot independently sort out the fault propagation path across service levels or accurately dig out the deep-seated fault causes. As a result, the average fault repair time remains high, and core business systems with strict continuity requirements, such as insurance underwriting and medical settlement, have poor overall fault resilience. Summary of the Invention

[0005] The purpose of this application is to provide a service anomaly handling method, apparatus, computer equipment, and storage medium to solve the problems of existing technologies that rely on static rules and manual operation and maintenance, lack automatic root cause identification and self-healing capabilities, and have low anomaly handling efficiency.

[0006] Firstly, a service exception handling method is provided, which adopts the following technical solution: The system retrieves performance metrics, tracing data, and business log data of the target service from the service cluster. Based on a comparison of the performance metrics with a pre-defined set of thresholds, it determines whether the target service is in an abnormal state. If the target service is in an abnormal state, it constructs a service dependency graph based on the tracing data and determines the propagation path of the abnormal state. It acquires abnormal business log data, code change records, and resource status data corresponding to all nodes covered by the propagation path, and generates prompt words based on these data. Using a pre-defined root cause analysis model, it generates a set of root causes and corresponding remediation decisions for each root cause within the set, based on the prompt words. Finally, based on the remediation decisions and the set of root causes, it performs governance operations corresponding to each root cause on the target service to eliminate the abnormal state.

[0007] Secondly, a service exception handling device is provided, which adopts the following technical solution: The first acquisition module is used to acquire performance metric data, tracing data, and business log data of the target service from the service cluster; The judgment module is used to determine whether the target service is in an abnormal state based on the comparison results between the performance indicator data and the preset threshold set. The module is used to construct a service dependency graph based on the tracing data if the target service is in an abnormal state, and to determine the propagation path of the abnormal state based on the service dependency graph. The second acquisition module is used to acquire abnormal business log data, code change records and resource status data corresponding to all nodes covered by the propagation path, and generate prompt word information based on the business log data, code change records and resource status data; The generation module is used to generate a set of abnormal root causes and corresponding repair decision instructions for each abnormal root cause in the set, based on the prompt word information and using a preset abnormal root cause analysis model. The execution module is used to perform governance operations corresponding to each abnormal root cause on the target service according to the repair decision instructions and the set of abnormal root causes, so as to eliminate the abnormal state.

[0008] Thirdly, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described service exception handling method.

[0009] Fourthly, a computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements the steps of the above-described service exception handling method.

[0010] Compared with existing technologies, the embodiments of this application have the following main advantages: By collecting cluster performance indicators, link tracing, and business log data from multiple dimensions, comprehensive service operation information can be covered, ensuring the data integrity of anomaly judgment. Service anomalies are automatically identified based on threshold comparison, eliminating the reliance on continuous manual inspection. Service dependency graphs are constructed through link data, automatically reconstructing fault propagation paths without the need for manual layer-by-layer analysis of call chains. Logs, code changes, and resource data are integrated to generate prompt words, improving the input materials for root cause analysis. Root cause sets and corresponding repair instructions are output using the model, achieving intelligent root cause localization. Corresponding governance operations are automatically executed based on the repair instructions, completing anomaly self-healing and improving anomaly handling efficiency. Overall, the degree of manual intervention is significantly reduced, shortening fault repair time. Attached Figure Description

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

[0012] Figure 1 This is an exemplary system architecture diagram to which this application can be applied; Figure 2 A flowchart of an embodiment of the service exception handling method according to this application; Figure 3 This is a schematic diagram of a structure of one embodiment of the service exception handling apparatus according to this application; Figure 4 This is a schematic diagram of the structure of one embodiment of the computer device according to this application. Detailed Implementation

[0013] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.

[0014] like Figure 1 As shown, system architecture 100 may include terminal device 101, network 102, and server 103. Terminal device 101 may be a laptop 1011, tablet 1012, or mobile phone 1013. Network 102 is used as a medium to provide a communication link between terminal device 101 and server 103. Network 102 may include various connection types, such as wired, wireless communication links, or fiber optic cables.

[0015] Users can use terminal device 101 to interact with server 103 via network 102 to receive or send messages, etc. Various communication client applications can be installed on terminal device 101, such as web browser applications, shopping applications, search applications, instant messaging tools, email clients, social media platform software, etc.

[0016] Terminal device 101 can be various electronic devices with a display screen and support web browsing. In addition to laptops 1011, tablets 1012, or mobile phones 1013, terminal device 101 can also be e-book readers, MP3 players (Moving Picture Experts Group Audio Layer III), MP4 players (Moving Picture Experts Group Audio Layer IV), laptops, and desktop computers.

[0017] Server 103 can be a server that provides various services, such as a backend server that provides support for the pages displayed on terminal device 101.

[0018] It should be noted that the service exception handling method provided in this application embodiment is generally executed by the server / terminal device, and correspondingly, the service exception handling device is generally set in the server / terminal device.

[0019] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0020] Continue to refer to Figure 2 The flowchart illustrates an embodiment of a service exception handling method according to this application. The service exception handling method includes the following steps: Step S201: Obtain performance metrics data, tracing data, and business log data of the target service from the service cluster.

[0021] In this embodiment, a service cluster refers to a collection of multiple independently deployed microservices that communicate and interact via network, used to jointly handle complex business processes such as insurance underwriting and medical settlement. In this embodiment, it is the direct source of performance metrics data, tracing data, and business log data, and also the object upon which governance operations are ultimately performed.

[0022] In this embodiment, the target service refers to any independently running microservice instance within the service cluster that possesses complete business processing capabilities. In insurance and healthcare scenarios, the target service can be any business unit such as customer risk underwriting service, premium calculation service, medical insurance catalog verification service, or medical expense splitting service.

[0023] In this embodiment, performance index data refers to structured quantitative data that is continuously collected by the collection component (Agent) deployed in the service cluster at a fixed time granularity and persistently stored in the form of a time sequence. It is used to objectively quantify the real-time resource consumption, concurrent carrying capacity, interface processing efficiency and operational stability of the target service.

[0024] In this embodiment, tracing data refers to the structured logs generated by the distributed tracing system when a request passes through the target service and its upstream and downstream dependent services. Each data entry contains a globally unique tracing ID, used to fully record the call path, timing, and time consumption of each stage of the request in a cross-service and cross-host environment, serving as the data foundation for constructing the inter-service dependency graph.

[0025] In this embodiment, business log data consists of records containing specific business semantics generated by the target service during the execution of business logic, such as processing an insurance claim or calculating a medical expense. Each business log entry can be associated with a business transaction number and records key information such as input parameters, processing steps, intermediate results, and final business status.

[0026] Step S202: Based on the comparison results between the performance index data and the preset threshold set, determine whether the target service is in an abnormal state.

[0027] In this embodiment, the threshold set refers to a collection of multi-dimensional indicator thresholds that are pre-configured and persistently stored in the configuration center, based on the service's long-term stable operation baseline and combined with timeliness and concurrency tolerance standards for different business scenarios. The set is a structured grouped storage structure, internally maintaining three independent sets of non-interfering threshold standards, namely query frequency threshold, response latency threshold, and request error threshold.

[0028] In this embodiment, the comparison result refers to the conclusion output after comparing the measured value of the performance indicator data with the threshold of the same type within the threshold set. This conclusion is used to determine whether the target service is judged to have entered an abnormal state.

[0029] In this embodiment, an abnormal state refers to a situation where multiple or one real-time performance indicators of the target service exceed a preset safety threshold range, causing the target service's operation to deviate from a standardized stable baseline. In this state, the target service may experience explicit problems such as slow interface processing, failed batch business requests, and insufficient concurrent handling capacity.

[0030] In this embodiment, if the target service does not have an abnormal state, the current detection process is terminated directly, and the performance index data, link tracing data and business log data generated in real time by the service cluster are continuously monitored and collected, and the index comparison and anomaly judgment steps are executed in a loop.

[0031] Step S203: If the target service is in an abnormal state, a service dependency graph is constructed based on the link tracing data, and the propagation path of the abnormal state is determined based on the service dependency graph.

[0032] In this embodiment, the service dependency graph refers to a topology model generated based on link tracing data, using a directed acyclic graph (DAG) as a carrier to achieve a visual and structured representation. Nodes in the graph correspond to the target service and its associated services, and edges correspond to the call hierarchy between the target service and its associated services. This fully reconstructs the entire service interaction network involved in abnormal business requests flowing through the target service, and is used to locate the path of anomaly propagation.

[0033] In this embodiment, the propagation path refers to the output result after traversing the service dependency graph. It refers to the sequence of consecutive service nodes that the abnormal state passes through from the fault initiation node to the target service based on the call hierarchy, and fully records the sequential propagation link of the abnormal spread.

[0034] Step S204: Obtain abnormal business log data, code change records, and resource status data corresponding to all nodes covered by the propagation path, and generate prompt word information based on the business log data, code change records, and resource status data.

[0035] In this embodiment, abnormal business log data refers to the set of associated log fragments corresponding to all nodes covered by the propagation path, which are selected from the business logs after the target service is determined to be in an abnormal state. This data is used to reconstruct the actual error reporting behavior of each node in the original link when the abnormality occurred.

[0036] In this embodiment, code change records refer to the complete code version change archives that are stored uniformly in the configuration management system and are retained throughout the service iterations and releases corresponding to all nodes covered by the propagation path. These archives can include all dimensions of change content such as code submitter, submission time, added / deleted / modified code files, interface logic changes, configuration parameter updates, and version launch time.

[0037] In this embodiment, resource status data refers to a set of cluster operation metrics continuously and periodically collected and persistently stored by the resource acquisition system. The collected data includes real-time operation metrics of hardware, software, and middleware resources such as CPU utilization, memory usage, disk I / O, network bandwidth, database connection pool, and thread pool for all service running containers / processes corresponding to all nodes covered by the propagation path. This data can reflect whether the target service has underlying issues such as resource exhaustion, resource preemption, or performance bottlenecks during abnormal phases.

[0038] In this embodiment, the prompt message refers to a dedicated text message generated by integrating fault-related content contained in three types of data: abnormal business log data, code change records, and resource status data. This message centrally carries three types of fault contexts: business errors, code version changes, and service resource malfunctions.

[0039] Step S205: Using a preset abnormal root cause analysis model, based on the prompt word information, generate an abnormal root cause set and a repair decision instruction corresponding to each abnormal root cause in the abnormal root cause set.

[0040] In this embodiment, the anomaly root cause analysis model refers to an intelligent analysis and reasoning model that is pre-deployed and fine-tuned. This model can have a built-in paired encoder and decoder structure to receive generated prompt word information. Relying on pre-learned massive microservice fault samples and operation and maintenance governance knowledge, it automatically mines and deduces the underlying causes of the target service anomalies, replacing manual experience judgment, and completing the identification and output of anomaly root causes.

[0041] In this embodiment, the set of abnormal root causes refers to the structured result set finally output after model decoding, which contains at least one or more independent abnormal root causes.

[0042] In this embodiment, each root cause refers to a single, independent, and distinguishable fault trigger within the set of root causes. It is the smallest fault unit that causes the target service to malfunction. Each root cause corresponds to a specific type of service fault, accurately identifying different fault types such as resource bottlenecks, code defects, and link blockages.

[0043] In this embodiment, the repair decision instruction refers to the standardized, executable, automated governance instruction obtained after matching the decision mapping table according to the anomaly root cause type.

[0044] Step S206: Based on the repair decision instructions and the set of abnormal root causes, perform governance operations corresponding to each abnormal root cause on the target service to eliminate the abnormal state.

[0045] In this embodiment, governance operations refer to targeted, categorized, and differentiated automated repair and control behaviors executed on target service links, service instances, traffic scheduling, and resource capacity based on the anomaly root cause type, detailed description of the anomaly root cause, and the matched repair decision instructions. This is used to accurately eliminate various microservice anomaly states, achieving self-healing governance of business systems without human intervention.

[0046] This application's embodiments comprehensively cover service operation information by collecting cluster performance indicators, link tracing, and business log data from multiple dimensions, ensuring the data integrity of anomaly detection. It automatically identifies service anomalies based on threshold comparison, eliminating reliance on continuous manual inspection. By constructing a service dependency graph using link data, it automatically reconstructs fault propagation paths, eliminating the need for manual layer-by-layer tracing of call chains. It integrates logs, code changes, and resource data to generate prompt words, improving the input materials for root cause analysis. The model outputs a set of root causes and corresponding repair instructions, achieving intelligent root cause localization. Based on the repair instructions, it automatically executes corresponding governance operations, completing anomaly self-healing and improving anomaly handling efficiency. Overall, it significantly reduces the degree of manual intervention and shortens fault repair time.

[0047] In some optional implementations of this embodiment, step 202, determining whether the target service is in an abnormal state based on the comparison result of performance indicator data and a preset threshold set, specifically includes the following steps: Extract query frequency, response latency, and request error rate from the performance metrics data; compare the query frequency, response latency, and request error rate with the corresponding query frequency threshold, response latency threshold, and request error rate threshold in the preset threshold set; if at least one of the query frequency, response latency, and request error rate is greater than or equal to the corresponding threshold, then it is determined that the target service is in an abnormal state.

[0048] The query frequency value refers to the total number of all business query requests received and processed by the target service, collected and statistically analyzed within a preset fixed statistical window. The response latency value refers to the total time taken for a single complete business query request, from receiving the complete request message from the target service, completing all internal logical operations, invoking downstream dependent resources, to generating a complete response message and returning it to the caller. The request error rate refers to the percentage of business requests that failed to be processed within a single unified statistical period, out of the total number of valid business requests in that period.

[0049] The query frequency threshold refers to the maximum allowed number of query requests, set based on the upper limit of service hardware resources, the peak concurrency of normal business operations, and the capacity for expansion during peak business periods. The response latency threshold refers to the maximum allowed total time for a single business request, set based on the industry's strict requirements for real-time business processing. Different business links have independent standards; exceeding this threshold indicates that the interface processing efficiency does not meet business delivery standards. The request error threshold refers to the maximum allowed percentage of periodically erroneous requests, set based on business fault tolerance standards and customer complaint risk thresholds.

[0050] In one example, the system pre-deploys collection agents on all business nodes of the insurance and healthcare microservice clusters. Each collection agent continuously bypasses the system to capture the full runtime data stream of the target service, including time-series performance metrics, link tracking data, and business operation logs, and pushes them uniformly to the message bus for data aggregation. The system consumes the raw performance metric data of the target service within the bus through the metric analysis agent. First, it performs data cleaning to remove invalid and interfering data such as batch load testing requests from the insurance system and debugging test requests from the hospital system. Then, it separates and extracts three core quantitative parameters from the standardized metric stream: query frequency value, response latency value, and request error rate. Subsequently, the metric analysis agent retrieves a threshold set adapted to the current business scenario, distinguishes between two sets of differentiated critical standards for auto insurance underwriting and outpatient medical insurance settlement, and compares the three extracted measured metrics one by one with the matching query frequency threshold, response latency threshold, and request error rate threshold within the set, generating an independent comparison result for each metric. The system has a built-in multi-condition or logical judgment unit that iterates through the comparison results of three indicators. If any measured value of the query frequency, response latency, or request error rate is greater than or equal to the corresponding business threshold, the medical insurance settlement service / insurance underwriting target service is marked as being in an abnormal state. The indicator analysis agent is deployed in the service anomaly handling system corresponding to this embodiment. It is a dedicated analysis unit that consumes the performance indicator data stream stored in the message queue. This service anomaly handling system also includes a trace analysis component (Trace Analysis Agent), a root cause analysis component (Root Cause Analysis Agent), a governance execution component (Governance Execution Agent), and an effectiveness evaluation component (Effectiveness Evaluation Agent).

[0051] This application's embodiments accurately extract three core quantitative parameters—query frequency, response latency, and request error rate—to simultaneously cover three risk dimensions: concurrent load, interface timeliness, and program stability, adapting to the fault identification needs of multiple business links. By comparing indicators item by item using a set of thresholds specific to each business, and relying on objective values ​​to complete the judgment, it eliminates subjective biases caused by the experience of operations personnel. The judgment logic that marks any indicator exceeding the limit as abnormal can quickly identify sudden faults such as traffic overload, settlement delays, and batch business errors, capturing abnormal nodes in advance.

[0052] In some optional implementations, step S203, constructing a service dependency graph based on the link tracing data and determining the propagation path of the abnormal state based on the service dependency graph, specifically includes the following steps: The link tracing data is parsed and processed to obtain the call hierarchy and call time between the target service and related services. A directed acyclic graph (DAG) is generated based on the call hierarchy as a service dependency graph. The nodes of the DAG represent the target service and related services, and the edges represent the call hierarchy. The nodes in the service dependency graph that are in an abnormal state are traversed, and the propagation path of the abnormal state is determined by combining the call time and the call hierarchy.

[0053] Among them, associated services refer to the interaction objects that the target service calls externally and are called by other services, as recorded in the link tracing data. Other microservices that have interface call interactions with the target service are defined as associated services.

[0054] The call hierarchy relationship refers to the relationship between the target service and its related services during a single business request flow, which is obtained by parsing the obtained link tracing data. It represents the order of upstream and downstream calls and the nested subordinate hierarchy between the target service and its related services. It is used to distinguish who is the call initiator and who is the callee.

[0055] Among them, the call time is a quantitative parameter stored in the link tracing data and extracted during the parsing process. It refers to the total time consumed by a single cross-service interface interaction between the target service and the corresponding related service, and can reflect the degree of blocking and latency of a single call link.

[0056] Among them, the directed acyclic graph is a graphical data structure selected for its unidirectional business call chain and the absence of circular calls. This structure relies on nodes and edges with unidirectional pointing to describe the relationship between objects. There are no closed loop paths, and it is used to carry the call topology of the target service and related services.

[0057] In one example, the system continuously consumes the link tracing data stream corresponding to the target service from the distributed message bus through a link tracing analysis component (Trace Analysis Agent). First, the link tracing data is standardized and parsed, removing invalid link records generated by duplicate collections and test requests. From the cleaned link data, interaction records are disassembled one by one to extract the complete call hierarchy relationship between the current target service and all related services. Simultaneously, the call time corresponding to each set of service interactions is extracted, and both types of information are stored in a temporary topology dataset. Based on the standardized call hierarchy relationship within the temporary topology dataset, a directed acyclic graph adapted to unidirectional business links is constructed, and this graph is defined as a service dependency graph. The target service and all related services are mapped to independent nodes within the graph, and unidirectional directed edges are generated according to the upstream and downstream call order to represent the call hierarchy relationship. The corresponding call time is used as an additional weight parameter for the edges. After the graph is constructed, the Trace analysis agent filters out the service nodes in the graph that have been determined to be in an abnormal state and starts the full graph traversal process. It searches for upstream and downstream nodes layer by layer along the direction of the directed edges, and judges the nodes with delayed amplification by combining the call time values ​​bound to each edge. Finally, it sorts out and outputs the complete abnormal state propagation path from the source node to the target service.

[0058] This application's embodiments utilize a link tracing analysis component to parse link tracing data and extract two core parameters: call level and call duration. This automatically extracts effective topology information from massive amounts of link data, saving the workload of manually tracing each call relationship. By constructing a directed acyclic graph (DAG) based on call hierarchy relationships as a service dependency graph, it can standardize and reconstruct complex multi-service interaction networks, avoiding issues like missing nodes or incorrect ordering that can occur when manually tracing links. Traversing abnormal nodes in the graph and combining call duration and hierarchy relationships to deduce propagation paths, it can automatically distinguish between primary and secondary fault nodes, quickly determining the propagation path of abnormal states.

[0059] In some optional implementations, the step "traversing the nodes in the service dependency graph that are in an abnormal state, and determining the propagation path of the abnormal state by combining the call time and call hierarchy" specifically includes the following steps: The abnormal state of the target service is mapped to the corresponding node in the service dependency graph, which is then designated as the abnormal node. Based on the call duration, starting from the abnormal node, the nodes whose call duration exceeds the preset propagation threshold are identified as propagation nodes along the edges of the directed acyclic graph. The abnormal node and the propagation node are marked in the service dependency graph, and the abnormal node and the propagation node are connected according to the call hierarchy to obtain the propagation path of the abnormal state.

[0060] Among them, an abnormal node refers to a node in the service dependency graph that represents the target service and related services. After the target service is determined to be in an abnormal state through indicator analysis, the abnormal result is bound to the node corresponding to the target service in the graph. It is the starting point for tracing the abnormal spread chain.

[0061] The propagation threshold refers to a pre-configured numerical standard used to filter abnormal propagation links, with the call time of a single service interaction as the criterion. When the call time between two services exceeds this threshold, it indicates that the link is significantly blocked and has amplified latency, exhibiting characteristics of propagating abnormalities outward, thus providing a quantitative judgment standard for filtering propagation nodes.

[0062] Among them, the propagation node refers to the node that is searched sequentially along the call chain from the abnormal node during the traversal of the service dependency graph. If the call time between a certain related service node and the adjacent service exceeds the preset propagation threshold, it means that the link where the node is located has a delay amplification and has the characteristic of receiving and continuing to propagate the abnormal state. The selected node is the propagation node.

[0063] In one example, the system uses a Trace analysis agent to read the completed service dependency graph and the target service anomaly determination results output by the indicator analysis component, and then performs node mapping operations. Specifically, the Trace analysis agent locates the node in the graph that uniquely corresponds to the target service, writes a unique anomaly identifier field for this node, completes the binding of the anomaly state to the graph node, and generates an initial anomaly node. The Trace analysis agent retrieves the system's pre-configured propagation threshold parameters, and using the anomaly node as the starting point, traverses the upstream and downstream related nodes along the unidirectional edges of the directed acyclic graph according to the call hierarchy. During the traversal, it reads the call time weight bound to each edge, compares the real-time call time with the propagation threshold one by one, and marks the corresponding service node as a propagation node and temporarily caches it if the current link call time exceeds the propagation threshold. After the full link traversal is completed, all anomaly nodes and propagation nodes are visually marked and distinguished in the service dependency graph using differentiated identifiers. Then, based on the call hierarchy relationship corresponding to the original directed edges of the graph, all continuously distributed anomaly nodes and propagation nodes are connected to form an ordered node sequence, and finally, a complete and continuous anomaly state propagation path is output.

[0064] This application's embodiments generate abnormal nodes by mapping the abnormal state of the target service to corresponding nodes in the graph, enabling rapid identification of the fault retrieval starting point without requiring manual location of the faulty service in complex topologies. It filters propagation nodes based on call duration and preset propagation thresholds, and uses quantified values ​​to filter abnormal propagation links, avoiding omissions, delays, and blocked links due to subjective human judgment. Differentiated marking of abnormal and propagation nodes allows for intuitive differentiation between the fault source node and secondary affected nodes. By connecting marked nodes according to the call hierarchy to generate propagation paths, it automatically organizes the complete fault propagation chain, significantly reducing the workload of manually checking each layer of the link in multi-service long-link scenarios.

[0065] In some optional implementations, step S204 involves obtaining abnormal business log data, code change records, and resource status data corresponding to all nodes covered by the propagation path, and generating prompt word information based on the business log data, code change records, and resource status data. This specifically includes the following steps: The system retrieves abnormal business log data corresponding to all nodes covered by the propagation path from the business log data; it retrieves code change records corresponding to all nodes covered by the propagation path from the configuration management system and resource status data corresponding to all nodes covered by the propagation path from the resource acquisition system. The configuration management system is used to store change data for each service in the service cluster, and the resource acquisition system is used to collect resource operation data for each service in the service cluster. Error feature information is extracted from the abnormal business logs, version difference information is extracted from the code change records, and resource usage information is extracted from the resource status data. The error feature information, version difference information, and resource usage information are concatenated according to a preset text template to obtain prompt word information.

[0066] The configuration management system is used to unify the lifecycle change data of all microservices within the managed service cluster. It supports searching code commit records, configuration modification records, and release records by service name, time range, and version number. Queries can be sent to this system via standardized interfaces to quickly and accurately retrieve code change records for the target service during the corresponding time period.

[0067] Among them, the resource collection system refers to the routine indicator collection subsystem deployed on the service cluster side. It relies on the cluster node collection probes to continuously collect and persistently store the resource operation indicators of each microservice process, container, and related middleware within the cluster.

[0068] Among them, error feature information refers to a standardized set of fault identifiers obtained by parsing and extracting abnormal business log data one by one in a structured manner.

[0069] Among them, version difference information refers to the summary of changes obtained by comparing the current online version with the previous stable and error-free version after reading the code change record.

[0070] Among them, resource occupancy information refers to a summary of quantitative indicators obtained after statistical analysis, filtering, and refinement of resource status data.

[0071] Among them, the text template refers to the standardized structured text framework that is pre-configured and persistently stored by the system. The template has a fixed descriptive order, information segmentation logic, and dedicated placeholder fields for various fault information. It strictly defines the layout order, description specifications, and supplementary explanation format for three types of information: error characteristics, version differences, and resource usage.

[0072] In one example, after the link tracing analysis component determines the propagation path of the abnormal state, the root cause analysis agent triggers the entire process of generating prompt words. The root cause analysis agent first reads the previously collected business log data of the target service from the distributed message queue. Using the time interval of the anomaly, the set of unique service identifiers of all nodes covered by the propagation path, and the faulty interface obtained from the link tracing as multiple filtering conditions, it matches and filters the massive logs one by one, eliminating irrelevant normal business logs, and aggregating the successfully matched faulty log fragments to generate abnormal business log data corresponding to all nodes covered by the propagation path. Subsequently, the root cause analysis agent initiates two parallel cross-system data queries: one calls the configuration management system query interface, passing in the set of service names of all nodes covered by the propagation path and the time range before and after the anomaly, to retrieve all commits and deployment files of all nodes covered by the propagation path during that period, obtaining a complete code change record; the other calls the resource acquisition system indicator query interface to obtain full-dimensional resource operation indicators of all nodes covered by the propagation path within the same time window, forming resource status data. The root cause analysis agent performs structured extraction processing on three types of data: it traverses abnormal business logs, extracting error codes, exception stack traces, and faulty interfaces to form error feature information; it compares code change updates with older versions of files, extracting modification logic to generate version difference information; and it statistically analyzes peak and over-limit records of resource indicators, extracting abnormal resource fluctuation data to obtain resource usage information. The root cause analysis agent loads a pre-set fault description text template from the system, sequentially filling the corresponding placeholder areas of the template with the three types of extracted structured information, and concatenating and integrating them according to the template's prescribed word order and segmentation rules. Finally, it outputs a uniformly formatted prompt message that covers multi-dimensional fault context.

[0073] This application's embodiments automatically filter out massive amounts of irrelevant logs and compress invalid data by screening abnormal business log data, reducing the computational overhead for subsequent information extraction. It interfaces with the configuration management system and resource acquisition system to retrieve change and resource data, simultaneously covering two major fault-causing dimensions: code defects and resource bottlenecks, eliminating the need for operations personnel to manually aggregate data across multiple platforms. It extracts standardized error features, version differences, and resource usage information in a layered manner, transforming messy raw data into structured elements easily identifiable by the model. It uses a unified text template to generate prompt words, standardizing the expression logic of multi-source heterogeneous data, ensuring the complete and orderly fault context input to the large model, and effectively improving the accuracy of root cause reasoning.

[0074] In some optional visual modes, step S205 involves using a preset abnormal root cause analysis model to generate an abnormal root cause set and corresponding repair decision instructions for each abnormal root cause in the abnormal root cause set, based on the prompt word information. This specifically includes the following steps: The prompt word information is input into a preset anomaly root cause analysis model. The encoder of the anomaly root cause analysis model encodes the prompt word information to obtain a semantic feature vector. The decoder of the anomaly root cause analysis model decodes the semantic feature vector to obtain an anomaly root cause set containing at least one anomaly root cause. The anomaly root cause set includes the anomaly root cause type of each anomaly root cause. For each anomaly root cause, the corresponding anomaly root cause type is matched in a preset decision mapping table to determine the corresponding repair decision instruction for each anomaly root cause.

[0075] The encoding process refers to the pre-processing feature transformation operation performed by the built-in encoder of the anomaly root cause analysis model, which is a core upstream step in model inference. This process performs structured parsing, semantic extraction, and feature digitization mapping on text-formatted prompt words, transforming natural language text carrying business errors, code changes, and resource anomalies into a standardized numerical vector form that the model can compute.

[0076] The decoding process refers to the intelligent reasoning operation performed by the built-in decoder of the anomaly root cause analysis model. It is the reverse parsing and result output process of the encoding process. This process performs deep feature parsing, fault logic deduction, and information reconstruction on the semantic feature vector output by the encoder, mines potential fault correlations from high-dimensional digital features, and finally infers and outputs structured fault root cause results.

[0077] In one example, the system inputs the integrated complete prompt word information into a preset anomaly root cause analysis model via a root cause analysis agent, initiating an intelligent root cause diagnosis process. The anomaly root cause analysis model first calls its built-in encoder to encode the text-type prompt word information. Through semantic parsing, feature extraction, and dimensional mapping, it accurately transforms the unstructured natural language fault description into a high-dimensional semantic feature vector that can be deeply computed by the model, fully preserving all key features of the fault context. Subsequently, the anomaly root cause analysis model calls its built-in decoder to perform comprehensive decoding and reasoning on the semantic feature vector, deeply mining the fault correlation logic and anomaly causes hidden in the vector features. It identifies one or more independent fault factors causing the target service anomaly, automatically summarizing and generating an anomaly root cause set, and automatically matching and labeling each independent anomaly root cause within the set with its corresponding standardized anomaly root cause type. Finally, the component iterates through all anomaly root causes in the anomaly root cause set, extracting the anomaly root cause type corresponding to each root cause as search keywords. It performs precise comparison and matching in the system's preset decision mapping table, and automatically determines a unique, executable repair decision instruction for each type of anomaly root cause based on the preset type mapping relationship.

[0078] This application embodiment uses the encoder built into the anomaly root cause analysis model to encode and transform prompt word information, converting messy text fault information into regular semantic feature vectors, effectively filtering invalid information, and improving the model's fault identification accuracy and computational efficiency. Relying on the decoder built into the anomaly root cause analysis model to decode and infer feature vectors, it can automatically identify multiple complex faults and generate a complete set of root causes, solving the problem of manual omission of multiple root cause faults. By standardizing root cause types to classify faults, unified hierarchical management of faults is achieved. Based on a preset decision mapping table to match repair instructions, appropriate governance instructions can be automatically generated without manual judgment, greatly shortening the diagnosis and repair time of service anomalies.

[0079] In some optional implementations, the root cause set also includes a description of each root cause. Step S206 involves performing governance operations corresponding to each root cause on the target service based on the repair decision instruction and the root cause set to eliminate the abnormal state. This specifically includes the following steps: If the root cause type is a service dependency failure, then according to the root cause description, a circuit breaker rule is sent to the target service so that the target service can block the call chain with downstream services according to the circuit breaker rule. If the root cause type is a performance bottleneck, then according to the repair decision instruction, the current number of instances of the target service is obtained, and a new instance is created based on the current number of instances and the root cause description, and the new instance is allocated to the node where the target service is located. If the root cause type is an instance exception, then the instance status of the target service is obtained, and according to the instance status and the root cause description, the exception instance and healthy instance of the target service are determined, and the access request corresponding to the exception instance is routed to the healthy instance.

[0080] Service dependency failures refer to a type of failure where the target service itself has no code defects or resource overload issues, and the exception is entirely caused by timeouts, errors, or unavailability of downstream dependent services. Furthermore, the failure propagates backward through the upstream and downstream call chains, leading to a chain reaction of response delays and call failures in the target service. The root cause of this type of failure lies in the failure of the cross-service dependency chain, rather than a single service failure; therefore, it is necessary to isolate the chain to prevent the failure from spreading.

[0081] The circuit breaker rule refers to a structured set of governance strategy parameters used to handle service dependency failures. It consists of downstream service information, call failure threshold, circuit breaker triggering conditions, circuit breaker duration, and half-open recovery detection mechanism. After the rule is issued and loaded into the target service, it can proactively identify invalid call requests to downstream failures, automatically intercept abnormal, invalid, and time-consuming cross-service calls, proactively disconnect abnormal dependency links, and prevent downstream failures from spreading upwards from the source.

[0082] Performance bottlenecks refer to performance-related failures where the target service's code logic is normal and the service chain is without anomalies, but a sudden surge in business concurrency, insufficient instance computing power, or exhaustion of resource quotas leads to full load of CPU, memory, thread pool, and database connection pool on a single instance, resulting in request backlog and soaring response latency. This type of failure does not involve link failures or instance downtime; it simply means that the service's carrying capacity cannot match the business traffic. The solution is to horizontally scale up the service to improve its overall throughput.

[0083] The current instance count refers to the total number of valid instances of the target service that are running normally and in a schedulable state in the cluster scheduling system at the time of the failure, which is real-time dynamic quantitative data for the cluster.

[0084] The new instance refers to a brand-new running instance of the target service created on demand to address performance bottleneck anomalies. It is an independent container running unit with a complete service running environment and business processing capabilities. After the new instance is created, it is uniformly incorporated into the target service cluster scheduling system and shares business traffic with the original instance. By horizontally expanding computing resources, it fills the performance gap and solves the performance bottleneck problems of excessive single instance load, traffic congestion, and excessive request latency.

[0085] Among them, instance anomalies refer to localized failures where some cluster instances of the same target service experience process errors, crashes, or interface unavailability, while the remaining instances function normally. These failures are not issues affecting the overall service, network, or resources, but rather isolated failures of individual instances within a distributed cluster deployment. This can cause random errors, localized traffic failures, and a decrease in overall service stability. Faulty instances can be isolated through traffic migration.

[0086] Among them, abnormal instances are a subset of the running instances in the target service cluster. They refer to service running instances that exhibit abnormal characteristics such as process freezing, port listening failure, business interface errors, and inability to release resources during abnormal periods, thus losing their normal business processing capabilities and being unable to stably handle access traffic. Continuous access to these instances will continuously generate errors and delays, and they are the direct failure points of instance abnormality faults.

[0087] Among them, healthy instances are a subset of the running instances of the target service cluster. They refer to normal service instances that are running normally, using resources reasonably, making normal interface calls, and having no errors or blockages during the period when the anomaly occurred, and that fully possess standard business processing capabilities.

[0088] In one example, the system receives the complete set of anomaly root causes and corresponding remediation decision instructions output by the root cause analysis agent through the governance execution agent. It then reads the anomaly root cause description and type for each anomaly root cause in the set and executes differentiated governance operations according to the type branch. If the root cause type is identified as a service dependency failure, the governance execution component extracts the anomaly root cause description associated with this root cause, clarifies parameters such as the downstream service identifier and call timeout threshold, generates matching circuit breaker rules based on these parameters, and distributes the circuit breaker rules to the target service through the service mesh interface. After the target service loads the rules, it automatically intercepts interface calls to the downstream service, preventing the failure from propagating upwards along the dependency chain. If the root cause type is identified as a performance bottleneck, the governance execution agent parses the remediation decision instructions, calls the cluster interface, and queries the real-time current number of instances of the target service. Combining the concurrency peak and resource gap data recorded in the anomaly root cause description, it calculates the expansion requirements, schedules the cluster orchestration component to create the corresponding number of new instances, and allocates the new instances to the cluster nodes to which the target service belongs, distributing business requests to alleviate resource bottlenecks. If the root cause type is identified as an instance anomaly, the governance execution agent calls the cluster monitoring interface to retrieve the real-time instance status of all instances of the target service; combined with the error instance characteristics recorded in the anomaly root cause description, the abnormal instances and healthy instances in the cluster are distinguished; the load balancing scheduling strategy is modified to cut off access traffic to abnormal instances, and all business requests originally allocated to abnormal instances are uniformly routed and forwarded to healthy instances, thus isolating the impact of faulty instances on the business.

[0089] This application's embodiments perform differentiated governance operations based on different root cause types of anomalies. This allows for targeted adaptation to three typical microservice anomalies: link propagation, performance overload, and instance failure, addressing the poor adaptability of traditional unified governance methods. Customized circuit breaker rules are issued based on root cause descriptions, precisely blocking fault-dependent links and effectively preventing cascading failures in complex businesses. Expanding to new instances based on real-time instance count and fault characteristics accurately fills performance gaps, avoiding resource waste or insufficient expansion. Accurately distinguishing between abnormal and healthy instances and migrating traffic isolates faulty nodes without interrupting business operations, significantly improving the operational stability and self-healing capabilities of distributed cluster services.

[0090] In some optional implementations, the service anomaly handling system also includes an effectiveness evaluation component. After the steps of executing governance operations corresponding to each anomaly root cause on the target service to eliminate the abnormal state based on the repair decision instructions and the set of anomaly root causes, the system further includes: obtaining performance indicator data after the governance operations are executed through the effectiveness evaluation component, generating evaluation feedback data based on this data, and updating the anomaly root cause analysis model based on the evaluation feedback data. By continuously collecting performance indicator data after the governance operations are completed, the actual changes brought about by self-healing actions such as circuit breaking, capacity expansion, and traffic migration to the target service's operational status can be intuitively quantified, and real operational samples after governance implementation can be completely preserved. Based on the standardized evaluation feedback data generated from the post-performance indicators, the matching degree between the current root cause determination and the repair instructions can be objectively assessed, distinguishing between effective governance and scenarios with deviations in handling. Iteratively updating the anomaly root cause analysis model using evaluation feedback data can continuously supplement real fault governance samples, correct model inference biases, and form a complete closed loop of fault diagnosis, automatic repair, effectiveness review, and model iteration. After long-term iteration, the model's accuracy in identifying faults in complex business processes in insurance and healthcare has been continuously improved, gradually reducing the frequency of manual intervention and continuously shortening the average fault repair time.

[0091] The embodiments of this application can acquire and process relevant data based on artificial intelligence technology. Artificial intelligence (AI) refers to the theories, methods, technologies, and application systems that use digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to obtain optimal results.

[0092] Foundational technologies for artificial intelligence generally include sensors, dedicated AI chips, cloud computing, distributed storage, big data processing, operating / interactive systems, and mechatronics. AI software technologies mainly encompass computer vision, robotics, biometrics, speech processing, natural language processing, and machine learning / deep learning.

[0093] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by instructing related hardware through computer-readable instructions. These computer-readable instructions can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above methods. The aforementioned storage medium can be a non-volatile storage medium such as a magnetic disk, optical disk, or read-only memory (ROM), or random access memory (RAM).

[0094] Further reference Figure 3As a response to the above Figure 2 To implement the method shown, this application provides an embodiment of a service exception handling device, which is similar to... Figure 2 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0095] like Figure 3 As shown, the service exception handling device 400 of this embodiment includes: a first acquisition module 401, a judgment module 402, a construction module 403, a second acquisition module 404, a generation module 405, and an execution module 405. Wherein: The first acquisition module 401 is used to acquire performance index data, tracing data and business log data of the target service from the service cluster; The judgment module 402 is used to determine whether the target service is in an abnormal state based on the comparison result between the performance index data and the preset threshold set. Module 403 is used to construct a service dependency graph based on the link tracing data if the target service has an abnormal state, and to determine the propagation path of the abnormal state based on the service dependency graph. The second acquisition module 404 is used to acquire abnormal business log data, code change records and resource status data corresponding to all nodes covered by the propagation path, and generate prompt word information based on the business log data, code change records and resource status data; The generation module 405 is used to generate a set of abnormal root causes and corresponding repair decision instructions for each abnormal root cause in the set of abnormal root causes based on prompt word information using a preset abnormal root cause analysis model. The execution module 406 is used to perform governance operations corresponding to each abnormal root cause on the target service according to the repair decision instructions and the set of abnormal root causes, so as to eliminate the abnormal state.

[0096] This application's embodiments comprehensively cover service operation information by collecting cluster performance indicators, link tracing, and business log data from multiple dimensions, ensuring the data integrity of anomaly detection. It automatically identifies service anomalies based on threshold comparison, eliminating reliance on continuous manual inspection. By constructing a service dependency graph using link data, it automatically reconstructs fault propagation paths, eliminating the need for manual layer-by-layer tracing of call chains. It integrates logs, code changes, and resource data to generate prompt words, improving the input materials for root cause analysis. The model outputs a set of root causes and corresponding repair instructions, achieving intelligent root cause localization. Based on the repair instructions, it automatically executes corresponding governance operations, completing anomaly self-healing and improving anomaly handling efficiency. Overall, it significantly reduces the degree of manual intervention and shortens fault repair time.

[0097] In one embodiment, the determination module 402 includes: The first extraction submodule is used to extract query frequency, response latency, and request error rate from performance metrics data. The comparison submodule is used to compare the query frequency value, response latency value, and request error rate with the corresponding query frequency threshold, response latency threshold, and request error threshold in the preset threshold set, respectively. The first determination submodule is used to determine that the target service is in an abnormal state if at least one of the query frequency value, response latency value, and request error rate is greater than or equal to the corresponding threshold.

[0098] In one embodiment, the construction module 403 includes: The parsing submodule is used to parse and process the link tracing data to obtain the call hierarchy and call time between the target service and related services; The generation submodule is used to generate a directed acyclic graph (DAG) based on the call hierarchy, which serves as a service dependency graph. The nodes of the DAG represent the target service and related services, and the edges represent the call hierarchy. The traversal submodule is used to traverse the nodes in the service dependency graph that are in an abnormal state, and determine the propagation path of the abnormal state by combining the call time and call hierarchy.

[0099] In one embodiment, the traversal submodule is further configured to map the abnormal state of the target service to the corresponding node in the service dependency graph as the abnormal node; based on the call time, starting from the abnormal node, along the edges of the directed acyclic graph, sequentially determine the nodes whose call time exceeds a preset propagation threshold as propagation nodes; mark the abnormal node and the propagation node in the service dependency graph, and connect the abnormal node and the propagation node according to the call hierarchy to obtain the propagation path of the abnormal state.

[0100] In one embodiment, the second acquisition module 404 includes: The first acquisition submodule is used to obtain abnormal business log data corresponding to all nodes covered by the propagation path from the business log data; The second acquisition submodule is used to obtain code change records corresponding to all nodes covered by the propagation path from the configuration management system and resource status data corresponding to all nodes covered by the propagation path from the resource acquisition system. The configuration management system is used to store change data of each service in the service cluster, and the resource acquisition system is used to collect resource operation data of each service in the service cluster. The second extraction submodule is used to extract error feature information from abnormal business logs, version difference information from code change records, and resource usage information from resource status data. The splicing submodule is used to splice error feature information, version difference information, and resource usage information according to a preset text template to obtain prompt word information.

[0101] In one embodiment, the generation module 405 includes: The encoding submodule is used to input the prompt word information into the preset anomaly root cause analysis model, and to process it through the encoder of the anomaly root cause analysis model to obtain the semantic feature vector of the prompt word information. The decoding submodule is used to decode the semantic feature vector through the decoder of the abnormal root cause analysis model to obtain an abnormal root cause set containing at least one abnormal root cause. The abnormal root cause set includes the abnormal root cause type of each abnormal root cause. The matching submodule is used to match the corresponding abnormal root cause type in a preset decision mapping table for each abnormal root cause, and determine the corresponding repair decision instruction for each abnormal root cause.

[0102] In one embodiment, the execution module 406 includes: The sending submodule is used to send circuit breaker rules to the target service according to the description of the exception root cause if the exception root cause type is a service dependency failure class, so that the target service can block the call link with the downstream service according to the circuit breaker rules. The allocation submodule is used to obtain the current number of instances of the target service according to the repair decision instruction if the root cause of the exception is a performance bottleneck. Based on the current number of instances and the description of the root cause of the exception, a new instance is created and allocated to the node where the target service is located. The second determination submodule is used to obtain the instance status of the target service if the exception root cause type is an instance exception class, and determine the exception instance and healthy instance of the target service based on the instance status and the exception root cause description, and route the access request corresponding to the exception instance to the healthy instance.

[0103] To address the aforementioned technical problems, embodiments of this application also provide a computer device. Please refer to [link / reference needed]. Figure 4 , Figure 4 This is a basic structural block diagram of the computer device in this embodiment.

[0104] Computer device 6 includes a memory 61, a processor 62, and a network interface 63 that are interconnected via a system bus. It should be noted that only computer device 6 with memory 61, processor 62, and network interface 63 is shown in the figure; however, it should be understood that it is not required to implement all the components shown, and more or fewer components can be implemented alternatively. Those skilled in the art will understand that the computer device described herein is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions, and its hardware includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, etc.

[0105] Computer devices can include desktop computers, laptops, handheld computers, and cloud servers. These devices allow for human-computer interaction with users through methods such as keyboards, mice, remote controls, touchpads, or voice-activated devices.

[0106] The memory 61 includes at least one type of readable storage medium, including flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 61 may be an internal storage unit of the computer device 6, such as the hard disk or memory of the computer device 6. In other embodiments, the memory 61 may also be an external storage device of the computer device 6, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., provided on the computer device 6. Of course, the memory 61 may also include both internal storage units and external storage devices of the computer device 6. In this embodiment, the memory 61 is typically used to store the operating system and various application software installed on the computer device 6, such as computer-readable instructions for service exception handling methods, etc. In addition, the memory 61 may also be used to temporarily store various types of data that have been output or will be output.

[0107] In some embodiments, processor 62 may be a central processing unit (CPU), a controller, a microcontroller, a microprocessor, or other data processing chip. This processor 62 is typically used to control the overall operation of the computer device 6. In this embodiment, processor 62 is used to execute computer-readable instructions stored in memory 61 or to process data, such as computer-readable instructions for executing service exception handling methods.

[0108] The network interface 63 may include a wireless network interface or a wired network interface, which is typically used to establish a communication connection between the computer device 6 and other electronic devices.

[0109] This application also provides another embodiment, namely, providing a computer-readable storage medium storing computer-readable instructions that can be executed by at least one processor to cause the at least one processor to perform the steps of the service exception handling method described above.

[0110] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods of the various embodiments of this application.

[0111] Obviously, the embodiments described above are only some embodiments of this application, not all embodiments. The accompanying drawings show preferred embodiments of this application, but do not limit the patent scope of this application. This application can be implemented in many different forms; rather, the purpose of providing these embodiments is to provide a more thorough and comprehensive understanding of the disclosure of this application. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing specific embodiments, or make equivalent substitutions for some of the technical features. Any equivalent structures made using the content of this application's specification and drawings, directly or indirectly applied to other related technical fields, are similarly within the scope of patent protection of this application.

[0112] It should be noted that any AI models, software tools, or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. All user personal information involved in the embodiments of this application has been authorized (with the knowledge and consent) by the relevant parties or has been fully authorized by all parties, and the executing entity may obtain it through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals.

Claims

1. A service exception handling method, characterized in that, include: Obtain performance metrics data, tracing data, and business log data of the target service from the service cluster; Based on the comparison results between the performance index data and the preset threshold set, it is determined whether the target service is in an abnormal state; If the target service is in an abnormal state, a service dependency graph is constructed based on the link tracing data, and the propagation path of the abnormal state is determined based on the service dependency graph. Obtain abnormal business log data, code change records, and resource status data corresponding to all nodes covered by the propagation path, and generate prompt word information based on the business log data, the code change records, and the resource status data; Using a preset abnormal root cause analysis model, based on the prompt word information, an abnormal root cause set is generated, along with repair decision instructions corresponding to each abnormal root cause in the abnormal root cause set. Based on the repair decision instructions and the set of abnormal root causes, the target service is subjected to governance operations corresponding to each of the abnormal root causes in order to eliminate the abnormal state.

2. The method according to claim 1, characterized in that, The step of determining whether the target service is in an abnormal state based on the comparison result between the performance indicator data and a preset threshold set includes: Extract the query frequency value, response latency value, and request error rate from the performance metric data; The query frequency value, the response latency value, and the request error rate are compared with the corresponding query frequency threshold, response latency threshold, and request error threshold in the preset threshold set, respectively. If at least one of the query frequency value, the response latency value, and the request error rate is greater than or equal to the corresponding threshold, then the target service is determined to be in an abnormal state.

3. The method according to claim 1, characterized in that, The steps of constructing a service dependency graph based on the link tracing data and determining the propagation path of the abnormal state based on the service dependency graph include: The link tracing data is parsed and processed to obtain the call hierarchy relationship and call time between the target service and related services; A directed acyclic graph is generated based on the call hierarchy relationship as a service dependency graph. The nodes of the directed acyclic graph are the target service and the associated service, and the edges of the directed acyclic graph are the call hierarchy relationship. The nodes in the service dependency graph that are in the abnormal state are traversed, and the propagation path of the abnormal state is determined by combining the call time and the call hierarchy.

4. The method according to claim 3, characterized in that, The step of traversing the nodes in the service dependency graph that are in the abnormal state, and determining the propagation path of the abnormal state by combining the call time and the call hierarchy, includes: The abnormal state of the target service is mapped to the corresponding node in the service dependency graph, which is then used as the abnormal node. Based on the call duration, starting from the abnormal node, along the edges of the directed acyclic graph, nodes whose call duration exceeds a preset propagation threshold are sequentially identified as propagation nodes. The abnormal node and the propagation node are marked in the service dependency graph. The abnormal node and the propagation node are connected according to the call hierarchy to obtain the propagation path of the abnormal state.

5. The method according to claim 1, characterized in that, The step of obtaining abnormal business log data, code change records, and resource status data corresponding to all nodes covered by the propagation path, and generating prompt word information based on the business log data, the code change records, and the resource status data, includes: Obtain abnormal business log data corresponding to all nodes covered by the propagation path from the business log data; The configuration management system is used to store change data of each service in the service cluster, and the resource collection system is used to collect resource operation data of each service in the service cluster. Extract error feature information from the abnormal business logs, extract version difference information from the code change records, and extract resource usage information from the resource status data; According to the preset text template, the error feature information, the version difference information, and the resource usage information are concatenated to obtain the prompt word information.

6. The method according to claim 1, characterized in that, The step of generating a set of abnormal root causes and corresponding repair decision instructions for each abnormal root cause in the set of abnormal root causes based on the prompt word information using a preset abnormal root cause analysis model includes: The prompt word information is input into a preset anomaly root cause analysis model, and encoded by the encoder of the anomaly root cause analysis model to obtain the semantic feature vector of the prompt word information. The semantic feature vector is decoded by the decoder of the abnormal root cause analysis model to obtain an abnormal root cause set containing at least one abnormal root cause, and the abnormal root cause set includes the abnormal root cause type of each abnormal root cause. For each of the aforementioned root causes of anomalies, the corresponding root cause type is matched in a preset decision mapping table to determine the corresponding repair decision instruction for each root cause of anomalies.

7. The method according to claim 6, characterized in that, The set of root causes of anomalies also includes a description of the root cause of each anomaly; the step of performing governance operations corresponding to each root cause on the target service according to the repair decision instruction and the set of root causes of anomalies to eliminate the abnormal state includes: If the root cause of the exception is a service dependency failure, then according to the root cause of the exception description, a circuit breaker rule is sent to the target service so that the target service blocks the call link with the downstream service according to the circuit breaker rule. If the root cause of the anomaly is a performance bottleneck, then according to the repair decision instruction, the current number of instances of the target service is obtained, a new instance is created based on the current number of instances and the root cause of the anomaly description, and the new instance is allocated to the node where the target service is located. If the root cause of the exception is an instance exception class, then the instance status of the target service is obtained, and based on the instance status and the root cause of the exception, the exception instance and healthy instance of the target service are determined, and the access request corresponding to the exception instance is routed to the healthy instance.

8. A service exception handling device, characterized in that, include: The first acquisition module is used to acquire performance metric data, tracing data, and business log data of the target service from the service cluster; The judgment module is used to determine whether the target service is in an abnormal state based on the comparison result between the performance indicator data and a preset set of thresholds. The construction module is used to construct a service dependency graph based on the link tracing data if the target service has an abnormal state, and to determine the propagation path of the abnormal state based on the service dependency graph. The second acquisition module is used to acquire abnormal business log data, code change records and resource status data corresponding to all nodes covered by the propagation path, and generate prompt word information based on the business log data, the code change records and the resource status data; The generation module is used to generate a set of abnormal root causes and corresponding repair decision instructions for each abnormal root cause in the set of abnormal root causes based on the prompt word information using a preset abnormal root cause analysis model. The execution module is used to perform governance operations corresponding to each of the abnormal root causes on the target service according to the repair decision instructions and the set of abnormal root causes, so as to eliminate the abnormal state.

9. A computer device, characterized in that, The device includes a memory and a processor, wherein the memory stores computer-readable instructions, and the processor executes the computer-readable instructions to implement the steps of the service exception handling method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-readable instructions that, when executed by a processor, implement the steps of the service exception handling method as described in any one of claims 1 to 7.

Images