Cross-system fault diagnosis method and system combining multidimensional anomaly detection

Abstract

This invention provides a cross-system fault diagnosis method and system that combines multi-dimensional anomaly detection. First, it acquires the original data set generated by cross-system calls, including fragmented call data, peripheral business transaction data, and log data. Breakpoint completion processing is then performed to generate a complete data set. Next, horizontal anomaly diagnosis is performed on the complete data set, using a decision tree algorithm to locate the fault propagation path and anomaly objects. Then, vertical anomaly detection is performed on the anomaly objects. Based on a multi-dimensional anomaly detection algorithm, the operating logs, error stacks, and infrastructure indicators are analyzed to generate anomaly cause analysis results. Finally, based on the analysis results, the root cause, fault object, and scope of impact are determined, and a cross-system fault diagnosis report is output. This comprehensive utilization of multi-source data enables precise location and in-depth analysis of cross-system faults, improving fault diagnosis efficiency and accuracy, and ensuring stable system operation.

Description

Technical Field

[0001] This invention relates to the field of digital software system technology, and more specifically, to a cross-system fault diagnosis method and system that combines multi-dimensional anomaly detection. Background Technology

[0002] In modern, complex IT architectures, cross-system calls occur frequently, with different systems collaborating to accomplish various business functions. However, when cross-system calls fail, troubleshooting becomes extremely challenging.

[0003] Currently, existing fault diagnosis methods often have many shortcomings. On the one hand, the collected data is usually fragmented. For example, the call data collected by link probes may be interrupted due to network fluctuations, system load, etc., making it impossible to fully present the entire process of cross-system calls. On the other hand, most existing diagnostic methods only focus on a single data source, such as analyzing only log data or relying solely on business transaction data, lacking comprehensive utilization of multi-source data. Moreover, in fault localization, it is often only possible to determine the general scope of the fault, making it difficult to accurately locate the fault propagation path and abnormal objects, let alone deeply analyze the specific reasons for the fault caused by the abnormal objects. This results in low fault diagnosis efficiency, requiring a lot of manpower and time for troubleshooting, and also makes it difficult to accurately determine the root cause and scope of impact of the fault, posing a serious threat to the stable operation of the system and business continuity. Summary of the Invention

[0004] In view of the aforementioned problems, and in conjunction with the first aspect of the present invention, embodiments of the present invention provide a cross-system fault diagnosis method combining multidimensional anomaly detection, the method comprising:

[0005] Obtain the raw data set generated during the cross-system call process, the raw data set including fragmented call data collected by the link probe, peripheral business transaction data and log data;

[0006] The original data set is subjected to breakpoint supplementation processing. The breakpoint positions in the fragmented call data are identified based on the application type. The external business transaction data, log data and system association information are integrated to generate a complete data set.

[0007] The complete dataset is subjected to lateral anomaly diagnosis and processing, and the fault propagation path and anomaly objects are located by using a decision tree algorithm;

[0008] The abnormal object is subjected to longitudinal anomaly detection processing. Based on the multi-dimensional anomaly detection algorithm, the runtime log, error stack and infrastructure indicators of the abnormal object are analyzed to generate anomaly cause analysis results.

[0009] Based on the results of the anomaly analysis, the root cause, the fault object, and the scope of impact are determined, and a cross-system fault diagnosis report is output.

[0010] In another aspect, embodiments of the present invention also provide a cross-system fault diagnosis system combining multi-dimensional anomaly detection, including a processor and a machine-readable storage medium connected to the processor. The machine-readable storage medium is used to store programs, instructions, or code, and the processor is used to execute the programs, instructions, or code in the machine-readable storage medium to implement the above-described method.

[0011] Based on the above, this embodiment of the invention acquires the original data set containing fragmented call data collected by link probes, peripheral business transaction data, and log data during cross-system calls, performs breakpoint supplementation processing on it, and integrates peripheral business transaction data, log data, and system-related information to generate a complete data set. Then, it performs horizontal anomaly diagnosis processing on the complete data set, using a decision tree algorithm to locate the fault propagation path and anomaly objects. This enables rapid and accurate determination of the propagation direction and key anomaly points of the fault in cross-system calls. Next, it performs vertical anomaly detection processing on the anomaly objects, analyzing the runtime logs, error stacks, and infrastructure indicators of the anomaly objects based on a multi-dimensional anomaly detection algorithm to generate detailed anomaly cause analysis results, deeply exploring the root cause of the fault. Finally, based on the anomaly cause analysis results, it determines the root cause, fault object, and scope of impact, and outputs a cross-system fault diagnosis report. This achieves full-process automation and precision from data integration and fault location to cause analysis, greatly improving the efficiency and accuracy of cross-system fault diagnosis, reducing fault troubleshooting costs, and ensuring the stable operation of the system and the continuity of business. Attached Figure Description

[0012] Figure 1 This is a schematic diagram of the execution flow of the cross-system fault diagnosis method combining multi-dimensional anomaly detection provided in an embodiment of the present invention.

[0013] Figure 2 This is a schematic diagram of exemplary hardware and software components of a cross-system fault diagnosis system that combines multidimensional anomaly detection, provided in an embodiment of the present invention. Detailed Implementation

[0014] The present invention will now be described in detail with reference to the accompanying drawings. Figure 1 This is a flowchart illustrating a cross-system fault diagnosis method combining multidimensional anomaly detection according to an embodiment of the present invention. The following is a detailed description of this cross-system fault diagnosis method combining multidimensional anomaly detection.

[0015] Step S110: Obtain the raw data set generated during the cross-system call process. The raw data set includes fragmented call data collected by the link probe, peripheral business transaction data, and log data.

[0016] In this embodiment, in a cross-system business environment, multiple systems collaborate to complete various business functions. For the fragmented call data collected by the link probe, link probe components can be deployed on the key interfaces and communication paths of each system. These link probe components can monitor inter-system call information in real time, including the call initiation time, the target system, the call parameters, and the call return results. Because the system call process may be affected by factors such as network fluctuations and system load, the collected data is often incomplete and fragmented. For example, in a cross-system business process, due to network latency, the link probe may only record the initiation part of the call, while subsequent processing and return result information are missing.

[0017] To ensure accurate collection of these fragmented call data, the link probe component employs high-speed data capture technology. For example, it samples inter-system communication data at extremely short intervals, performs preliminary parsing and filtering of the raw data packets, and extracts key information related to system calls. This data is then sent to the data collection center via a data transmission channel. During data transmission, encryption techniques are used to prevent data theft or tampering.

[0018] External business transaction data reflects the specific details of business transactions and is typically stored in the business database. To obtain this data, a database interface can be used to connect to the business database. Based on preset query rules, business transaction data related to cross-system calls is periodically extracted from the business database. This transaction data includes basic transaction information, such as the initiator, recipient, transaction time, and transaction amount, as well as detailed transaction content, such as information about the goods or services traded and the transaction status. During data extraction, data filtering and cleaning can be performed to remove invalid or duplicate data, ensuring data accuracy and consistency.

[0019] Log data records detailed information about the operation of various systems, including system operation logs, error messages, and status changes. Log data is typically stored as files in the log file system of each system. To retrieve this log data, log collection tools can be used. These tools periodically scan the log files of each system, collect newly generated log data, and send it to a data collection center. During log data collection, the data can be categorized and labeled for subsequent analysis and processing.

[0020] At the data collection center, fragmented call data, external business transaction data, and log data collected from link probes, business databases, and log file systems can be integrated to form a raw data set. During the integration process, data can be correlated and matched based on timestamps and relevant identifiers to ensure data consistency and integrity. Simultaneously, data can be stored and managed using distributed file systems and database technologies to ensure efficient data storage and retrieval.

[0021] Step S120: Perform breakpoint supplementation processing on the original data set, identify the breakpoint positions in the fragmented call data based on the application type, and integrate the peripheral business transaction data, log data and system association information to generate a complete data set.

[0022] Because fragmented data calls may be incomplete, breakpoint supplementation is required to build a complete dataset. This process involves multiple steps, including application type matching, breakpoint location identification, and data fusion.

[0023] Step S121: Perform application type matching processing on the fragmented call data to identify the call protocol characteristics and data interaction patterns corresponding to different application types.

[0024] Different applications follow established calling protocols and data interaction patterns when making cross-system calls. To accurately identify the application type to which fragmented call data belongs, in-depth data analysis and processing are necessary.

[0025] First, feature extraction can be performed on fragmented call data. Natural language processing and machine learning techniques can be used to parse and process the textual information in the fragmented call data, extracting key feature information. For example, for request and response messages in fragmented call data, features such as message headers, body content, request methods, and response status codes can be extracted. For binary information in fragmented call data, data mining and pattern recognition techniques can be used to extract structural features and distribution characteristics of the fragmented call data.

[0026] Then, an application type feature library can be established, containing the calling protocol characteristics and data interaction patterns of various application types. These calling protocol characteristics and data interaction patterns are obtained through analysis and summarization of a large amount of calling data from known application types. When establishing the application type feature library, classification algorithms can be used to categorize and organize the characteristics of different application types, forming a hierarchical feature structure.

[0027] Next, the extracted feature information of the fragmented call data is matched with features in the application type feature library. A similarity calculation algorithm is used to calculate the similarity score between the data features and each feature in the application type feature library. For example, the cosine similarity algorithm is used to calculate the similarity of text features, and the Euclidean distance algorithm is used to calculate the similarity of numerical features. Based on the similarity scores, the application type with the highest score is selected as the application type for this fragmented call data.

[0028] A multi-stage matching strategy can be employed during the matching process. First, a coarse matching is performed to quickly filter out the range of potentially matching application types. Then, a fine-grained matching is conducted within this range to further improve accuracy. Simultaneously, a machine learning model can be used to validate and optimize the matching results. The matching results are used as input to train the machine learning model, allowing it to learn the feature distributions and matching patterns of different application types, thereby improving the accuracy and stability of the matching process.

[0029] Step S122: Based on the calling protocol characteristics and data interaction mode, mark the missing data nodes in the fragmented calling data as breakpoint locations.

[0030] Once the application type to which the fragmented call data belongs is determined, the breakpoint locations in the data can be identified based on the call protocol characteristics and data interaction patterns of that application type.

[0031] Each application type has its own defined rules and processes for its invocation protocol and data interaction pattern. For example, in an HTTP-based application call, a complete call typically includes three stages: request initiation, server processing, and response return. Each stage has its own defined data format and interaction rules. By conducting detailed analysis of fragmented call data, we can check whether the fragmented call data conforms to the invocation protocol and data interaction pattern of that application type.

[0032] If data is missing at a certain stage in the fragmented data call, or if the format and interaction rules of the fragmented data call do not conform to the normal flow, this location can be marked as a breakpoint. When marking breakpoints, a data tagging algorithm can be used to record relevant information about the breakpoint, such as the breakpoint's timestamp, the data segment it belongs to, and the breakpoint type. Simultaneously, the breakpoint location can be visualized for subsequent analysis and processing.

[0033] To improve the accuracy of breakpoint location identification, a multi-dimensional analysis approach can be employed. In addition to analyzing data format and interaction rules, this involves combining contextual information and time-series data for comprehensive analysis. For example, analyzing the correlation between different data points helps determine whether missing data would affect the integrity of the entire call flow. Simultaneously, machine learning algorithms can be used to predict and verify breakpoint locations. Breakpoint location information from historical data is used as training data to train the machine learning model, allowing it to learn the distribution patterns and characteristics of breakpoint locations, thereby improving the accuracy and reliability of breakpoint location identification.

[0034] Step S123: Extract transaction identifier information and interaction parameter set that are aligned with the timestamp of the breakpoint from the peripheral business transaction data.

[0035] After marking the breakpoint location, it is necessary to extract information related to the breakpoint location from the external business transaction data to supplement the missing data.

[0036] First, based on the timestamp of the breakpoint, search for matching transaction records in the external business transaction data. A time series matching algorithm is used to compare the timestamp of the breakpoint with the transaction timestamps in the external business transaction data to find transaction records with similar timestamps.

[0037] Then, transaction identification information and interaction parameter sets are extracted from these transaction records. Transaction identification information uniquely identifies a transaction, such as transaction number, order number, etc. The interaction parameter set contains various parameter information during the transaction process, such as transaction amount, quantity, and product or service information.

[0038] When extracting information, data extraction algorithms can be used to extract the required information from transaction records according to preset rules. Simultaneously, the extracted information can be cleaned and transformed to ensure that its format and quality meet the requirements of subsequent processing. For example, transaction amounts in different formats can be uniformly converted to the same currency unit, and information on goods or services with different codes can be decoded and standardized.

[0039] Step S124: Extract request initiation records, response reception records, and intermediate processing log entries associated with the breakpoint location from the log data.

[0040] Log data records detailed information about the system during operation, from which key information related to breakpoint locations can be extracted.

[0041] First, the log data is preprocessed, including parsing, cleaning, and classifying it. The log data is categorized according to different log types, such as system operation logs, error logs, and access logs. Then, based on the information related to the breakpoint location, the associated request initiation records, response reception records, and intermediate processing log entries are located within the log data.

[0042] A log retrieval algorithm is employed to search for log entries based on information such as timestamps, keywords, and sources. For example, by searching for keywords related to the breakpoint location, such as system names and interface names, potentially relevant log entries are filtered out. Then, the filtered log entries are analyzed in detail to extract request initiation records, response reception records, and intermediate processing log entries.

[0043] During the extraction process, natural language processing (NLP) techniques can be used to parse and understand log entries. This converts the textual information of log entries into structured data, extracting key information such as request parameters, response status codes, intermediate processing steps, and results. Simultaneously, the extracted information can be verified and supplemented to ensure its accuracy and completeness.

[0044] Step S125: Use the transaction identifier information, interaction parameter set, request initiation record, response reception record, and intermediate processing log entries as breakpoint supplementary data.

[0045] Relevant information extracted from external business transaction data and log data will be integrated to form breakpoint supplementary data.

[0046] During the integration process, data can be associated and matched based on relevance and consistency. For example, transaction identifier information can be associated with transaction identifiers in request initiation records and response reception records to ensure correct data correspondence. Simultaneously, data can be cleaned and transformed to remove duplicate and invalid data, and to standardize data format and standards.

[0047] Then, the integrated data is used as breakpoint supplementary data to fill in the missing parts of the fragmented call data. When supplementing the data, the breakpoint supplementary data can be accurately inserted into the corresponding positions in the fragmented call data based on the breakpoint location information.

[0048] Step S126: Call the pre-stored system association information, which includes service dependencies for cross-system calls, interface call rules, and infrastructure deployment location information.

[0049] In this embodiment, the system association information reflects the interrelationships and calling rules between various systems. The pre-stored system association information is collected and organized during system deployment and configuration. This system association information includes service dependencies across systems, i.e., which other systems' services a service depends on; interface calling rules, i.e., the methods, parameters, and return values ​​for interface calls between systems; and infrastructure deployment location information, i.e., the physical location and network topology of each system.

[0050] When system-related information needs to be accessed, it can be queried and retrieved through the system-related information management module. This module stores and manages system-related information, ensuring its accuracy and timeliness. Simultaneously, it allows for the updating and maintenance of system-related information, promptly updating it whenever system service dependencies, interface call rules, or infrastructure deployment locations change.

[0051] Step S127: The breakpoint supplement data is fused with the system association information to fill in the missing data nodes in the fragmented call data and generate a complete data set.

[0052] The breakpoint supplementary data is integrated with the system association information to fill in the missing data nodes in the fragmented call data.

[0053] First, based on the service dependencies and API call rules in the system's association information, the breakpoint supplementary data is analyzed and processed. It is determined whether the breakpoint supplementary data conforms to the system's call rules and service dependencies. If not, the breakpoint supplementary data can be adjusted and corrected to ensure its rationality and consistency.

[0054] Then, the processed breakpoint supplementary data is merged with the fragmented call data. Based on the breakpoint location information, the breakpoint supplementary data is accurately inserted into the corresponding positions in the fragmented call data, filling in the missing data nodes. During the merging process, data fusion algorithms can be used to integrate and optimize the data, ensuring its integrity and accuracy.

[0055] Finally, the merged data is linked and integrated with system-related information to generate a complete dataset. This complete dataset contains comprehensive information about cross-system calls, including the call process, details of business transactions, system operation logs, and inter-system relationships.

[0056] Step S130: Perform horizontal anomaly diagnosis on the complete dataset and locate the fault propagation path and anomaly objects using a decision tree algorithm.

[0057] After obtaining the complete dataset, lateral anomaly diagnosis is required to locate the propagation path of the fault and the abnormal object. Decision tree algorithm is a commonly used machine learning algorithm that can classify and make decisions based on the characteristics and rules of the data, making it very suitable for fault diagnosis and anomaly localization.

[0058] Step S131: Extract the call path feature set from the complete data set. The call path feature set includes the number of calling nodes, the calling order between nodes, the processing time of a single node, and the node response status identifier.

[0059] The call path feature set reflects the basic characteristics and status of cross-system calls. First, the call records in the complete dataset are parsed to extract relevant information for each call path. By analyzing the initiator and receiver information in the call records, the number of nodes in the call path and the call order between nodes are determined. For example, if a call path originates from system A, calls system B and system C in sequence, and finally returns the result to system A, then the number of nodes in this call path is 3, and the call order between nodes is A->B->C->A.

[0060] Then, based on the timestamp information in the call log, the processing time for each node is calculated. The time difference between the timestamp of the call initiation and the timestamp of the node's response is the processing time for that node. Simultaneously, based on the node's response information, the node's response status is determined, such as successful response, failed response, or timeout response.

[0061] The extracted features, such as the number of calling nodes, the order of calls between nodes, the processing time of a single node, and the node response status identifier, are organized and combined to form a call path feature set. When forming the feature set, the features can be standardized, converting different types of features into a unified format and scope for subsequent analysis and processing.

[0062] Step S132: Input the call path feature set into the feature filtering module of the decision tree algorithm, and select key features as splitting attributes according to the information gain ratio. The key features include the single node processing time abnormal identifier and the node response status abnormal identifier.

[0063] The feature selection module of the decision tree algorithm is used to select key features as splitting attributes from the feature set of the calling path to construct the decision tree model. Information gain ratio is a commonly used feature selection metric that measures the importance of a feature for classification.

[0064] After the feature set of the calling path is input into the feature filtering module, the module evaluates each feature and calculates its information gain ratio. The information gain ratio is calculated based on the entropy and conditional entropy of the data. Entropy represents the uncertainty of the data, and conditional entropy represents the uncertainty of the data given a certain feature. The information gain ratio is the ratio of information gain to the intrinsic value of the feature, which can effectively avoid selecting features with too many possible values.

[0065] For single-node processing time characteristics, a normal processing time range can be set based on historical data and business experience. If the processing time of a node exceeds this range, the single-node processing time exception flag for that node is set to exception. For node response status flags, if the node's response status is failure or timeout, the node response status exception flag for that node is set to exception.

[0066] Based on the calculated information gain ratio, features with an information gain ratio greater than a set threshold are selected as key features. In this embodiment, the single-node processing time anomaly identifier and the node response status anomaly identifier typically have high information gain ratios, and therefore are selected as key features as splitting attributes.

[0067] Step S133: Construct a decision tree classification model based on the splitting attributes. The internal nodes of the decision tree classification model represent feature splitting conditions, and the leaf nodes represent fault propagation path types.

[0068] Once the splitting attributes are determined, a decision tree classification model can be constructed based on these attributes. A decision tree classification model is a tree-like structure consisting of internal nodes and leaf nodes.

[0069] Internal nodes represent feature splitting conditions, dividing the data based on the values ​​of the splitting attributes. For example, if the single node processing time anomaly identifier is selected as the splitting attribute, the internal nodes will divide the data into different subsets based on the value of this feature (normal or abnormal). Each subset will then continue to be divided based on other splitting attributes until the set stopping condition is met.

[0070] Leaf nodes represent the types of fault propagation paths. During the construction of the decision tree, when a data subset meets the stopping conditions, such as when the number of samples in the data subset is less than a certain threshold, or when the purity of the data subset reaches a set standard, the data subset is marked as a leaf node, and its corresponding fault propagation path type is determined based on the sample characteristics in the data subset.

[0071] The decision tree classification model is constructed recursively. Starting from the root node, the data is divided according to the splitting attribute, generating child nodes. This process is then repeated for each child node until all nodes have been processed. During the construction process, pruning algorithms can be used to optimize the decision tree, removing unnecessary nodes and branches to improve its generalization ability and accuracy.

[0072] Step S134: Traverse the call paths in the complete dataset using the decision tree classification model to identify abnormal nodes that meet the splitting conditions as candidate abnormal objects.

[0073] After constructing the decision tree classification model, input the call path from the complete dataset into the decision tree classification model for traversal.

[0074] Starting from the root node of the decision tree, the system compares the feature values ​​of the call path with the splitting conditions of the internal nodes and selects the appropriate branch to continue traversing. When a leaf node is reached, the system determines whether the call path is abnormal based on the fault propagation path type of the leaf node.

[0075] During the traversal, if the feature value of a node satisfies the splitting condition of its internal nodes, and this splitting condition is related to an abnormal situation, then the node is identified as a candidate exception object. For example, if the splitting condition of an internal node is that a single node processing time exception is marked as an exception, and when traversing to a call path, a node in that call path has a single node processing time exception marked as an exception, then that node is identified as a candidate exception object.

[0076] The identified candidate anomalies are recorded and organized to form a candidate anomaly object set. When recording candidate anomalies, information such as their node identifier, the call path they belong to, and related feature values ​​can be recorded for subsequent analysis and processing.

[0077] Step S135: Perform path backtracking processing on the candidate abnormal objects, analyze the position of the abnormal node in the call path and its dependency relationship with other nodes, determine the scope of subsequent node abnormal propagation triggered by the abnormal node, and generate a fault propagation path that includes the abnormal starting node, propagation direction and the set of affected nodes.

[0078] After obtaining the set of candidate exception objects, it is necessary to perform path backtracking on these candidate exception objects to determine the propagation path of the fault.

[0079] The path backtracking process starts with the candidate exception object and traces backward along the call path to analyze the position of the exception node in the call path and its dependencies on other nodes. In the complete dataset, the call relationships of each system node are explicitly recorded. Through these records, it is clear which preceding nodes triggered the exception node and which subsequent nodes it would call.

[0080] First, identify the preceding node of the abnormal node. Based on the call path records, find the preceding node that directly called the abnormal node. Analyze the running status and related characteristics of the preceding node to see if it also has an anomaly. If the preceding node is normal, it can be preliminarily determined that the anomaly originated from the abnormal node itself; if the preceding node also has an anomaly, it is necessary to further trace the preceding node of the preceding node, and so on, until the starting node of the anomaly is found.

[0081] Next, the dependencies between the abnormal node and its subsequent nodes are analyzed. After an abnormal node encounters an exception, it may propagate the exception to subsequent nodes that have a calling relationship with it. By examining the call path records, the set of subsequent nodes called by the abnormal node is determined. For each subsequent node, its running status and related characteristics after the abnormal node encountered an exception are examined. If the response status of a subsequent node changes to abnormal, or if the processing time of a single node changes significantly, then it can be considered that the subsequent node has been affected by the exception propagation.

[0082] When identifying affected subsequent nodes, it's necessary to consider the call order and timing relationships between nodes. If a subsequent node also experiences an anomaly shortly after the abnormal node, and there's a direct call relationship between them, then the subsequent node is likely affected by the anomaly propagation. However, if the time interval between the subsequent node's anomaly and the abnormal node's anomaly is long, or if there's no direct call relationship between them, then further analysis is needed to determine if other factors caused the subsequent node's anomaly.

[0083] To more accurately determine the scope of anomaly propagation, service dependencies in system association information can be considered. Some system nodes may have indirect service dependencies; even if they don't have direct call records in the call path, anomalies may still propagate through these indirect dependencies. Analyzing service dependencies can help identify potentially affected nodes.

[0084] After identifying the anomaly's originating node, propagation direction, and the set of affected nodes, this information is integrated to generate a fault propagation path. The fault propagation path details how the anomaly starts from the originating node, propagates through which nodes, and ultimately affects which nodes. This allows for rapid location of the fault source and the implementation of appropriate measures to block the propagation of the anomaly and restore the system to normal operation.

[0085] Step S136: Extract nodes with an incorrect response status and nodes whose processing time exceeds the baseline threshold from the fault propagation path as the finally located abnormal objects.

[0086] After obtaining the fault propagation path, it is necessary to extract the final anomaly object from it. A response status of "error" and a processing time exceeding a baseline threshold are two important indicators for determining node anomalies.

[0087] For each node in the fault propagation path, check its response status identifier. If the response status identifier shows an error, it indicates that the node encountered a problem during operation and could not complete the task normally. This error may be caused by internal system code errors, insufficient resources, network failures, etc. Extract these nodes with error response statuses as potential exception objects.

[0088] Simultaneously, a baseline processing time threshold is set for each node. This threshold is determined based on historical system data and business requirements, representing the reasonable time required for the node to complete its task under normal circumstances. For nodes in the fault propagation path, their actual processing time is compared with the baseline threshold. If a node's actual processing time exceeds the baseline threshold, it indicates a significant slowdown in its processing speed, potentially indicating performance issues or being affected by other abnormal factors. These nodes with processing times exceeding the baseline threshold are also extracted as potential anomalies.

[0089] Nodes with error responses and those whose processing time exceeds a baseline threshold are merged to obtain the final set of identified anomalies. These anomalies are nodes that exhibit significant abnormalities during fault propagation and require focused analysis and handling to resolve system faults.

[0090] Step S140: Perform vertical anomaly detection processing on the abnormal object, analyze the running log, error stack and infrastructure indicators of the abnormal object based on the multi-dimensional anomaly detection algorithm, and generate anomaly cause analysis results.

[0091] After locating the abnormal objects, they need to undergo vertical anomaly detection processing to deeply analyze the causes of the anomalies. Multidimensional anomaly detection algorithms combine information from various aspects such as the abnormal object's runtime logs, error stacks, and infrastructure metrics, enabling a more comprehensive and accurate analysis of the causes of the anomalies.

[0092] Step S141: Extract the runtime log data of the abnormal object from the complete dataset. The runtime log data includes timestamps, operation types, input parameters, and output results.

[0093] The complete dataset records detailed operational information for each system node, from which the operational log data of the anomaly objects can be extracted. Operational log data is a detailed record of the system's operation process and is of significant value for analyzing the causes of anomalies.

[0094] Based on the identifier information of the abnormal object, the operation log records related to the abnormal object are filtered out from the complete dataset. Each operation log record contains key information such as timestamp, operation type, input parameters, and output results. The timestamp records the specific time when the operation occurred; by analyzing the timestamp, the time sequence and time interval of the abnormal occurrence can be understood. The operation type describes the specific operation performed by the system, such as data query, data update, business calculation, etc. The input parameters are the parameter information used during operation execution, and the output result is the return result after the operation is executed.

[0095] When extracting runtime log data, the data needs to be cleaned and organized. Useless information, such as redundant characters and comments, needs to be removed to ensure the extracted data is accurate and clear. Simultaneously, the data format needs to be converted, unifying timestamps from different formats to a standard format, and organizing input parameters and output results according to established specifications for subsequent analysis and processing.

[0096] Step S142: Perform lexical analysis on the operation log data to extract key operation verbs, data object nouns, and state description adjectives as log feature units.

[0097] To extract useful information from runtime log data, lexical analysis is required. Lexical analysis breaks down text data into meaningful lexical units and identifies key information within them.

[0098] Step S1421: Perform text cleaning on the operation log data to remove non-semantic information and retain the operation description text content.

[0099] Operation log data may contain non-semantic information, such as system-generated timestamp format information and log record numbers. This information does not directly help in analyzing the cause of anomalies and needs to be removed. Regular expression matching and string processing techniques are used to identify and delete this non-semantic information, retaining only the text content related to the operation description. For example, the prefix "[2024-01-01 12:00:00] INFO:" in the log record is removed, leaving only the subsequent operation description text.

[0100] Step S1422: Input the operation description text into a word segmentation tool for segmentation processing to generate a word segmentation result containing multiple word units.

[0101] Use a professional word segmentation tool to segment the text describing the operation. The tool divides the text into individual word units based on the language's grammatical rules and vocabulary. Different languages ​​and business scenarios may require different word segmentation tools to ensure accuracy and effectiveness. For example, Jieba can be used for Chinese text, while NLTK or similar tools can be used for English text. The segmentation result is a list containing multiple word units, each representing a meaningful word in the text.

[0102] Step S1423: Match the operation verbs in the word segmentation results according to the preset verb lexicon, wherein the operation verbs include words that represent system operation behaviors.

[0103] A pre-defined verb lexicon is established, containing common operational verbs in the system, such as "query," "update," "delete," and "calculate." The word segmentation results are matched against the verb lexicon to identify operational verbs. Each word unit in the segmentation results is iterated over, checking if it exists in the verb lexicon. If it does, it is marked as an operational verb, thus accurately identifying the system operations described in the operation logs.

[0104] Step S1424: Match the data object nouns in the word segmentation results according to the preset noun lexicon, wherein the data object nouns contain words representing the operation object.

[0105] Similarly, a pre-defined noun lexicon is used, containing common data object nouns in the system, such as "user information," "order data," and "inventory records." The word segmentation results are matched against the noun lexicon to identify the data object nouns. Each word unit in the segmentation results is iterated over, checking if it exists in the noun lexicon. If it does, it is marked as a data object noun, thus clearly identifying the data object targeted by the system operation.

[0106] Step S1425: Match the state description adjectives in the word segmentation results according to the preset adjective lexicon, wherein the state description adjectives include words that indicate the state of the operation result.

[0107] A pre-defined adjective lexicon is established, containing adjectives describing the state of an operation, such as "success," "failure," "normal," and "abnormal." The word segmentation results are matched against the adjective lexicon to identify the state-describing adjectives. Each word unit in the segmentation results is iterated over, and its existence is checked against the adjective lexicon. If it is found, it is marked as a state-describing adjective, thus revealing the state of the system operation.

[0108] Step S1426: Perform frequency statistics processing on the matched operation verbs, data object nouns and state description adjectives, and filter words with a frequency exceeding a preset threshold as key log feature units.

[0109] Frequency statistics are performed on the matched operation verbs, data object nouns, and status description adjectives. The number of times each word appears in the entire operation log data is counted. Then, a preset threshold is set, and words with a frequency exceeding this threshold are selected as key log feature units. These key log feature units represent important information that frequently appears in the operation logs and are of significant reference value for analyzing the causes of anomalies. For example, if a certain operation verb appears frequently, it indicates that the operation may be a critical operation in the system; if a certain data object noun appears frequently, it indicates that the data object may be a key focus area for anomaly detection.

[0110] Step S1427: Arrange and combine the key log feature units in the order of operation verb - data object noun - state description adjective to generate a set of feature units representing the core semantics of the log.

[0111] The selected key log feature units are arranged and combined in the order of operation verb - data object noun - status description adjective. This arrangement clearly expresses the core semantics of the runtime log. For example, a combination like "query - user information - failure" intuitively indicates that the system failed when querying user information. All the above arrangements are collected to generate a set of feature units representing the core semantics of the log. This set of feature units more accurately reflects the system operations and result states recorded in the runtime log.

[0112] Step S143: Perform syntactic analysis on the error stack data of the exception object to identify the stack call level, exception class name and exception trigger code line number, and generate stack structure features.

[0113] Error stack data records the system's call stack information when the exception occurred. By performing syntactic analysis on it, we can gain a deeper understanding of the specific location and cause of the exception.

[0114] First, the error stack data is parsed. Error stack data is usually recorded according to a defined format; for example, Java error stacks display the class name, method name, and line number for each call level in a predefined format. Through regular expression matching and string manipulation techniques, the error stack data is parsed into individual call level records.

[0115] Next, the call stack hierarchy is identified. Each call stack record represents a method call made by the system at the time the exception occurred. By sorting the parsed call stack records, the order of the call stacks can be determined. Starting from the lowest call stack and analyzing upwards step by step, we can understand how the system calls one method to another, ultimately leading to the exception.

[0116] Next, extract the exception class name. Each call level record typically contains the exception class name. Using string extraction techniques, the exception class name is extracted from the call level record. The exception class name reflects the type of exception, such as NullPointerException, SQLException, etc., with different exception class names representing different exception causes.

[0117] Finally, determine the line number that triggered the exception. The call hierarchy record clearly indicates which line of code triggered the exception. By parsing the call hierarchy record, the line number that triggered the exception can be extracted. This line number accurately pinpoints the exact location where the exception occurred, allowing developers to examine the corresponding code and find the cause of the exception.

[0118] The identified call stack hierarchy, exception class name, and exception-triggered line number are combined to generate a stack structure feature. This stack structure feature can comprehensively describe the system's call stack at the time the exception occurs.

[0119] Step S144: Input the log feature unit and the stack structure feature into the semantic understanding model, analyze the semantic relationship between the log content and the stack information, and extract the set of semantic features representing the abnormal triggering conditions.

[0120] A semantic understanding model is a trained artificial intelligence model that can understand the semantic information of text data and analyze the relationships between different texts.

[0121] The log feature set and stack structure features are taken as input and fed into the semantic understanding model. The semantic understanding model processes this input data and analyzes the semantic relationship between the log content and the stack information. For example, the model will determine whether the operation failure recorded in the log is related to the exception class and exception triggering code line number displayed in the stack information.

[0122] By analyzing semantic relationships, the model extracts a set of semantic features that represent the conditions that trigger an anomaly. These sets of semantic features contain key information that describes the cause of the anomaly. For example, if the log records "Query - Data Object - Failure," and the stack trace shows that it was caused by a database connection anomaly, then the semantic understanding model will extract the semantic feature "Database connection anomaly caused the data object query to fail."

[0123] Step S145: Obtain infrastructure indicator data of the device where the abnormal object is located from the infrastructure monitoring system. The infrastructure indicator data includes computing resource usage data, network transmission data, and storage access data.

[0124] The infrastructure monitoring system monitors the operational status and performance metrics of each device in real time. It retrieves infrastructure metric data from the device containing the anomaly, reflecting the device's hardware resource usage and network communication status.

[0125] Computational resource usage data includes CPU utilization and memory utilization. CPU utilization reflects the activity level of the device's central processing unit at a given moment. High CPU utilization can lead to slow system performance or even malfunctions. Memory utilization reflects the device's memory resource usage; insufficient memory can prevent programs from functioning correctly.

[0126] Network transmission data includes network bandwidth utilization and network latency. Network bandwidth utilization reflects the activity level of a device in terms of network transmission. If network bandwidth utilization is too high, it may lead to data transmission delays, affecting the normal operation of the system. Network latency reflects the time required for data to be transmitted over the network. If network latency is too high, it may cause slow system response.

[0127] Storage access data includes disk I / O utilization and storage capacity utilization. Disk I / O utilization reflects the activity level of the device's disk read / write operations; excessively high disk I / O utilization may slow down data read / write speeds. Storage capacity utilization reflects the usage of the device's storage resources; insufficient storage capacity may prevent data from being stored correctly.

[0128] By interacting with the infrastructure monitoring system through an interface, we can obtain infrastructure metric data for the devices containing the anomalies. When acquiring data, it's necessary to filter the time range to ensure that the obtained data covers a period before and after the anomaly occurred, allowing for a more accurate analysis of the relationship between the anomaly and the infrastructure metrics.

[0129] Step S146: Perform multidimensional anomaly detection processing on the infrastructure indicator data, and identify the time points and magnitudes of abrupt changes in the indicator data by statistically analyzing the mean, variance, and rate of change of the indicator data through a sliding window.

[0130] To more accurately analyze anomalies in infrastructure indicator data, multidimensional anomaly detection processing is required.

[0131] Step S1461: Arrange the infrastructure indicator data in timestamp order to generate an indicator data sequence with time series relationship.

[0132] Infrastructure indicator data is recorded in chronological order, but due to data collection and transmission issues, the data order may be disordered during acquisition. Therefore, it is necessary to sort the acquired infrastructure indicator data according to timestamps. By comparing and sorting the timestamps, the data is rearranged into a time-series sequence of indicator data. This sequence clearly shows how infrastructure indicators change over time.

[0133] Step S1462: Set a fixed-length sliding window to slide through the index data sequence, the length of which matches the average processing time of cross-system calls.

[0134] A fixed-length sliding window is set up, the length of which matches the average processing time of cross-system calls. The purpose of this setting is to enable statistical analysis of infrastructure indicator data within a reasonable time frame and to more accurately capture changes in the indicator data.

[0135] Place the sliding window at the beginning of the indicator data sequence and then begin sliding it through. Each time the window slides for one time unit, the indicator data within it is updated accordingly. Statistical analysis is performed on the indicator data within the window during the sliding process.

[0136] Step S1463: Calculate the mean parameter for the indicator data in each sliding window, where the mean parameter represents the average level of the indicator data within the window.

[0137] For each sliding window containing indicator data, its mean parameter is calculated. The mean parameter reflects the average level of the indicator data within the window. It is obtained by summing all the indicator data within the window and then dividing by the number of data points. For example, for a sliding window containing 10 data points, the values ​​of these 10 data points are summed and then divided by 10 to obtain the mean parameter of the indicator data within that window. This mean parameter can serve as a representative value of the indicator data for that time period for subsequent comparison and analysis.

[0138] Step S1464: Calculate the average of the squared differences between the index data and the mean parameter within each sliding window as the variance parameter, whereby the variance parameter represents the degree of dispersion of the index data within the window.

[0139] After calculating the mean parameter of the indicator data within each sliding window, the squared difference between each data point and the mean parameter is calculated. These squared differences are then summed and divided by the number of data points to obtain the variance parameter. The variance parameter reflects the dispersion of the indicator data within the window. A large variance parameter indicates significant fluctuations in the indicator data within the window, potentially indicating anomalies; a small variance parameter indicates relatively stable indicator data.

[0140] Step S1465: Calculate the ratio of the difference between the mean parameters of adjacent sliding windows to the mean parameters of the previous window as the rate of change parameter, wherein the rate of change parameter represents the fluctuation range of the index data.

[0141] Compare the mean parameters of two adjacent sliding windows and calculate their difference. Then divide this difference by the mean parameter of the previous window to obtain the rate of change parameter. The rate of change parameter reflects the fluctuation range of the indicator data within adjacent time periods. If the rate of change parameter is large, it indicates that the indicator data has changed significantly within adjacent time periods, possibly due to abnormal events; if the rate of change parameter is small, it indicates that the indicator data has changed relatively smoothly.

[0142] Step S1466: Set a mutation detection threshold, which includes a variance parameter threshold and a rate of change parameter threshold.

[0143] To determine whether abrupt changes have occurred in the indicator data, it is necessary to set a mutation detection threshold. This threshold includes a variance parameter threshold and a rate of change parameter threshold. The variance parameter threshold determines whether the dispersion of the indicator data within a window exceeds the normal range, while the rate of change parameter threshold determines whether the fluctuation range of the indicator data within adjacent time periods exceeds the normal range. The setting of these thresholds needs to be determined in conjunction with the system's historical data and business characteristics. This can be achieved by analyzing a large amount of historical infrastructure indicator data to statistically determine the distribution range of the variance and rate of change parameters under normal conditions, and then determining appropriate thresholds based on this distribution range. For example, a certain percentile of the variance parameter in the historical data can be used as the variance parameter threshold, and a certain percentile of the rate of change parameter can be used as the rate of change parameter threshold.

[0144] Step S1467: Traverse the variance parameter and rate of change parameter of all sliding windows, and identify the window positions where the variance parameter exceeds the variance parameter threshold or the rate of change parameter exceeds the rate of change parameter threshold as the abrupt change time points.

[0145] After calculating the variance and rate of change parameters for each sliding window and setting the mutation detection threshold, all sliding windows are iterated through. For each sliding window, it is checked whether its variance parameter exceeds the variance parameter threshold or its rate of change parameter exceeds the rate of change parameter threshold. If either condition is met, the position of that sliding window is marked as a mutation time point. This mutation time point represents the moment when infrastructure indicator data undergoes a significant change, which may be related to the occurrence of anomalies.

[0146] Step S1468: Calculate the absolute value of the difference between the indicator data corresponding to the mutation time point and the indicator data under normal conditions as the mutation amplitude. The indicator data under normal conditions is the mean parameter of the sliding window when no mutation occurs.

[0147] After identifying the time points of abrupt changes, it is necessary to calculate the magnitude of the changes. The indicator data under normal conditions can be represented by the mean parameter of a sliding window without changes. For each time point of abrupt change, find the corresponding indicator data value, and then calculate the absolute value of the difference between this value and the indicator data under normal conditions (the mean parameter of the sliding window without changes). This absolute value of the difference is the magnitude of the changes. The magnitude of the changes reflects the degree to which the indicator data changes at the time point of the change. The larger the magnitude of the changes, the more drastic the change in the indicator data, and the greater the potential impact on the normal operation of the system.

[0148] Step S147: Analyze the temporal correlation between the abnormal triggering conditions in the semantic feature set and the mutation time point of the indicator data, determine the correlation between the abnormal cause and the change of infrastructure indicators, and generate an abnormal cause analysis result that includes a description of the abnormal triggering conditions, the type of associated infrastructure indicator and the strength of the correlation.

[0149] After obtaining the anomaly triggering conditions and the mutation time points of the indicator data in the semantic feature set, it is necessary to analyze the temporal correlation between them. By comparing the occurrence time of the anomaly triggering conditions and the mutation time points of the indicator data, it is possible to see if there is a temporal sequence or synchronicity between the two.

[0150] If the time of occurrence of the abnormal trigger condition is very close to the time of a sudden change in the indicator data, it can be preliminarily determined that there is a strong correlation between the cause of the anomaly and the change in the infrastructure indicator. For example, if the semantic feature set shows the abnormal trigger condition of "database query failure", and at a similar time point, the disk I / O utilization rate in the infrastructure indicator data changes abruptly, it can be inferred that the database query failure may be related to disk I / O performance issues.

[0151] To more accurately determine the strength of the correlation, statistical analysis methods can be used. For example, the correlation coefficient between the number of times the anomaly triggering conditions occurred and the number of times the indicator data abruptly changed can be calculated. A high correlation coefficient indicates a strong correlation between the cause of the anomaly and the change in the infrastructure indicator; a low correlation coefficient indicates a weak correlation.

[0152] By integrating information such as the description of the anomaly triggering conditions, the types of associated infrastructure indicators, and the strength of the correlation, an anomaly cause analysis result is generated. This result clearly demonstrates the cause of the anomaly and its relationship with changes in infrastructure indicators.

[0153] Step S150: Determine the root cause, fault object, and scope of impact based on the results of the anomaly cause analysis, and output a cross-system fault diagnosis report.

[0154] After obtaining the results of the anomaly analysis, it is necessary to further determine the root cause of the fault, the fault object, and the scope of the fault's impact, and then compile this information into a cross-system fault diagnosis report.

[0155] Step S151: Extract the description of the abnormal triggering conditions and the types of related infrastructure indicators from the abnormal cause analysis results, and determine the direct cause of the abnormality and the underlying infrastructure factors as the root cause of the failure.

[0156] The anomaly cause analysis results include information such as descriptions of the anomaly triggering conditions and types of related infrastructure indicators. In-depth analysis of this information can identify the direct causes and underlying infrastructure factors leading to the anomaly.

[0157] The direct cause can usually be obtained directly from the description of the exception triggering condition. For example, if the exception triggering condition is described as "network connection timeout caused service call failure", then network connection timeout is the direct cause of the exception.

[0158] Underlying infrastructure factors can be identified from the associated infrastructure metric types. If the associated infrastructure metric type shows excessively high network bandwidth usage, then insufficient network bandwidth is likely the underlying infrastructure factor causing network connection timeouts. Combining the direct cause with the underlying infrastructure factors allows us to determine the root cause of the fault. The root cause is the fundamental reason for the anomaly; only by accurately identifying the root cause can effective measures be taken to resolve the fault.

[0159] Step S152: Combine the abnormal starting node and the set of affected nodes in the fault propagation path to determine the initial fault object corresponding to the fault root cause and the subsequent affected secondary fault objects.

[0160] The fault propagation path records the fault initiation node and the set of affected nodes. The fault initiation node is where the fault begins, and its corresponding system node is the initial fault object. By combining the fault root cause, we can determine the reason why the initial fault object caused the fault.

[0161] The nodes in the affected node set are those affected during the fault propagation process; these nodes are the secondary fault objects. By analyzing the call relationships and dependencies between nodes in the fault propagation path, it can be determined how the initial fault object propagated the fault to the secondary fault objects. For example, if the initial fault object is a database server that fails to query data due to disk I / O performance issues, and this database server provides data services to multiple application servers, then these application servers may become secondary fault objects because they depend on the data provided by the database server.

[0162] Step S153: Analyze the service dependency relationship between the initial fault object and the secondary fault object, and determine the specific links in the fault propagation through the call path and the degree of impact of each link.

[0163] Step S1531: Extract the call path information between the initial fault object and the secondary fault object from the complete data set. The call path information includes the call interface identifier, data transmission content, and call sequence relationship.

[0164] The complete dataset records the call path information between various system nodes. Using the identification information of the initial fault object and secondary fault objects, the call path information between them is extracted from the complete dataset. The call interface identifiers in the call path information clearly identify which interfaces the initial fault object and secondary fault objects communicate through; the data transmission content reveals what data was transmitted during the call; and the call sequence relationship reveals the order and time interval of the calls.

[0165] Step S1532: Perform a segmentation process on the call path information, dividing the call path into an interface call segment, a data transmission segment, and a result feedback segment.

[0166] The extracted call path information is broken down into stages according to function and process. The interface call stage is the process of the initial fault object initiating a call to the secondary fault object, including sending and receiving the call request; the data transmission stage is the process of data being transferred from the initial fault object to the secondary fault object during the call, including data packaging, transmission, and parsing; the result feedback stage is the process of the secondary fault object returning the call result to the initial fault object, including result generation and return.

[0167] Step S1533: In the interface call phase, analyze whether the request parameters when the initial faulty object initiates a call to the secondary faulty object are abnormal, and determine the first degree of impact of the interface call phase.

[0168] During the API call phase, the request parameters when the initial faulty object initiates a call to the secondary faulty object are examined. If the request parameters do not conform to the API specifications or expectations, it may lead to call failure or exceptions. For example, if a critical field in the request parameters is empty or incorrectly formatted, the secondary faulty object may be unable to process the request correctly. By analyzing the request parameters, the degree of impact of the fault on the API call phase can be assessed, and this degree of impact is defined as the first level of impact. The first level of impact can be quantified based on the severity and frequency of the request parameter anomalies. For example, the severity of request parameter anomalies can be divided into three levels: minor, moderate, and severe, each corresponding to a different impact score.

[0169] Step S1534: In the data transmission process, analyze whether the data content transmitted from the initial fault object to the secondary fault object is complete or the format is correct, and determine the second degree of influence of the data transmission process.

[0170] In the data transmission phase, the data content transmitted from the initial faulty object to the secondary faulty object is examined. Incomplete data may prevent the secondary faulty object from obtaining sufficient information for processing; incorrect data format may prevent the secondary faulty object from correctly parsing the data. By analyzing the completeness and format correctness of the data content, the degree of impact of the fault on the data transmission phase can be assessed, and this degree of impact is defined as the second degree of impact. Similarly, the second degree of impact can be quantified based on the severity and frequency of incomplete or incorrect data content.

[0171] Step S1535: In the result feedback stage, analyze whether the time for the secondary fault object to receive the response result from the initial fault object has exceeded the time limit or whether the result content is incorrect, and determine the third degree of influence of the result feedback stage.

[0172] In the result feedback phase, the reception of the response from the initial faulty object by the secondary faulty object is examined. If the response timeout occurs, the secondary faulty object may not receive timely processing results, impacting subsequent business processes; if the result content is incorrect, it may cause the secondary faulty object to make incorrect decisions. By analyzing the response time and content, the degree of impact on the result feedback phase from the fault can be assessed, and this degree of impact is defined as the third level of impact. The third level of impact can be quantified based on the length of the response timeout and the severity of the result content errors.

[0173] Step S1536: Calculate a weighted average value based on the first degree of influence, the second degree of influence, and the third degree of influence to generate a comprehensive evaluation value representing the overall degree of influence of the fault propagation process.

[0174] To determine the overall impact of the fault propagation process, a weighted average of the first, second, and third levels of impact is needed. Different stages may have varying importance in the fault propagation process, therefore, each level of impact must be assigned a corresponding weight. The weighting can be determined based on the system's business characteristics and actual circumstances. For example, if the data transmission stage is crucial for the system's normal operation, a higher weight can be assigned to the second level of impact. Multiplying the first, second, and third levels of impact by their respective weights and then summing the results yields a weighted average, which is the comprehensive assessment of the overall impact of the fault propagation process. This comprehensive assessment more fully reflects the degree of impact of the fault propagation at each stage.

[0175] Step S154: Count the number of systems, services and related business transactions included in the set of affected nodes, and generate a quantitative description representing the breadth of the fault's impact.

[0176] Step S1541: Classify the nodes in the affected node set by system type and count the number of nodes belonging to different business systems as the number of affected systems.

[0177] The set of affected nodes may contain multiple system nodes of different types. By classifying these nodes by system type, the number of nodes belonging to different business systems can be counted. For example, an enterprise information system may include different business systems such as finance, human resources, and sales. Classifying the nodes in the affected node set, counting the number of affected nodes in each business system, and then summing these counts gives the total number of affected systems. The number of affected systems reflects the degree of diffusion of the fault across different business systems.

[0178] Step S1542: Classify the nodes in the affected node set according to their service functions, and count the number of service nodes that provide different business functions as the number of affected services.

[0179] In addition to classifying by system type, it is also necessary to classify the nodes in the affected node set by their service functions. Each system node may provide different business functions; for example, a server node may provide user authentication services, data storage services, etc. By classifying the nodes in the affected node set by their service functions, the number of service nodes providing different business functions can be counted. This number of service nodes represents the number of affected services. The number of affected services reflects the scope of the impact of the fault on different business functions.

[0180] Step S1543: Extract the business transaction identifiers associated with the affected node set from the complete data set, and count the number of business transactions with unique identifiers as the number of affected business transactions.

[0181] The complete dataset records detailed information about each business transaction. Using the node identifiers in the affected node set, the associated business transaction identifiers are extracted from the complete dataset. Then, the number of business transactions with unique identifiers is counted; this number represents the number of affected business transactions. The number of affected business transactions reflects the extent to which the fault impacts actual business transactions.

[0182] Step S1544: Construct an impact breadth assessment model. The inputs to the impact breadth assessment model are the number of affected systems, the number of affected services, and the number of affected business transactions. The output is the impact breadth score.

[0183] To comprehensively assess the breadth of a failure's impact, an impact breadth assessment model needs to be constructed. The inputs to this model are the number of affected systems, the number of affected services, and the number of affected business transactions; the output is an impact breadth score. This model can be constructed using machine learning algorithms or statistical analysis methods. For example, a linear regression model can be used, with the number of affected systems, services, and transactions as independent variables and the impact breadth score as the dependent variable. The parameters of the impact breadth assessment model can be determined by training on a large amount of historical data. The impact breadth score directly reflects the breadth of the failure's impact; a higher score indicates a wider range of impact.

[0184] Step S1545: Generate a corresponding text description based on the impact breadth score. The text description includes an explanation of the correspondence between the number of affected systems, the number of affected services, the number of affected business transactions, and the impact breadth score.

[0185] Based on the impact breadth score, a corresponding text description is generated. This text description details the correspondence between the number of affected systems, the number of affected services, the number of affected business transactions, and the impact breadth score. For example, "This outage affected multiple business systems, resulting in a large number of affected systems. Simultaneously, multiple service nodes were affected, resulting in a large number of affected services. The number of related business transactions was also significant. The overall impact breadth score is high, indicating a wide-ranging impact." This text description allows relevant personnel to more intuitively understand the breadth of the outage's impact.

[0186] Step S155: Analyze the impact of the fault root cause on the continuity of business transactions, determine the duration of business interruption and the number of failed transactions caused by the fault, and generate a quantitative description representing the depth of the fault's impact.

[0187] Step S1551: Extract the start time stamp and recovery time stamp of the fault from the complete data set, and calculate the time difference between the start time stamp and the recovery time stamp as the service interruption duration.

[0188] The complete dataset records the relevant time information of the fault occurrence. By analyzing log data and business transaction data, the start timestamp and recovery timestamp of the fault are extracted. The start timestamp represents the moment the fault began to affect business transactions, and the recovery timestamp represents the moment business transactions returned to normal. The time difference between these two timestamps is calculated; this time difference is the business interruption duration. The business interruption duration reflects the degree of impact of the fault on the continuity of business transactions; the longer the business interruption duration, the more severe the impact of the fault on the business.

[0189] Step S1552: Count the number of business transactions with a failed status associated with the set of affected nodes during the period from the start timestamp to the recovery timestamp as the number of failed transactions.

[0190] After determining the start and recovery timestamps of the failure, the number of failed transactions among the business transactions associated with the affected node set during that time period is counted. By filtering and statistically analyzing the business transaction data in the complete dataset, business transactions related to the affected node set during the failure period are identified, and the number of failed transactions among them is counted. The number of failed transactions directly reflects the impact of the failure on business transactions; a higher number of failed transactions indicates a greater impact on the business.

[0191] Step S1553: Obtain the number of normal business transactions within the same time period before the fault occurred as the baseline transaction number.

[0192] To more accurately assess the impact of a failure on business transactions, it is necessary to obtain the number of normal business transactions within the same time period before the failure occurred as a baseline transaction count. This is achieved by querying and statistically analyzing historical business transaction data from the complete dataset to identify the number of normal business transactions within the same historical time period as the failure occurrence. The baseline transaction count provides a benchmark for comparing business transaction activity during the failure period.

[0193] Step S1554: Calculate the ratio of the number of failed transactions to the baseline number of transactions as the transaction failure rate.

[0194] The transaction failure rate is the ratio of the number of failed transactions to the baseline number of transactions. The transaction failure rate directly reflects the impact of failures on the success rate of business transactions. A higher failure rate indicates a more severe impact of failures on business transactions.

[0195] Step S1555: Construct an impact depth assessment model. The inputs to the impact depth assessment model are the business interruption duration, the number of failed transactions, and the transaction failure rate. The output is an impact depth score.

[0196] To comprehensively assess the depth of an outage's impact, an impact depth assessment model needs to be constructed. The inputs to this model are business interruption duration, number of failed transactions, and transaction failure rate; the output is an impact depth score. This model can be constructed using machine learning algorithms or statistical analysis methods. For example, a multiple linear regression model can be used, with business interruption duration, number of failed transactions, and transaction failure rate as independent variables, and the impact depth score as the dependent variable. The model's parameters are determined by training on a large amount of historical data. The impact depth score more comprehensively reflects the degree to which an outage affects the continuity and success rate of business transactions; a higher score indicates a more severe impact from the outage.

[0197] Step S1556: Generate a corresponding text description based on the impact depth score. The text description includes a description of the relationship between the business interruption duration, the number of failed transactions, the transaction failure rate, and the impact depth score.

[0198] Based on the impact depth score, a corresponding text description is generated. This text description details the correlation between the business interruption duration, the number of failed transactions, the transaction failure rate, and the impact depth score. For example, "This failure resulted in a long business interruption duration, a large number of failed transactions, and a high transaction failure rate. The overall impact depth score is high, indicating that the failure had a very serious impact on business transactions." This text description allows relevant personnel to more intuitively understand the depth of the failure's impact.

[0199] Step S156: Integrate the root cause of the fault, the initial fault object, the secondary fault object, the quantitative description of the breadth of impact, and the quantitative description of the depth of impact to generate a cross-system fault diagnosis report that includes text descriptions and charts.

[0200] This cross-system fault diagnosis report integrates information such as the root cause of the fault, the initial fault object, secondary fault objects, quantitative descriptions of the breadth and depth of impact, and more. The report includes detailed text descriptions, providing a comprehensive explanation of the fault's cause, affected objects, and scope of impact. Furthermore, to more intuitively display fault-related information, the report also includes charts and graphs. For example, bar charts may be used to display the number of affected systems, services, and transactions; line charts may be used to show trends in service interruption duration and transaction failure rate. This combination of text descriptions and charts allows relevant personnel to gain a clearer and more comprehensive understanding of the fault situation.

[0201] Figure 2The illustration shows exemplary hardware and software components of a cross-system fault diagnosis system 100 incorporating multidimensional anomaly detection, which can implement the ideas of this application, according to some embodiments of this application. For example, a processor 120 can be used in the cross-system fault diagnosis system 100 incorporating multidimensional anomaly detection and to perform the functions in this application.

[0202] The cross-system fault diagnosis system 100 combining multidimensional anomaly detection can be a general-purpose server or a special-purpose server; both can be used to implement the cross-system fault diagnosis method combining multidimensional anomaly detection of this application. Although only one server is shown in this application, for convenience, the functions described in this application can be implemented in a distributed manner on multiple similar platforms to balance the load.

[0203] For example, a cross-system fault diagnosis system 100 incorporating multidimensional anomaly detection may include a network port 110 connected to a network, one or more processors 120 for executing program instructions, a communication bus 130, and various forms of storage media 140, such as a disk, ROM, or RAM, or any combination thereof. Exemplarily, the cross-system fault diagnosis system 100 incorporating multidimensional anomaly detection may also include program instructions stored in ROM, RAM, or other types of non-transitory storage media, or any combination thereof. The methods of this application can be implemented according to these program instructions. The cross-system fault diagnosis system 100 incorporating multidimensional anomaly detection also includes an I / O interface 150 between the computer and other input / output devices.

[0204] For ease of explanation, only one processor is described in the cross-system fault diagnosis system 100 incorporating multidimensional anomaly detection. However, it should be noted that the cross-system fault diagnosis system 100 incorporating multidimensional anomaly detection may also include multiple processors. Therefore, the steps executed by one processor as described in this application may also be executed jointly or individually by multiple processors. For example, if the processor of the cross-system fault diagnosis system 100 incorporating multidimensional anomaly detection executes steps A and B, it should be understood that steps A and B may also be executed jointly by two different processors or individually by one processor. For example, the first processor executes step A, the second processor executes step B, or the first processor and the second processor jointly execute steps A and B.

[0205] Furthermore, this embodiment of the invention also provides a readable storage medium, wherein computer-executable instructions are preset in the readable storage medium, and when the processor executes the computer-executable instructions, the cross-system fault diagnosis method combining multi-dimensional anomaly detection is implemented as described above.

[0206] It should be noted that, in order to simplify the description of the present invention and thus help to understand one or more embodiments of the invention, multiple features may sometimes be grouped into one embodiment, drawing or description thereof in the foregoing description of the embodiments of the present invention.

Claims

1. A cross-system fault diagnosis method combining multidimensional anomaly detection, characterized in that, The method includes: Obtain the raw data set generated during the cross-system call process, the raw data set including fragmented call data collected by the link probe, peripheral business transaction data and log data; The original data set is subjected to breakpoint supplementation processing. The breakpoint positions in the fragmented call data are identified based on the application type. The external business transaction data, log data and system association information are integrated to generate a complete data set. The complete dataset is subjected to lateral anomaly diagnosis and processing, and the fault propagation path and anomaly objects are located by using a decision tree algorithm; The abnormal object is subjected to longitudinal anomaly detection processing. Based on the multi-dimensional anomaly detection algorithm, the runtime log, error stack and infrastructure indicators of the abnormal object are analyzed to generate anomaly cause analysis results. Based on the results of the anomaly cause analysis, determine the root cause, fault object, and scope of impact of the fault, and output a cross-system fault diagnosis report; The process of performing lateral anomaly diagnosis on the complete dataset, and locating the fault propagation path and anomaly objects using a decision tree algorithm, includes: Extract a call path feature set from the complete dataset. The call path feature set includes the number of calling nodes, the calling order between nodes, the processing time of a single node, and the node response status identifier. The call path feature set is input into the feature filtering module of the decision tree algorithm, and key features are selected as splitting attributes according to the information gain ratio. The key features include single node processing time abnormality identifier and node response status abnormality identifier. A decision tree classification model is constructed based on the aforementioned splitting attribute. The internal nodes of the decision tree classification model represent feature splitting conditions, and the leaf nodes represent fault propagation path types. The decision tree classification model traverses the call paths in the complete dataset to identify abnormal nodes that meet the splitting conditions as candidate abnormal objects. The candidate abnormal objects are subjected to path backtracking processing to analyze the position of the abnormal node in the call path and its dependency relationship with other nodes, determine the scope of abnormal propagation of subsequent nodes triggered by the abnormal node, and generate a fault propagation path that includes the abnormal starting node, propagation direction and the set of affected nodes. Nodes with incorrect response status and nodes whose processing time exceeds a baseline threshold are extracted from the fault propagation path and used as the finally located anomaly objects. The process involves performing vertical anomaly detection on the abnormal object, analyzing its runtime logs, error stacks, and infrastructure metrics based on a multi-dimensional anomaly detection algorithm, and generating anomaly cause analysis results, including: Extract the runtime log data of the abnormal object from the complete dataset. The runtime log data includes timestamps, operation types, input parameters, and output results. Lexical analysis was performed on the operation log data to extract key operation verbs, data object nouns, and status description adjectives as log feature units; Syntactic analysis is performed on the error stack data of the exception object to identify the stack call level, exception class name and exception trigger code line number, and generate stack structure features. The log feature units and the stack structure features are input into the semantic understanding model to analyze the semantic relationship between log content and stack information, and to extract a set of semantic features representing abnormal triggering conditions. The infrastructure indicator data of the device where the abnormal object is located is obtained from the infrastructure monitoring system. The infrastructure indicator data includes computing resource usage data, network transmission data, and storage access data. Multidimensional anomaly detection processing is performed on the infrastructure indicator data. By using a sliding window to statistically analyze the mean, variance, and rate of change of the indicator data, the time points and magnitudes of abrupt changes in the indicator data are identified. The temporal correlation between the anomaly triggering conditions in the semantic feature set and the mutation time point of the indicator data is analyzed to determine the correlation between the anomaly cause and the changes in infrastructure indicators, and anomaly cause analysis results containing descriptions of anomaly triggering conditions, types of associated infrastructure indicators, and correlation strength are generated.

2. The cross-system fault diagnosis method combining multidimensional anomaly detection according to claim 1, characterized in that, The step involves performing breakpoint supplementation on the original data set, identifying breakpoint locations in the fragmented call data based on application type, and integrating the external business transaction data, log data, and system correlation information to generate a complete data set, including: The fragmented call data is processed for application type matching to identify the call protocol characteristics and data interaction patterns corresponding to different application types; Based on the characteristics of the calling protocol and the data interaction mode, missing data nodes are marked as breakpoint locations in the fragmented calling data; Extract transaction identifier information and a set of interaction parameters aligned with the timestamp of the breakpoint from the peripheral business transaction data; Extract request initiation records, response reception records, and intermediate processing log entries associated with the breakpoint location from the log data; The transaction identifier information, interaction parameter set, request initiation record, response reception record, and intermediate processing log entries are used as supplementary breakpoint data. The system association information is pre-stored and includes service dependencies for cross-system calls, interface call rules, and infrastructure deployment location information. The breakpoint supplementary data is fused with the system association information to fill in the missing data nodes in the fragmented call data, generating a complete data set.

3. The cross-system fault diagnosis method combining multidimensional anomaly detection according to claim 1, characterized in that, The step of performing lexical analysis on the operation log data to extract key operation verbs, data object nouns, and state description adjectives as log feature units includes: The operation log data is cleaned to remove non-semantic information and retain the operation description text content; The operation description text is input into a word segmentation tool for segmentation, generating a word segmentation result containing multiple word units; The word segmentation results are matched with operation verbs based on a preset verb lexicon, and the operation verbs include words that represent system operation behaviors; The data object nouns in the word segmentation results are matched according to a preset noun lexicon, and the data object nouns contain words that represent the operation objects; The state description adjectives in the word segmentation results are matched according to a preset adjective lexicon, and the state description adjectives include words that indicate the state of the operation result; Frequency statistics are performed on the matched operation verbs, data object nouns, and state description adjectives, and words with a frequency exceeding a preset threshold are selected as key log feature units. The key log feature units are arranged and combined in the order of operation verb - data object noun - state description adjective to generate a set of feature units representing the core semantics of the log.

4. The cross-system fault diagnosis method combining multidimensional anomaly detection according to claim 1, characterized in that, The multidimensional anomaly detection processing of the infrastructure indicator data, which involves using a sliding window to statistically analyze the mean, variance, and rate of change of the indicator data, to identify the time points and magnitudes of abrupt changes in the indicator data, includes: The infrastructure indicator data are arranged in timestamp order to generate an indicator data sequence with a time series relationship; A fixed-length sliding window is set to slide across the indicator data sequence, and the length of the sliding window is matched with the average processing time of cross-system calls; Calculate the mean parameter for the indicator data within each sliding window, where the mean parameter represents the average level of the indicator data within the window; The average of the squared differences between the index data and the mean parameter within each sliding window is calculated as the variance parameter, which represents the degree of dispersion of the index data within the window. The ratio of the difference between the mean parameters of adjacent sliding windows to the mean parameter of the previous window is used as the rate of change parameter, which represents the fluctuation range of the indicator data. Set a mutation detection threshold, which includes a variance parameter threshold and a rate of change parameter threshold; Iterate through the variance and rate of change parameters of all sliding windows, and identify the window positions where the variance parameter exceeds the variance parameter threshold or the rate of change parameter exceeds the rate of change parameter threshold as the abrupt change time points. The absolute value of the difference between the indicator data at the time point of mutation and the indicator data under normal conditions is calculated as the mutation amplitude. The indicator data under normal conditions is the mean parameter of the sliding window where no mutation has occurred.

5. The cross-system fault diagnosis method combining multidimensional anomaly detection according to claim 1, characterized in that, The process involves determining the root cause, fault object, and scope of impact based on the anomaly analysis results, and outputting a cross-system fault diagnosis report, including: Extract the description of the anomaly triggering conditions and the types of related infrastructure indicators from the anomaly cause analysis results, and determine the direct cause of the anomaly and the underlying infrastructure factors as the root cause of the failure. By combining the abnormal starting node and the set of affected nodes in the fault propagation path, the initial fault object corresponding to the fault root cause and the subsequent affected secondary fault objects are determined. Analyze the service dependencies between the initial fault object and the secondary fault objects to determine the specific steps in the fault propagation through the call path and the degree of impact of each step; The number of systems, services, and associated business transactions included in the affected node set are counted to generate a quantitative description representing the breadth of the fault's impact. Analyze the impact of the root cause of the failure on the continuity of business transactions, determine the duration of business interruption and the number of failed transactions caused by the failure, and generate a quantitative description representing the depth of the failure's impact. The root cause of the fault, the initial fault object, the secondary fault object, the quantitative description of the breadth of impact, and the quantitative description of the depth of impact are integrated to generate a cross-system fault diagnosis report that includes text descriptions and charts.

6. The cross-system fault diagnosis method combining multidimensional anomaly detection according to claim 5, characterized in that, The analysis of the service dependencies between the initial faulty object and the secondary faulty object determines the specific stages of fault propagation through the call path and the degree of impact of each stage, including: Extract the call path information between the initial fault object and the secondary fault object from the complete dataset. The call path information includes the call interface identifier, data transmission content, and call sequence relationship. The call path information is broken down into stages, dividing the call path into interface call stage, data transmission stage, and result feedback stage; In the API call phase, analyze whether the request parameters when the initial faulty object makes a call to the secondary faulty object are abnormal, and determine the first degree of impact of the API call phase. In the data transmission process, analyze whether the data content transmitted from the initial fault object to the secondary fault object is complete or the format is correct, and determine the second degree of impact of the data transmission process. In the result feedback stage, analyze whether the time for the secondary fault object to receive the response result from the initial fault object exceeds the time limit or whether the result content is incorrect, and determine the third degree of influence of the result feedback stage. A weighted average is calculated based on the first degree of impact, the second degree of impact, and the third degree of impact to generate a comprehensive assessment value representing the overall impact of the fault propagation process.

7. The cross-system fault diagnosis method combining multidimensional anomaly detection according to claim 5, characterized in that, The statistical analysis includes the number of systems, services, and associated business transactions contained in the affected node set, generating a quantitative description representing the breadth of the fault's impact, including: The nodes in the affected node set are classified by system type, and the number of nodes belonging to different business systems is counted as the number of affected systems. The nodes in the affected node set are classified according to their service functions, and the number of service nodes providing different business functions is counted as the number of affected services. Extract the business transaction identifiers associated with the set of affected nodes from the complete data set, and count the number of business transactions with unique identifiers as the number of affected business transactions; Construct an impact breadth assessment model, the input of which is the number of affected systems, the number of affected services, and the number of affected business transactions, and the output is the impact breadth score; A corresponding text description is generated based on the impact breadth score. The text description includes an explanation of the correspondence between the number of affected systems, the number of affected services, the number of affected business transactions, and the impact breadth score.

8. A cross-system fault diagnosis system combining multi-dimensional anomaly detection, characterized in that, The system includes a processor and a memory, the memory being connected to the processor. The memory is used to store programs, instructions, or code, and the processor is used to execute the programs, instructions, or code in the memory to implement the cross-system fault diagnosis method combining multidimensional anomaly detection as described in any one of claims 1-7.

Images