Unsupervised anomaly detection method based on multi-source data of micro-service system

Abstract

The invention provides an unsupervised anomaly detection method based on multi-source data of a micro-service system. The unsupervised anomaly detection method comprises the specific steps of micro-service selection, multi-source feature sequence construction and anomaly detection and interpretation. And during micro-service selection, extracting tracking data to construct a call tree, analyzing a fault propagation mode, and defining the micro-service corresponding to a leaf node in the call tree as a fault sensitive instance. When a multi-source feature sequence is constructed, correlation between indexes and tracking and different faults is analyzed, correlation is carried out in time, and feature serialization is achieved. During anomaly detection, time sequence characteristics are divided into continuous data blocks by using a sliding window mechanism, and the states of the data blocks are judged by encoding and reconstructing the data blocks. During exception explanation, a data block reconstruction distance is extracted, and a micro-service instance with a large exception probability and corresponding features are obtained. The method can be used for enterprises and cloud service providers to evaluate the operation states of key businesses, application services and systems in the internal cloud environment, and guarantee is provided for improving the application service quality.

Description

Technical Field

[0001] The present invention relates to the field of microservice system anomaly detection, and in particular to an unsupervised anomaly detection method based on multi-source data of a microservice system. Background Art

[0002] With the rapid development of cloud-native technologies, the continuous innovation of technologies such as containerization, microservices, and container orchestration tools has made the deployment, expansion, and management of large-scale public applications on the cloud more flexible, and the gradual migration of domestic and foreign enterprise applications to the cloud has become a trend. However, the service architecture of large-scale applications is more complex, the number of service components is larger, and the failure of cross-layer components will seriously affect the quality of application services. It is crucial to implement unified, accurate, and explainable anomaly detection for microservice systems, which provides data support for further fault location and protection.

[0003] However, it is challenging to achieve unified, accurate and explainable anomaly detection for complex microservice architectures. For the multiple modal data generated by the system, existing methods mostly use single modal data to achieve detection. This method lacks the correlation analysis of multi-source features for different types of faults, and the quantification of the characterization ability of different modal features for faults is relatively lacking. Secondly, many existing microservice anomaly detection methods mainly target microservice instances, and need to build independent detection models for the data generated by each instance, which is bound to occupy a lot of resources. In addition, this method regards each instance as a relatively independent individual, ignoring the mutual influence between microservice instances when a fault occurs. Finally, the existing anomaly detection methods have low ability to dynamically capture the mutual influence between microservice instances, lack of analysis of the abnormal data structure of the microservice system, resulting in the misjudgment of normal data that cannot be ignored as abnormal. Therefore, it is necessary to propose a method that uses multi-source data with high correlation with faults from the perspective of the whole system to achieve accurate anomaly detection and explainable anomaly analysis.

[0004] In general, the current methods for feature analysis of microservice systems, microservice instance call association, and anomaly detection have the following three main problems: (1) Single-mode data feature analysis: By using single-mode data such as indicators and tracking to characterize faults, there is a lack of correlation analysis of multi-source features for different types of faults, and it is impossible to quantify the difference in the contribution of different modal data features to multiple fault detection; (2) Instance-based model construction method: Instance-based model construction method requires building an independent model for each instance of the microservice system. This will lead to a large amount of resource consumption, fail to provide the overall operating status of the system, and ignore the mutual influence relationship between microservice instances. (3) Anomaly detection method: The existing anomaly detection method has a low ability to dynamically capture the mutual influence between microservice instances, which will cause normal data that cannot be ignored to be misjudged as anomalies, further resulting in a decrease in the performance of downstream fault location methods. Summary of the invention

[0005] To solve the above problems, the present invention proposes an unsupervised anomaly detection method based on multi-source data of a microservice system. The method selects multi-source data of microservice instances that are sensitive to faults in the system, extracts multi-source data features that contribute greatly to fault characterization, and constructs a unified monitoring model for the microservice system based on the Transformer encoder to achieve accurate anomaly detection and provide a detailed anomaly analysis report. The specific steps of the method are divided into four parts: selection of fault-sensitive microservice instances, construction of multi-source data feature sequences, abnormal event detection based on reconstruction, and abnormal interpretation. When selecting microservice instances, a call tree structure is constructed by extracting Trace data, the fault propagation mode of abnormalities at different locations is analyzed, and the microservice instances corresponding to the leaf nodes in the call tree are defined as fault-sensitive instances. When constructing a multi-source data feature sequence, the correlation between indicators and trace data on the characterization of different types of faults is analyzed, a feature set that contributes greatly to fault detection is selected, and the two modal features are associated in the time dimension to finally achieve feature serialization. When detecting abnormal events, a sliding window mechanism is used to divide the time series features into continuous data blocks, and the data blocks are encoded and reconstructed to determine whether there are abnormalities in the data blocks. When interpreting anomalies, the reconstruction distance of the data block is extracted, and the microservice instances with higher anomaly probability and corresponding features are extracted to provide more detailed anomaly information. The present invention can be used by enterprises and cloud service providers to evaluate the operating status of key businesses, application services and systems in internal cloud environments, and provide guarantees for improving the quality of application services.

[0006] To achieve the purpose of the present invention, the specific technical steps of this scheme are as follows:

[0007] Step (1) Based on the trace data collected from the microservice system, a hierarchical call tree structure is constructed. The propagation pattern of the fault in the call tree is analyzed, and the topological position of the microservice instance in the tree structure is determined. The microservice corresponding to the leaf node in the call tree is regarded as a fault-sensitive instance, and a specific set of sensitive microservice instances is analyzed for microservice systems of different scales;

[0008] Step (2) Based on the metric data collected from the microservice system, analyze the correlation differences between different types of faults and system-level metrics and application-level metrics, and determine the set of metrics that contribute most to fault characterization. Based on the trace data, extract the features used to characterize the duration of each span and the features used to characterize the call relationship between multiple spans;

[0009] Step (3) performs time alignment and clock synchronization operations on the multi-source data features of the fault-sensitive microservice instance, namely the selected indicator features and two trace features, and processes the event stream into a continuous time feature sequence. The time feature sequence is divided into continuous data blocks using a sliding window mechanism, and the data blocks are encoded into embedded vectors;

[0010] Step (4) builds an anomaly detection model based on the Transformer encoder. By minimizing the distance between the reconstruction of a data block and the data block itself, the characteristic form of multi-source data during the normal operation of the microservice system is learned. The anomaly detection model determines the anomaly by the distance between a specific data block and the reconstruction, and provides a detailed interpretable analysis of the anomaly.

[0011] Furthermore, the step (1) specifically comprises the following sub-steps:

[0012] (1.1) Collect trace data within 2-5 hours from a normally running microservice system, and extract the TraceID, SpanID, ParentID and corresponding microservice instance features of each trace data at each moment. Aggregate all spans with the same TraceID into the same trace, and determine the call relationship between different spans through ParentID to identify common calls between instances;

[0013] (1.2) Based on multiple call records, a hierarchical call tree structure is constructed. Each node in the call tree represents a microservice, and the edge represents the call between microservices. The hierarchical design maximizes the characterization of the call priority between microservices;

[0014] (1.3) Based on the constructed call tree, further analyze the fault propagation mode. The fault propagation mode varies depending on the location of the fault. The fault location is divided into leaf nodes and intermediate nodes, and the differences in fault propagation modes caused by different fault locations are discussed;

[0015] (1.4) The fault propagation pattern shows that since the leaf nodes of the call tree are usually the endpoints of the business logic and are heavily dependent on the normal operation of other microservices, the characteristic changes caused by the fault are more obvious on the leaf nodes. The microservice instances represented by the leaf nodes in the call tree are identified as fault-sensitive microservice instances.

[0016] Furthermore, the step (2) specifically comprises the following sub-steps:

[0017] (2.1) Based on the common indicator characteristics and Kubernetes (K8s) platform structure, 11 system-level and application-level indicators are analyzed, and the mutual information technology (MI) is used to measure the differences in the ability of different indicators to characterize different types of faults. Three indicators are selected from the 11 indicators to mainly characterize resource type faults;

[0018] (2.2) Considering the inadequacy of indicator features in characterizing network faults and program code faults, we further proposed span duration features and span offset time features from trace data, and studied the characterization capabilities of the two trace features for three types of faults: network delay, error return, and exception code.

[0019] Furthermore, the detailed information of the multi-source data features in (2.1) to (2.2) is shown in Table 2:

[0020] Table 2 Multi-source characteristics

[0021]

[0022] The step (3) specifically comprises the following sub-steps:

[0023] (3.1) The collected indicators of fault-sensitive instances have a serialized structure, and the metric data is standardized;

[0024] (3.2) The collected trace of the fault-sensitive instance consists of multiple spans. First, multiple spans belonging to the same trace at each moment are aggregated according to TraceID. Subsequently, the corresponding call relationship between the parent span and the child span in each trace is determined using ParentID. Considering the heavy dependence of trace data on user behavior, a situation may arise where a fault-sensitive microservice neither calls other microservices nor is called by other microservices. In this case, the trace-related features of the instance may be missing. Therefore, it is necessary to perform missing value filling operations and perform similar normalization processing on the Trace data;

[0025] (3.3) Achieve time alignment and clock synchronization. Align the timestamps of serialized indicators and trace data, retain the characteristics of multi-source data with the same Unix timestamp, and establish a correspondence between the two types of data on these timestamps to ensure that the clocks of the two monitoring data are synchronized. In addition, when collecting raw traces, it is necessary to aggregate the processed traces every minute to obtain the indicators and trace data characteristics of each minute in the microservice system;

[0026] (3.4) The multi-source features acquired are divided into continuous data blocks in the time dimension using a sliding window mechanism. The features of the fault-sensitive instance at each moment are used as a token for the model input, and the embedding vector is obtained by adding position encoding and flattening.

[0027] The step (4) specifically comprises the following sub-steps:

[0028] (4.1) Use the reconstruction-based model to learn the normal operation mode of the system, adopt the optimized Transformer model as the encoder, encode the normal time series into the latent space to obtain the reconstruction error corresponding to the original data;

[0029] (4.2) Obtain the embedding vector and reconstruction vector of each data block through embedded coding and reconstruction. Determine whether an abnormality occurs based on the change in the distance between the original data and the reconstructed data;

[0030] (4.3) Design an interpreter to analyze anomalies. By calculating the distance between the embedding vector and the reconstructed vector of the original data block, the microservice instances and corresponding features that contribute most to anomaly judgment are determined to help further locate the fault.

[0031] An electronic device comprises a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the processor implements the unsupervised anomaly detection method based on multi-source data of a microservice system when executing the program.

[0032] A computer-readable storage medium stores computer instructions, which, when executed by a processor, implement the unsupervised anomaly detection method based on multi-source data of a microservice system.

[0033] Compared with the prior art, the present invention has the following advantages and beneficial effects:

[0034] (1) The present invention proposes an unsupervised anomaly detection method based on multi-source data of a microservice system, which can associate the acquired multi-source data and accurately and quickly analyze the overall operating status of the system at a specific moment. When a system anomaly is detected, it has the ability to provide abnormal microservice instances and feature information of significant changes, thereby realizing monitoring and security maintenance of the microservice system on the cloud.

[0035] (2) The present invention includes correlation analysis between multi-source data features and different types of faults, constructing a hierarchical microservice call tree structure based on tracking data, encoding and reconstructing system features using a Transformer encoder, obtaining more accurate anomaly detection results, and providing a detailed anomaly analysis report.

[0036] (3) The unsupervised anomaly detection method based on multi-source data of microservice system proposed in the present invention can be applied to enterprises and cloud service providers to evaluate the operating status of key businesses, application services and systems in the internal cloud environment, and has high application prospects. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] Figure 1 It is a framework for unsupervised anomaly detection methods based on multi-source data in microservice systems;

[0038] Figure 2 The span duration and span offset feature maps in the tracking;

[0039] Figure 3 Schematic diagram of fault propagation mode at different fault locations. DETAILED DESCRIPTION

[0040] The technical solution provided by the present invention will be described in detail below in conjunction with specific embodiments. It should be understood that the following specific implementation methods are only used to illustrate the present invention and are not used to limit the scope of the present invention.

[0041] Embodiment 1: The present invention provides an unsupervised anomaly detection method based on multi-source data of a microservice system, and its structural framework is as follows: Figure 1 As shown, the following steps are included:

[0042] (1) Based on the trace data collected from the microservice system, a hierarchical call tree structure is constructed. The propagation pattern of the fault in the call tree is analyzed, and the topological position of the microservice instance in the tree structure is determined. The microservice corresponding to the leaf node in the call tree is regarded as a fault-sensitive instance, and a specific set of sensitive microservice instances is analyzed for microservice systems of different scales;

[0043] The specific process of this step is as follows:

[0044] (1.1) Collect trace data within 3 hours from a normally running microservice system, extract the TraceID, SpanID, ParentID and corresponding microservice instance features of each trace data at each moment. Aggregate all spans with the same TraceID into the same trace, and determine the call relationship between different spans through ParentID to identify common calls between instances;

[0045] (1.2) Based on multiple call records, a hierarchical call tree structure is constructed, as follows Figure 3 As shown. Each node in the call tree represents a microservice, and the edge represents the call between microservices. A microservice that is not called by any other microservice is the root node of the tree; a microservice that does not call any other microservice is a leaf node of the tree; other microservices are intermediate nodes. When there is an edge between a high-level node and a low-level node in the call tree, it means that the high-level microservice calls the low-level microservice. The layered design maximizes the characterization of the call priority between microservices;

[0046] (1.3) Based on the constructed call tree, the fault propagation mode is further analyzed. The fault propagation mode varies according to the location where the fault occurs. The fault location is divided into leaf nodes and intermediate nodes, and the differences in fault propagation modes caused by different fault locations are discussed. If the abnormal leaf node is not called by other nodes during this period, the fault is limited to this node, such as Figure 3 As shown in (a); if the abnormal leaf node is called by the parent node during this period, the error may affect the ancestors and descendants of some nodes, such as Figure 3 As shown in (b); when an intermediate node fails, if the abnormal intermediate node is not called during the failure, the failure may propagate along the call chain and affect some child nodes of the node, such as Figure 3 If an abnormal intermediate node is called, the fault may present the pattern in (c), and also affect some of the node's ancestor nodes and their descendant nodes, similar to the pattern in (b);

[0047] (1.4) The fault propagation pattern shows that since the leaf nodes of the call tree are usually the endpoints of the business logic and are heavily dependent on the normal operation of other microservices, the characteristic changes caused by the fault are more obvious on the leaf nodes. The microservice instances represented by the leaf nodes in the call tree are identified as fault-sensitive microservice instances.

[0048] (2) Based on the metric data collected from the microservice system, analyze the correlation differences between different types of faults and system-level metrics and application-level metrics, and determine the set of metrics that contribute most to fault characterization. Based on the trace data, extract the features used to characterize the duration of each span and the features used to characterize the call relationship between multiple spans;

[0049] The specific process of this step is as follows:

[0050] (2.1) Based on the common indicator characteristics and Kubernetes (K8s) platform structure, 11 system-level and application-level indicators are analyzed, and the mutual information technology (MI) is used to measure the differences in the ability of different indicators to characterize different types of faults. Three indicators are selected from the 11 indicators to mainly characterize resource type faults;

[0051] (2.2) Considering the inadequacy of the indicator features in characterizing network type faults and program code faults, we further propose the Span duration feature and Span offset time feature from the Trace data. In a microservice system, Trace data uses parent spans and child spans to represent the hierarchical relationship in the service call chain. Figure 2 As shown, there are three types of call relationships between parent spans and child spans, and the same three relationships also exist between multiple child spans that share the same parent span. According to the relationship between the end time of the parent span and the child span, the Span Offset is divided into positive offset and negative offset. The characterization capabilities of the two Trace features for three types of faults: network delay, error return, and exception code are studied;

[0052] Furthermore, detailed information on the multi-source data features in (2.1) to (2.2) is shown in Table 3.

[0053] Table 3 Multi-source characteristics

[0054]

[0055] Step (3) performs time alignment and clock synchronization operations on the multi-source data features of the fault-sensitive microservice instance, namely the selected indicator features and two trace features, and processes the event stream into a continuous time feature sequence. The time feature sequence is divided into continuous data blocks using a sliding window mechanism, and the data blocks are encoded into embedded vectors;

[0056] The specific process of this step is as follows:

[0057] (3.1) The indicators of the collected fault-sensitive instances have a serialized structure, and the metric data is standardized; considering that the training phase uses normal data generated by the system, and the test phase uses mixed data composed of a large amount of normal data interspersed with a small amount of abnormal data. In order to avoid the standardization process causing the training model to predict all normal data as abnormal, it is necessary to standardize the training set and the test set separately. The specific process is shown in Formula 1:

[0058] M′ d =M d -mean(M train ) / std(M train ) (1)

[0059] Among them, M d Represents the original metric data, M′ d Represents standardized data, mean(M train ) and std(M train ) refer to the mean and standard deviation of the training set respectively;

[0060] (3.2) The collected trace of the fault-sensitive instance consists of multiple spans. First, multiple spans belonging to the same trace at each moment are aggregated according to TraceID. Subsequently, ParentID is used to determine the corresponding calling relationship between the parent span and the child span in each trace. Considering the heavy dependence of trace data on user behavior, a situation may occur in which a fault-sensitive microservice neither calls other microservices nor is called by other microservices. In this case, the trace-related features of the instance may be missing. Therefore, it is necessary to perform a missing value filling operation and perform similar normalization processing on the Trace data; considering the continuity of the microservice state, the missing values ​​are filled with the average value of the features in the range of [t-ε, t+ε], and the scheme of the present invention uses ε=2. Subsequently, a normalization process similar to that used for metric serialization is applied to the two trace-related characteristics that change over time;

[0061] (3.3) Achieve time alignment and clock synchronization. Align the timestamps of serialized indicators and trace data, retain the characteristics of multi-source data with the same Unix timestamp, and establish a correspondence between the two types of data on these timestamps to ensure that the clocks of the two monitoring data are synchronized. In addition, when collecting raw traces, it is necessary to aggregate the processed traces every minute to obtain the indicators and trace data characteristics of each minute in the microservice system;

[0062] (3.4) The multi-source features acquired are divided into continuous data blocks in the time dimension using a sliding window mechanism, where each data block contains three-dimensional features corresponding to W moments. The features of the fault-sensitive instance at each moment are used as a token of the model input, such as Figure 1 In order to process three-dimensional data D t , without losing the original data D t The abnormal information carried in D t Flattening is performed on the two dimensions of features and microservice instances to obtain 2D time series features Finally, the embedding vector is obtained by adding the position encoding. The embedding process is shown in Formula 2:

[0063]

[0064] Among them, t represents a certain moment, E pos represents position encoding, W, M and F are the sliding window size, the number of microservices and the number of features respectively.

[0065] (4) Build an anomaly detection model based on the Transformer encoder. By minimizing the distance between the reconstruction of a data block and the data block itself, the feature form of multi-source data during the normal operation of the microservice system is learned. The anomaly detection model determines the anomaly by the distance between a specific data block and the reconstruction, and provides a detailed interpretable analysis of the anomaly;

[0066] The specific process of this step is as follows:

[0067] (4.1) Using the reconstruction-based model to learn the normal operation mode of the system, the optimized Transformer model is used as the encoder to encode the normal time series into the latent space to obtain the reconstruction error corresponding to the original data; the structure of the encoder is as follows Figure 1 As shown, it includes alternating multi-head self-attention (MSA) blocks, MLP blocks, and output blocks;

[0068] (4.2) Through embedding coding and reconstruction, the embedding vector Max and reconstruction vector Rec of each data block are obtained. Whether an abnormality occurs is determined based on the change in the distance between the original data and the reconstructed data. If it increases significantly, it is an abnormality; the reconstruction error between the original data and the reconstructed data is used to measure the distance between them and used as the loss function for model training. The calculation process is shown in Formula 3:

[0069]

[0070] Where M is the number of microservices and F is the number of features. During training, normal data is divided into 8:2, and abnormalities are judged by reconstruction error during testing. Each sliding window outputs the detection result. If it is abnormal at any moment, the entire data block is marked as abnormal. Finally, the prediction result is compared with the label to evaluate the detection performance;

[0071] (4.3) Design an interpreter to analyze the anomaly. By calculating the distance between the embedding vector M and the reconstructed vector R of the original data block, the microservice instance and corresponding features that contribute more to the anomaly judgment are determined to help further locate the fault. The specific calculation process is shown in Formula 4:

[0072]

[0073] Among them, M and F represent the number of microservices and the number of features respectively.

[0074] The technical means disclosed in the scheme of the present invention are not limited to the technical means disclosed in the above-mentioned implementation mode, but also include technical schemes composed of any combination of the above-mentioned technical features. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications are also regarded as the protection scope of the present invention.

Claims

1. An unsupervised anomaly detection method based on multi-source data of a microservice system, characterized in that: The method comprises the following step: Step (1) constructs a hierarchical call tree structure based on the trace data collected from the microservice system, analyzes the propagation mode of the fault in the call tree, and determines the topological position of the microservice instance in the tree structure. The microservice corresponding to the leaf node in the call tree is taken as a fault-sensitive instance, and a specific set of sensitive microservice instances is analyzed for microservice systems of different scales. Step (2) Based on the metric data collected from the microservice system, analyze the correlation differences between different types of faults and system-level metrics and application-level metrics, determine the set of metrics that contribute most to fault characterization, and extract features used to characterize the duration of each span and features used to characterize the call relationship between multiple spans based on the trace data; Step (3) performs time alignment and clock synchronization operations on the multi-source data features of the fault-sensitive microservice instance, namely, the selected indicator features and two trace features, processes the event stream into a continuous time feature sequence, divides the time feature sequence into continuous data blocks using a sliding window mechanism, and encodes the data blocks into embedded vectors; Step (4) constructs an anomaly detection model based on the Transformer encoder. By minimizing the distance between the reconstruction of a data block and the data block itself, the feature form of multi-source data during the normal operation of the microservice system is learned. The anomaly detection model determines the anomaly through the distance between a specific data block and the reconstruction, and provides a detailed interpretable analysis of the anomaly.

2. According to claim 1, the unsupervised anomaly detection method based on multi-source data of a microservice system is characterized in that: The step (1) specifically comprises the following sub-steps: (1.1) Collect trace data within 2-5 hours from a normally running microservice system, extract the TraceID, SpanID, ParentID and corresponding microservice instance features of each trace data at each moment, aggregate all spans with the same TraceID into the same trace, and determine the call relationship between different spans through ParentID to identify common calls between instances; (1.2) Based on multiple call records, a hierarchical call tree structure is constructed. Each node in the call tree represents a microservice, and the edge represents the call between microservices. The hierarchical design maximizes the representation of the call priority between microservices. (1.3) Based on the constructed call tree, the fault propagation mode is analyzed. The fault propagation mode varies according to the location where the fault occurs. The fault location is divided into leaf nodes and intermediate nodes, and the differences in fault propagation modes caused by different fault locations are discussed; (1.4) The fault propagation pattern shows that since the leaf nodes of the call tree are usually the endpoints of the business logic and are heavily dependent on the normal operation of other microservices, the characteristic changes caused by the fault are more obvious on the leaf nodes, and the microservice instances represented by the leaf nodes in the call tree are identified as fault-sensitive microservice instances.

3. The unsupervised anomaly detection method based on multi-source data of a microservice system according to claim 2 is characterized in that: The step (2) specifically comprises the following sub-steps: (2.1) Based on the common indicator characteristics and Kubernetes (K8s) platform structure, 11 system-level and application-level indicators are analyzed, and the mutual information technology (MI) is used to measure the differences in the ability of different indicators to characterize different types of faults. Three indicators are selected from the 11 indicators to mainly characterize resource type faults; (2.2) Considering the inadequacy of indicator features in characterizing network type faults and program code faults, we further propose span duration features and span offset time features from trace data, and study the characterization capabilities of the two trace features for three types of faults: network delay, error return, and exception code.

4. The unsupervised anomaly detection method based on multi-source data of a microservice system according to claim 3 is characterized in that: The detailed information of the multi-source data features in steps (2.1) to (2.2) is shown in Table 1: Table 1 Multi-source characteristics 5. The unsupervised anomaly detection method based on multi-source data of a microservice system according to claim 2 is characterized in that: The step (3) specifically comprises the following sub-steps: (3.1) The collected indicators of fault-sensitive instances have a serialized structure, and the metric data is standardized. The training set and the test set need to be standardized separately. The specific process is shown in Formula 1: M′ d =M d -mean(M train ) / std(M train ) (1) Among them, M d Represents the original metric data, M′ d Represents standardized data, mean(M train ) and std(M train ) refer to the mean and standard deviation of the training set respectively; (3.2) The collected trace of the fault-sensitive instance consists of multiple spans. First, multiple spans belonging to the same trace at each moment are aggregated according to TraceID. Then, the corresponding call relationship between the parent span and the child span in each trace is determined using ParentID. (3.3) Time alignment and clock synchronization are achieved. The timestamps of serialized indicators and trace data are aligned, the characteristics of multi-source data with the same Unix timestamp are retained, and the corresponding relationship between the two types of data is established on these timestamps to ensure that the clocks of the two monitoring data are synchronized. In addition, when collecting raw traces, the processed traces need to be aggregated every minute to obtain the indicators and trace data characteristics of each minute in the microservice system; (3.4) The multi-source features acquired are divided into continuous data blocks in the time dimension using a sliding window mechanism, where each data block contains three-dimensional features corresponding to W moments. The features of the fault-sensitive instance at each moment are used as a token of the model input. In order to process the three-dimensional data D t , without losing the original data D t The abnormal information carried in D t Flattening is performed on the two dimensions of features and microservice instances to obtain 2D time series features Finally, the embedding vector is obtained by adding the position encoding. The embedding process is shown in Formula 2: Among them, t represents a certain moment, E pos represents position encoding, W, M and F are the sliding window size, the number of microservices and the number of features respectively.

6. The unsupervised anomaly detection method based on multi-source data of a microservice system according to claim 3 is characterized in that: The step (4) specifically comprises the following sub-steps: (4.1) Use the reconstruction-based model to learn the normal operation mode of the system, adopt the optimized Transformer model as the encoder, encode the normal time series into the latent space to obtain the reconstruction error corresponding to the original data; (4.2) Through embedded coding and reconstruction, the embedded vector Max and the reconstructed vector Rec of each data block are obtained. Whether an abnormality occurs is determined based on the change in the distance between the original data and the reconstructed data. If it increases significantly, it is an abnormality. The reconstruction error between the original data and the reconstructed data is used to measure the distance between them and used as the loss function for model training. The calculation process is shown in Formula 3: Among them, M is the number of microservices, F is the number of features, and the normal data is divided into 8:2 during training. During testing, the anomaly is judged by reconstruction error. Each sliding window outputs the detection result. If it is abnormal at any time, the entire data block is marked as abnormal. Finally, the prediction result is compared with the label to evaluate the detection performance; (4.3) An interpreter is designed to analyze the anomaly. By calculating the distance between the embedding vector M and the reconstructed vector R of the original data block, the microservice instance and the corresponding features that contribute most to the anomaly judgment are determined to help further locate the fault. The specific calculation process is shown in Formula 4: Among them, M and F represent the number of microservices and the number of features respectively.

7. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the program, the unsupervised anomaly detection method based on multi-source data of a microservice system is implemented as described in any one of claims 1 to 6 above.

8. A computer-readable storage medium having computer instructions stored thereon, characterized in that: When the computer instruction is executed by the processor, the unsupervised anomaly detection method based on multi-source data of a microservice system as described in any one of claims 1 to 6 is implemented.

Images