Micro-service architecture intelligent alarm method and related equipment

Abstract

The invention discloses a micro-service architecture intelligent alarm method and related equipment, and the method comprises the steps: collecting service call chain Span data in real time, preprocessing the data, and storing the data in a time sequence database, thereby providing complete and timely data support for anomaly detection, and achieving the comprehensive perception of a service operation state. And then periodically extracting a time sequence, counting and carrying out service association on multi-dimensional feature construction vectors, depicting service laws in a multi-dimensional manner, matching with an isolated forest algorithm anomaly detection model, deeply mining an anomaly mode, outputting an accurate real-time anomaly score, and sensitively capturing service anomalies. The dynamic threshold value calculated through the service history normal data is flexibly adapted to the service period fluctuation, the defect of a fixed threshold value is avoided, and the judgment accuracy is greatly improved by combining with the exception list generated by the exception score. Finally, based on call chain topology root cause analysis, alarm information is aggregated according to service domains, scattered prompts are converted into core root cause alarms, a clear positioning basis is provided for operation and maintenance personnel, and the fault processing efficiency is remarkably improved.

Description

Technical Field

[0001] This application relates to the field of microservice technology, and more specifically, to a method and related equipment for intelligent alarming in microservice architecture. Background Technology

[0002] With the acceleration of digital transformation, microservice architecture has been widely adopted due to its advantages such as elastic scaling and independent deployment. Backend systems are often broken down into dozens or even hundreds of independent services, forming complex call chains via protocols such as HTTP and RPC. Ensuring system stability is a core operational requirement. Service call chain monitoring systems need to collect key data such as response time and error rate and trigger alarms; otherwise, if core modules such as payment services fail to recover for an extended period, transaction flow will be directly affected. Currently, call chain monitoring has become a core aspect of microservice operations and maintenance, but existing technologies have significant shortcomings and are insufficient to meet the demands of efficient operations and maintenance.

[0003] Current technologies primarily trigger alarms through post-event statistics, such as calculating indicators at fixed intervals and issuing alarms when they exceed preset thresholds, relying on static, fixed thresholds to determine anomalies. The drawbacks are twofold: First, alarms are delayed and have a high false alarm rate. The delay manifests in the inability to predict anomalies in advance; as the situation gradually worsens, alarms are only triggered after the fixed threshold has been exceeded, by which time the fault has already affected some transactions. The high false alarm rate stems from the inability of static thresholds to adapt to business fluctuations. During peak sales periods, increased normal order service response times can trigger alarms based on the original threshold, while during off-peak periods, even minor service errors can lead to false alarms due to exceeding the fixed threshold. Second, alarm storms make root cause location difficult. A failure in the core service database can trigger a chain of alarms in multiple downstream services, requiring operations personnel to manually trace the call chain relationships to locate the root cause, which is time-consuming and severely delays fault repair.

[0004] Therefore, there is an urgent need for a new intelligent alarm solution for microservice architecture to address the shortcomings of existing technologies and provide strong support for the stable operation of microservice systems. Summary of the Invention

[0005] This application provides a method and related equipment for intelligent alarming in microservice architectures. Through a complete process design—including real-time collection and processing of service call chain Span data, extraction of multi-dimensional features to construct vectors, detection of anomalies using the isolated forest algorithm, setting dynamic thresholds based on historical data to filter abnormal services, and aggregation of root cause alarms based on call chain topology analysis—it achieves precise and efficient microservice alarming, improves the timeliness and accuracy of alarms, and provides support for the stable operation of microservice systems.

[0006] A method for intelligent alerting in a microservice architecture includes:

[0007] Collect Span data from the service call chain in the microservice architecture, preprocess it, and store it in a time-series database;

[0008] Periodically extract multi-dimensional features from the time-series database to construct a feature vector, wherein the multi-dimensional features include time-series features, statistical features, and inter-service correlation features;

[0009] The feature vectors are input into an anomaly detection model trained based on the isolated forest algorithm, and the real-time anomaly scores of each service are output.

[0010] Based on the real-time anomaly scores and dynamic anomaly detection thresholds of each service, an anomaly service list is generated, wherein the dynamic anomaly detection thresholds are calculated based on the mean and standard deviation of the anomaly score distribution of each service within a historical normal time window.

[0011] Root cause analysis is performed on each abnormal service in the abnormal service list based on the call chain topology, and at least one root cause alarm message is generated based on the aggregation of business domain relationships.

[0012] The root cause alarm information is output to the operation and maintenance platform.

[0013] Optionally, the step of performing root cause analysis on each abnormal service in the abnormal service list based on the call chain topology includes:

[0014] Construct an exception service call graph based on the parent-child relationship of the call chain in the call chain topology;

[0015] The root cause tracing rules are used to identify the root cause service from the abnormal service call graph. These root cause tracing rules include:

[0016] If the anomaly score of the first service is higher than the preset anomaly score of all its downstream dependent services, then the first service is determined to be a candidate root cause service.

[0017] And / or,

[0018] If the second service does not have a parent service in the list of abnormal services, then the second service is determined to be a candidate root cause service.

[0019] Optionally, the process of generating root cause alarm information based on business domain relationships includes:

[0020] Determine the business domain to which each of the candidate root cause services belongs;

[0021] Multiple candidate root cause services belonging to the same business domain are aggregated into a root cause alarm unit, and the service with the highest real-time anomaly score in each root cause alarm unit is taken as the final root cause service.

[0022] Root cause alarm information is generated based on the final root cause service of each root cause alarm unit and the associated services of the final root cause service within its business domain.

[0023] Optionally, extracting multidimensional features from the time-series database to construct a feature vector includes:

[0024] The response time series within the first preset time window is queried from the time series database, and the slope of the time series is calculated by linear regression as the first time series feature reflecting the trend of response time change.

[0025] The error rate sequence within the second preset time window is queried from the time series database, and the error rate slope is calculated by linear regression as a second time series feature reflecting the trend of error rate change.

[0026] The time-series database is used to query all service call records within the most recent unit time period, and the P-quantile of the response time and the proportion of erroneous requests to the total number of requests are calculated as statistical features reflecting the current state of the service.

[0027] The average response time of the parent service of the current service within the past unit time is queried from the time series database, and the ratio of the average response time to the average response time of the current service is calculated as the first service association feature.

[0028] The error rate of all direct downstream services of the current service within a unit time period is queried from the time series database, and the maximum error rate is taken as the second service association feature.

[0029] The first time series feature, the second time series feature, the statistical feature, the first service association feature, and the second service association feature are standardized and then concatenated in a preset order to form a feature vector.

[0030] Optionally, the training process of the anomaly detection model includes:

[0031] Obtain the multidimensional feature vectors of each service during the historical normal period to form an unlabeled training sample set;

[0032] With the goal of fitting the distribution of normal business data in the training sample set, the isolated forest algorithm is used to train the training sample set until the model converges;

[0033] The isolated forest algorithm includes constructing a forest composed of multiple isolated trees, and when constructing each isolated tree, randomly selecting a subset of features from all features for node splitting.

[0034] Optional, also includes:

[0035] If the real-time anomaly score exceeds the anomaly detection dynamic threshold, the predicted failure time of the service is predicted by combining the preset anomaly score upper limit and the time step coefficient.

[0036] The calculated predicted failure time is added to the corresponding service entry in the abnormal service list and ultimately included in the root cause alarm information.

[0037] A microservice architecture intelligent alarm device, comprising:

[0038] The data acquisition unit is used to collect Span data from the service call chain in the microservice architecture, and store it in the time-series database after preprocessing.

[0039] The feature construction unit is used to periodically extract multi-dimensional features from the time-series database to construct feature vectors. The multi-dimensional features include time-series features, statistical features, and inter-service correlation features.

[0040] An anomaly scoring unit is used to input the feature vector into an anomaly detection model trained based on the isolated forest algorithm and output the real-time anomaly score for each service.

[0041] An anomaly detection unit is used to generate an anomaly service list based on the real-time anomaly score and anomaly detection dynamic threshold of each service, wherein the anomaly detection dynamic threshold is calculated based on the mean and standard deviation of the anomaly score distribution of each service within a historical normal time window.

[0042] The root cause alarm unit is used to perform root cause analysis on each abnormal service in the abnormal service list according to the call chain topology, and generate at least one root cause alarm message based on the aggregation of business domain relationships.

[0043] The alarm output unit is used to output the root cause alarm information to the operation and maintenance platform.

[0044] A microservice architecture-based intelligent alarm device, comprising a memory and a processor;

[0045] The memory is used to store programs;

[0046] The processor is used to execute the program to implement the various steps of the intelligent alarm method for microservice architecture as described in any of the above.

[0047] A readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the intelligent alerting method for a microservice architecture as described in any of the preceding claims.

[0048] A computer program product includes a computer program that, when run by a processor, executes the steps of the intelligent alerting method for a microservice architecture as described in any of the preceding claims.

[0049] As can be seen from the above technical solutions, the intelligent alarm method and related equipment for microservice architecture provided in this application achieve accuracy and efficiency in microservice alarms through a full-process technical design encompassing data acquisition and processing, feature engineering, intelligent detection, dynamic threshold filtering, and root cause aggregation. This method collects Span data from the service call chain in the microservice architecture in real time, preprocesses it, and stores it in a time-series database, providing a comprehensive and high-quality data foundation for subsequent analysis. This ensures the integrity and timeliness of the data required for anomaly detection, enabling a comprehensive understanding of the service's operational status.

[0050] By periodically extracting time-series features, statistical features, and inter-service correlation features to construct feature vectors, the system can characterize service operation patterns from multiple dimensions, providing rich evidence for anomaly identification. Combined with an anomaly detection model trained based on the isolated forest algorithm, it can deeply mine anomaly patterns in the data, outputting accurate real-time anomaly scores for each service, and achieving sensitive capture of service anomalies. By introducing dynamic thresholds calculated based on the mean and standard deviation of anomaly score distributions within historical normal service time windows, the system can flexibly adapt to the operational characteristics of services in different business cycles, effectively avoiding the insufficient adaptability of fixed thresholds. Combined with the anomaly service list generated by real-time anomaly scores, the accuracy of anomaly judgment is significantly improved. By calling the chain topology to conduct root cause analysis and aggregating alarm information based on business domain relationships, scattered anomaly prompts can be transformed into root cause alarms focusing on core issues, simplifying the alarm information hierarchy. Combined with accurate output to the operations and maintenance platform, this provides operations and maintenance personnel with clear fault location evidence, significantly improving fault handling efficiency. The overall solution, through the deep integration of data processing, intelligent algorithms, and business logic, comprehensively improves the timeliness, accuracy, and practicality of microservice alarms, providing strong support for the stable operation of microservice systems. Attached Figure Description

[0051] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0052] Figure 1 This is a flowchart of a microservice architecture intelligent alarm method disclosed in an embodiment of this application;

[0053] Figure 2 This is a schematic diagram of a microservice architecture intelligent alarm device disclosed in an embodiment of this application;

[0054] Figure 3 This is a hardware structure block diagram of a microservice architecture intelligent alarm device disclosed in an embodiment of this application. Detailed Implementation

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

[0056] This application can be used in a wide variety of general-purpose or special-purpose computing device environments or configurations. For example: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor devices, distributed computing environments including any of the above devices, etc.

[0057] The following section introduces the solution proposed in this application. The technical solution is as follows, and details are provided below.

[0058] Figure 1 This is a flowchart of a microservice architecture intelligent alarm method disclosed in an embodiment of this application.

[0059] like Figure 1 As shown, the method may include:

[0060] Step S1: Collect Span data of the service call chain in the microservice architecture, preprocess it and store it in the time series database.

[0061] Specifically, Span data generated during service calls within the microservice architecture is collected. Non-intrusive probe technology is used to automatically embed probes during service startup, comprehensively collecting raw data including basic fields such as unique call chain identifiers, service names, interface names, response times, error indicators, and call timestamps. A business type field is also added, mapped from the interface name to differentiate between different business scenarios. The collected raw Span data undergoes preprocessing. For missing response time data, it is filled with the recent average response time for the same business type within the service. Extreme outliers exceeding the normal data distribution range are removed to avoid interfering with subsequent model training. Metrics such as response time, call count, and error rate are converted to uniform numerical values ​​to ensure data standardization. After preprocessing, the data is stored in a time-series database according to service name and timestamp partitioning rules, retaining historical data periods sufficient for model training and providing high-quality foundational data for subsequent anomaly feature learning.

[0062] Step S2: Periodically extract multi-dimensional features from the time-series database to construct a feature vector. The multi-dimensional features include time-series features, statistical features, and inter-service correlation features.

[0063] Specifically, relevant data for each service is extracted from a time-series database according to a preset time period, and three types of multi-dimensional features are extracted to construct a feature vector. Time-series features reflect the changing trends of indicators over time, including the slope of response time changes, the trend of error rate changes, and the volatility of call counts within a specified time period, effectively capturing the slow deterioration trend of service operation status. Statistical features reflect the overall distribution pattern of indicators, covering the quantiles of response time, error rate, average response time, and call counts within a specified time period, enabling accurate identification of sudden anomalies. Service inter-relationship features reflect the dependency relationships between services, including the response time ratio of the parent service to the current service and the error rate of downstream services, avoiding the isolation of judging the operation status of individual services. These features comprehensively characterize the service operation status from three dimensions: time-varying trends, overall distribution patterns, and service dependency relationships. After extraction, they are integrated to form a standardized feature vector.

[0064] Step S3: Input the feature vector into the anomaly detection model trained based on the isolated forest algorithm, and output the real-time anomaly score for each service.

[0065] Specifically, the constructed feature vectors are input into the anomaly detection model, which is built on the Isolation Forest algorithm. This model uses feature vector data from historical normal service operation periods for unsupervised training, eliminating the need for manual labeling of anomalous samples and adapting to the scarcity of anomalous samples in microservice scenarios. During model training, samples are repeatedly segmented by randomly selecting features and feature thresholds until each sample is isolated or reaches a preset tree depth, ultimately learning the pattern of isolated path lengths for normal samples. In the real-time detection phase, the model calculates the average isolated path length corresponding to the input feature vectors and outputs a real-time anomaly score for each service. A higher score indicates a greater likelihood of an anomaly in the service, achieving accurate quantitative assessment of service anomaly states.

[0066] The training process of the anomaly detection model includes:

[0067] ① Obtain the multidimensional feature vectors of each service during the historical normal period to form an unlabeled training sample set;

[0068] ② With the goal of fitting the distribution of normal business data in the training sample set, the isolated forest algorithm is used to train the training sample set until the model converges;

[0069] The isolated forest algorithm includes constructing a forest composed of multiple isolated trees, and when constructing each isolated tree, randomly selecting a subset of features from all features for node splitting.

[0070] Specifically, the process begins by acquiring multi-dimensional feature vectors for each service during its historical normal operation period. These vectors encompass time-series features reflecting the trend of indicator changes over time, statistical features reflecting the overall distribution pattern of indicators, and correlation features characterizing the dependencies and influences between services. These multi-dimensional feature vectors are then integrated to form an unlabeled training sample set. This set contains only data under normal business operation conditions, eliminating the need for manual labeling of anomaly categories. Subsequently, aiming to fit the distribution pattern of normal business data in the training sample set, the Isolation Forest algorithm is used to train the model on this training sample set until the model converges. The core of the Isolation Forest algorithm lies in constructing a forest structure composed of multiple isolated trees. During the construction of each isolated tree, a feature subset is randomly selected from all multi-dimensional features. Based on this feature subset, a splitting threshold is randomly determined, and the samples are recursively split until each sample is isolated as a single leaf node or a preset tree depth limit is reached. Through the collaborative learning of multiple isolated trees, the model can accurately capture the distribution characteristics of normal business data, laying the foundation for subsequent anomaly identification.

[0071] Step S4: Generate an abnormal service list based on the real-time anomaly score and dynamic anomaly detection threshold of each service, wherein the dynamic anomaly detection threshold is calculated based on the mean and standard deviation of the anomaly score distribution of each service within a historical normal time window.

[0072] Specifically, anomaly determination is performed based on the real-time anomaly scores and dynamic anomaly detection thresholds of each service, generating a list of abnormal services. The dynamic anomaly detection threshold is not a fixed value but is dynamically calculated based on the distribution of anomaly scores within the historical normal operating time window of each service. Specifically, it is determined by statistically analyzing the mean and standard deviation of anomaly scores within that period, automatically adjusting to fluctuations in business operation status, effectively adapting to the fluctuating needs of different business scenarios such as peak sales periods and off-peak periods. When the real-time anomaly score of a service exceeds its corresponding dynamic threshold, the service is determined to be an abnormal service. Simultaneously, the difference between the real-time anomaly score and the dynamic threshold, historical anomaly development patterns, and predicted failure time are combined to integrate core information such as service name, business type, anomaly score, dynamic threshold, predicted failure time, and key anomaly characteristics to form a structured list of abnormal services.

[0073] Step S5: Perform root cause analysis on each abnormal service in the abnormal service list according to the call chain topology, and generate at least one root cause alarm message based on the business domain relationship aggregation.

[0074] Specifically, firstly, based on the call chain topology, the upstream and downstream dependencies of each service in the abnormal service list are analyzed. Root cause analysis is then performed based on the real-time anomaly score differences among the services. If a service's anomaly score is higher than all downstream services and the score difference reaches a preset standard, and this service has no abnormal parent service or its parent service is not in the anomaly list, then this service is determined to be the root cause service, and the anomalies of downstream services are considered to be caused by the root cause service. Subsequently, alarm information is aggregated based on preset business domain relationships. Business domains are divided according to core business scenarios, and each business domain includes core services and corresponding downstream dependent services, stored through a mapping table and supporting manual adjustment. During the aggregation process, independent alarms of downstream services are discarded, and only the alarm information of the root cause service is retained. Supplementary annotations are added, including the service scope of direct and indirect impact, the current scale of affected users, etc., ultimately generating at least one root cause alarm message. This message includes key information such as the business domain identifier, root cause service details, anomaly characteristic description, impact scope description, and business impact degree.

[0075] Step S6: Output the root cause alarm information to the operation and maintenance platform.

[0076] Specifically, root cause alarm information, after being aggregated and processed by the business domain, is output to the operations and maintenance platform according to a preset method. This enables real-time push and historical retention of alarm information, while also providing supporting root cause location information to help operations and maintenance personnel respond quickly and handle faults. In the real-time push phase, root cause alarm information is synchronized to the designated operations and maintenance platform and instant messaging tools. The alarm information clearly indicates the alarm priority and includes core content such as the business domain identifier, root cause service name, anomaly score, predicted failure time, direct impact service scope, indirect impact service scope, and the current scale of affected users. Priority is highlighted using corresponding visual identifiers to facilitate quick identification of critical alarms by operations and maintenance personnel. In the historical storage phase, root cause alarm information is categorized and stored in a relational database according to business domain, priority, and time dimensions, supporting subsequent precise queries and tracing based on these dimensions. In addition, the output also includes a root cause analysis report, which contains a detailed description of the anomaly characteristics (such as response time trends, error rate fluctuations, etc.), a visual anomaly propagation path diagram built based on the call chain topology (with anomaly nodes marked in a prominent manner), and targeted remediation suggestions generated based on historical fault case matching. This allows operations and maintenance personnel to obtain complete information needed for fault handling without cross-system queries, providing comprehensive support for quickly developing and implementing remediation plans.

[0077] Furthermore, considering that real-time anomaly detection allows for accurate prediction of fault occurrence points, providing maintenance personnel with sufficient repair time to improve fault prevention efficiency, this application also includes:

[0078] ①If the real-time anomaly score exceeds the anomaly detection dynamic threshold, the predicted failure time of the service is predicted by combining the preset anomaly score upper limit and the time step coefficient.

[0079] ② The calculated predicted failure time is added to the corresponding service entry in the abnormal service list and finally included in the root cause alarm information.

[0080] Specifically, if a service's real-time anomaly score exceeds the corresponding dynamic threshold for anomaly detection, it is determined that the service exhibits a clear anomaly trend. At this point, the predicted failure time of the service is calculated by combining a preset upper limit for the anomaly score and a time step coefficient. The upper limit for the anomaly score is a pre-defined peak score representing a completely abnormal service state. The time step coefficient is a fixed time parameter determined based on statistical analysis of historical anomaly cases, used to quantify the correlation between changes in the anomaly score and the failure time. Specifically, by using the proportional relationships between the difference between the real-time anomaly score and the dynamic threshold for anomaly detection, and the difference between the upper limit for anomaly score and the real-time anomaly score, combined with the time step coefficient, accurate predictions of the failure time are achieved. The closer the real-time anomaly score is to the upper limit for anomaly score, the faster the service is deteriorating, and the shorter the interval between the predicted failure time and the current time, ensuring that operations personnel can determine the urgency of repair based on the prediction results.

[0081] The calculated predicted failure time is integrated with information such as the service name, business type, real-time anomaly score, dynamic anomaly detection threshold, and key anomaly characteristics of the corresponding service, and added to the corresponding entry for that service in the anomaly service list, forming complete anomaly service information containing the predicted failure time. This predicted failure time will ultimately be synchronously included in the root cause alarm information, presented together with the root cause service identifier, impact scope, anomaly characteristic details, alarm priority, etc., allowing operations and maintenance personnel to intuitively obtain the specific time when the failure may occur upon receiving the alarm. Combined with their own work arrangements and the complexity of the repair process, they can rationally plan the repair steps and time allocation, further improving the pertinence and timeliness of fault handling, and minimizing the loss to the business after the failure actually occurs.

[0082] As can be seen from the above technical solutions, the intelligent alarm method and related equipment for microservice architecture provided in this application achieve accuracy and efficiency in microservice alarms through a full-process technical design encompassing data acquisition and processing, feature engineering, intelligent detection, dynamic threshold filtering, and root cause aggregation. This method collects Span data from the service call chain in the microservice architecture in real time, preprocesses it, and stores it in a time-series database, providing a comprehensive and high-quality data foundation for subsequent analysis. This ensures the integrity and timeliness of the data required for anomaly detection, enabling a comprehensive understanding of the service's operational status.

[0083] By periodically extracting time-series features, statistical features, and inter-service correlation features to construct feature vectors, the system can characterize service operation patterns from multiple dimensions, providing rich evidence for anomaly identification. Combined with an anomaly detection model trained based on the isolated forest algorithm, it can deeply mine anomaly patterns in the data, outputting accurate real-time anomaly scores for each service, and achieving sensitive capture of service anomalies. By introducing dynamic thresholds calculated based on the mean and standard deviation of anomaly score distributions within historical normal service time windows, the system can flexibly adapt to the operational characteristics of services in different business cycles, effectively avoiding the insufficient adaptability of fixed thresholds. Combined with the anomaly service list generated by real-time anomaly scores, the accuracy of anomaly judgment is significantly improved. By calling the chain topology to conduct root cause analysis and aggregating alarm information based on business domain relationships, scattered anomaly prompts can be transformed into root cause alarms focusing on core issues, simplifying the alarm information hierarchy. Combined with accurate output to the operations and maintenance platform, this provides operations and maintenance personnel with clear fault location evidence, significantly improving fault handling efficiency. The overall solution, through the deep integration of data processing, intelligent algorithms, and business logic, comprehensively improves the timeliness, accuracy, and practicality of microservice alarms, providing strong support for the stable operation of microservice systems.

[0084] In some embodiments of this application, the process of step S5, performing root cause analysis on each abnormal service in the abnormal service list according to the call chain topology, and generating at least one root cause alarm message based on business domain relationship aggregation is described.

[0085] The process of performing root cause analysis on each abnormal service in the abnormal service list based on the call chain topology may specifically include:

[0086] ① Construct an exception service call graph based on the parent-child relationship of the call chain in the call chain topology;

[0087] ② Identify the root cause service from the abnormal service call graph using root cause tracing rules, wherein the root cause tracing rules include:

[0088] If the anomaly score of the first service is higher than the preset anomaly score of all its downstream dependent services, then the first service is determined to be a candidate root cause service.

[0089] And / or,

[0090] If the second service does not have a parent service in the list of abnormal services, then the second service is determined to be a candidate root cause service.

[0091] Specifically, an abnormal service call graph is first constructed based on the parent-child call relationships of services in the call chain topology. These parent-child call relationships are clearly defined by the parent and child service identifiers in the call chain data, accurately reflecting the upstream and downstream dependency logic between services. During construction, each abnormal service in the abnormal service list is treated as an independent node. Based on the actual call flow of each service, directed edges are used to connect abnormal service nodes with direct upstream and downstream relationships, forming a complete abnormal service call graph. This graph visually presents the dependency paths between abnormal services, clearly showing the possible propagation directions of the anomaly, providing visual relational support for subsequent root cause tracing, and avoiding misjudgments of the root cause caused by isolated analysis of a single abnormal service.

[0092] Subsequently, the preset root cause tracing rules are applied to identify candidate root cause services from the abnormal service call graph. The root cause tracing rules can be applied individually or in combination to improve the accuracy of identification.

[0093] The first rule is: if the real-time anomaly score of a certain service (i.e., the first service) is higher than the anomaly scores of all its downstream dependent services, and the difference between the scores reaches the preset standard, it indicates that the anomaly degree of the service is significantly higher than that of the downstream related services, and the anomaly state of the downstream services is more likely to be caused by the anomaly propagation of the service. Therefore, the first service is determined to be the candidate root cause service.

[0094] The second rule states: If the parent service of a certain service (i.e., the second service) does not appear in the list of abnormal services, meaning its parent service is operating normally or has not met the abnormality criteria, it indicates that the abnormality of this service is not caused by the fluctuations of the upstream abnormal service, but rather it is more likely to be the origin of the abnormality itself. Therefore, this second service is determined to be a candidate root cause service. Through the flexible application of the above root cause tracing rules, candidate root cause services can be accurately screened from complex abnormal service call relationships, laying the foundation for subsequently confirming the final root cause by combining factors such as service importance and the scope of business impact.

[0095] One possible approach is to further implement a final root cause service confirmation process after filtering candidate root cause services using root cause tracing rules, to ensure the uniqueness and accuracy of root cause identification, as follows:

[0096] First, all candidate root cause services are sorted in descending order of their real-time anomaly scores. Higher anomaly scores indicate a more significant degree of anomaly and a higher probability of the service being the source of the anomaly. This sorting process initially identifies services with the most potential root cause attributes. Then, a secondary verification is performed using preset business scenario priority weights. These priorities are based on the core nature of the business domain to which the service belongs and the service's crucial role in the business process. For example, candidate root cause services in core business domains such as order placement and payment have higher priority than non-core business domains such as logs and monitoring. Services that directly impact the transaction loop, such as order services and payment services, have higher priority than auxiliary services.

[0097] Based on this, verify the anomaly propagation coverage of each candidate root cause service: trace the downstream dependency links of the candidate root cause service through the anomaly service call graph to confirm whether its anomaly can explain the triggering cause of the anomalies of all other anomalies, that is, determine whether the anomaly characteristics of other anomalies are consistent with the anomaly propagation logic of the candidate root cause service (e.g., the downstream service call timeout is caused by the response timeout of the candidate root cause service). If there are multiple candidate root cause services, the service with the widest anomaly propagation coverage and the best position in both anomaly score ranking and business scenario priority should be selected as the final root cause service; if the anomaly score of a candidate root cause service is not the highest, but its business scenario is a core scenario and its anomaly propagation can cover all other anomalies, then it should be determined as the final root cause service based on the business impact priority, to ensure that the root cause positioning conforms to the anomaly propagation rules at the technical level and fits the core requirements of business operation and maintenance, and avoids root cause misjudgment due to a single dimension.

[0098] The process of generating root cause alarm information based on business domain relationships can specifically include:

[0099] ① Determine the business domain to which each of the candidate root cause services belongs;

[0100] ② Aggregate multiple candidate root cause services belonging to the same business domain into a root cause alarm unit, and take the service with the highest real-time anomaly score in each root cause alarm unit as the final root cause service;

[0101] ③ Generate root cause alarm information based on the final root cause service of each root cause alarm unit and the associated services of the final root cause service in its business domain.

[0102] Specifically, the business domain to which each candidate root cause service belongs is first determined. These business domains are pre-divided based on core business scenarios. Each business domain contains core services and corresponding downstream dependent services. The division rules and service affiliation relationships are stored and managed through a business domain-service mapping table, which can be manually adjusted and optimized according to actual business scenarios. When determining the business domain affiliation of a candidate root cause service, a preliminary matching is first performed based on the mapping table. Then, the parent-child service identifiers in the call chain data are used to verify whether the service dependency relationship is consistent with the business domain definition. If there are special scenarios where the service dependency relationship does not match the pre-divided business domain, the affiliation is calibrated after manual confirmation, ensuring that each candidate root cause service is accurately assigned to its corresponding business domain.

[0103] Multiple candidate root cause services belonging to the same business domain are aggregated to form a single root cause alarm unit. During the aggregation process, the real-time anomaly score of the candidate root cause service is used as the core criterion. The real-time anomaly score directly reflects the degree of anomaly of the service. The higher the score, the greater the probability that the service is the source of the anomaly. Therefore, the candidate root cause service with the highest real-time anomaly score in each root cause alarm unit is determined as the final root cause service of that business domain. This ensures the uniqueness and accuracy of root cause location and avoids confusion for operations and maintenance personnel caused by multiple root cause identifiers within the same business domain.

[0104] Based on the ultimate root cause service of each root cause alarm unit, root cause alarm information is generated by combining the related services of the ultimate root cause service within its business domain. The related services include the direct downstream dependent services of the ultimate root cause service and the indirectly related services affected by the anomaly propagation. When generating alarm information, firstly, the independent alarm records of related services are discarded, retaining only the core anomaly information of the ultimate root cause service, while supplementing the impact scope description of the related services and clarifying the list of directly and indirectly affected services. Secondly, core data such as the anomaly score, predicted failure time, and key anomaly characteristics (such as response time trends and error rate fluctuations) of the ultimate root cause service are integrated. Finally, the actual impact of the anomaly on the business (such as the scale of affected users and the business scenarios involved) is statistically analyzed and labeled, forming a complete and comprehensive root cause alarm information system. This allows operations and maintenance personnel to intuitively grasp the source of the anomaly, the scope of impact, and the business loss, and to quickly formulate a repair plan without cross-system queries.

[0105] In some embodiments of this application, the process of extracting multidimensional features from the time-series database to construct feature vectors in step S2 is described, which may specifically include:

[0106] ① Query the response time series within the first preset time window from the time series database, and calculate the slope of the time series through linear regression as the first time series feature reflecting the trend of response time change;

[0107] ② Query the error rate sequence within the second preset time window from the time series database, and calculate the error rate slope through linear regression as a second time series feature reflecting the trend of error rate change;

[0108] ③ Query all service call records within the most recent unit time period from the time-series database, calculate the P-quantile of the response time and the proportion of erroneous requests to the total number of requests, as statistical features reflecting the current state of the service;

[0109] ④ Query the average response time of the parent service of the current service in the time series database within the past unit time, and calculate the ratio of the average response time to the average response time of the current service as the first service association feature;

[0110] ⑤ Query the error rate of all direct downstream services of the current service in the time series database within the nearest unit time, and take the maximum error rate as the second service association feature;

[0111] ⑥ The first time series feature, the second time series feature, the statistical feature, the first service association feature, and the second service association feature are standardized and concatenated in a preset order to form a feature vector.

[0112] Specifically, the first step is to extract the first time series feature: query the response time series data of the current service within a first preset time window from the time series database. This first preset time window is a fixed duration pre-configured based on business scenario requirements, used to capture short-term trends in response time. The response time series is then fitted using a linear regression algorithm to obtain the time series slope, which is used as the first time series feature. This feature quantifies the rate and direction of response time change over time. A positive slope indicates an upward trend in response time, effectively capturing early signs of slow service performance deterioration and avoiding overlooking trend anomalies by focusing only on single-point response times.

[0113] Subsequently, a second time-series feature is extracted: error rate sequence data of the current service within a second preset time window is queried from the time-series database. The second preset time window can be independently configured according to the fluctuation characteristics of the error rate indicator, forming a differentiated time dimension coverage with the first preset time window. Similarly, a linear regression algorithm is used to calculate the error rate sequence, obtaining the error rate slope as the second time-series feature. This feature can accurately depict the changing trend of the error rate, promptly identify the potential risk of a gradually increasing error rate, and provide multi-dimensional time trend support for anomaly prediction.

[0114] Next, statistical features are extracted: All service call records for the current service within the most recent unit of time are retrieved from the time-series database. Based on these call records, two core statistical indicators are calculated: first, the P-quantile of the response time, which effectively eliminates the interference of extreme outliers and more objectively reflects the response time level of most normal service calls; second, the proportion of erroneous requests to the total number of requests (i.e., the error rate), which directly reflects the frequency of abnormal requests occurring in the current service. These two indicators are integrated as statistical features to comprehensively reflect the current operational status of the service, providing real-time data support for anomaly detection.

[0115] Next, service association features are extracted, including a first service association feature and a second service association feature. For the first service association feature, the average response time of the parent service of the current service in the recent unit time is queried from the time series database. The ratio of this average response time to the average response time of the current service in the recent unit time is calculated. This ratio can quantify the relationship between the response times of the parent service and the current service. If the ratio is abnormally high, it may indicate that the performance fluctuation of the parent service has affected the current service, providing a basis for cross-service anomaly propagation analysis. For the second service association feature, the error rate data of all direct downstream services of the current service in the recent unit time is queried, and the maximum error rate is selected as the feature. This maximum value can highlight the most serious abnormal state in the downstream service, avoiding the omission of anomaly feedback of individual key downstream services due to the overall low error rate of downstream services, and achieving comprehensive coverage of the impact of inter-service dependencies.

[0116] Finally, feature vectors are constructed: the extracted first time series features, second time series features, statistical features, first service association features, and second service association features are standardized to convert each feature value to a uniform numerical range, ensuring balanced weights for features of different dimensions and avoiding the impact of differences in units on the accuracy of subsequent model calculations; the standardized features are then sequentially concatenated according to a preset feature sorting rule (such as the order of time series features, statistical features, and service association features) to form a feature vector with a fixed structure and uniform dimensions, providing standardized data support for the input of the anomaly detection model and ensuring that the model can stably and accurately learn the normal operation mode and anomaly feature patterns of services.

[0117] The following describes a microservice architecture intelligent alarm device provided in the embodiments of this application. The microservice architecture intelligent alarm device described below and the microservice architecture intelligent alarm method described above can be referred to and correspond to each other.

[0118] See Figure 2 , Figure 2 This is a schematic diagram of a microservice architecture intelligent alarm device disclosed in an embodiment of this application.

[0119] like Figure 2 As shown, the intelligent alarm device for a microservice architecture may include:

[0120] Data acquisition unit 110 is used to collect Span data of service call chain in microservice architecture, and store it in time series database after preprocessing;

[0121] The feature construction unit 120 is used to periodically extract multi-dimensional features from the time-series database to construct a feature vector. The multi-dimensional features include time-series features, statistical features, and inter-service correlation features.

[0122] Anomaly scoring unit 130 is used to input the feature vector into an anomaly detection model trained based on the isolated forest algorithm and output the real-time anomaly score for each service.

[0123] An anomaly detection unit 140 is used to generate an anomaly service list based on the real-time anomaly score and anomaly detection dynamic threshold of each service, wherein the anomaly detection dynamic threshold is calculated based on the mean and standard deviation of the anomaly score distribution of each service within a historical normal time window.

[0124] The root cause alarm unit 150 is used to perform root cause analysis on each abnormal service in the abnormal service list according to the call chain topology, and generate at least one root cause alarm message based on the aggregation of business domain relationships.

[0125] The alarm output unit 160 is used to output the root cause alarm information to the operation and maintenance platform.

[0126] As can be seen from the above technical solutions, the intelligent alarm method and related equipment for microservice architecture provided in this application achieve accuracy and efficiency in microservice alarms through a full-process technical design encompassing data acquisition and processing, feature engineering, intelligent detection, dynamic threshold filtering, and root cause aggregation. This method collects Span data from the service call chain in the microservice architecture in real time, preprocesses it, and stores it in a time-series database, providing a comprehensive and high-quality data foundation for subsequent analysis. This ensures the integrity and timeliness of the data required for anomaly detection, enabling a comprehensive understanding of the service's operational status.

[0127] By periodically extracting time-series features, statistical features, and inter-service correlation features to construct feature vectors, the system can characterize service operation patterns from multiple dimensions, providing rich evidence for anomaly identification. Combined with an anomaly detection model trained based on the isolated forest algorithm, it can deeply mine anomaly patterns in the data, outputting accurate real-time anomaly scores for each service, and achieving sensitive capture of service anomalies. By introducing dynamic thresholds calculated based on the mean and standard deviation of anomaly score distributions within historical normal service time windows, the system can flexibly adapt to the operational characteristics of services in different business cycles, effectively avoiding the insufficient adaptability of fixed thresholds. Combined with the anomaly service list generated by real-time anomaly scores, the accuracy of anomaly judgment is significantly improved. By calling the chain topology to conduct root cause analysis and aggregating alarm information based on business domain relationships, scattered anomaly prompts can be transformed into root cause alarms focusing on core issues, simplifying the alarm information hierarchy. Combined with accurate output to the operations and maintenance platform, this provides operations and maintenance personnel with clear fault location evidence, significantly improving fault handling efficiency. The overall solution, through the deep integration of data processing, intelligent algorithms, and business logic, comprehensively improves the timeliness, accuracy, and practicality of microservice alarms, providing strong support for the stable operation of microservice systems.

[0128] Optionally, the step of performing root cause analysis on each abnormal service in the abnormal service list based on the call chain topology includes:

[0129] Construct an exception service call graph based on the parent-child relationship of the call chain in the call chain topology;

[0130] The root cause tracing rules are used to identify the root cause service from the abnormal service call graph. These root cause tracing rules include:

[0131] If the anomaly score of the first service is higher than the preset anomaly score of all its downstream dependent services, then the first service is determined to be a candidate root cause service.

[0132] And / or,

[0133] If the second service does not have a parent service in the list of abnormal services, then the second service is determined to be a candidate root cause service.

[0134] Optionally, the process of generating root cause alarm information based on business domain relationships includes:

[0135] Determine the business domain to which each of the candidate root cause services belongs;

[0136] Multiple candidate root cause services belonging to the same business domain are aggregated into a root cause alarm unit, and the service with the highest real-time anomaly score in each root cause alarm unit is taken as the final root cause service.

[0137] Root cause alarm information is generated based on the final root cause service of each root cause alarm unit and the associated services of the final root cause service within its business domain.

[0138] Optionally, extracting multidimensional features from the time-series database to construct a feature vector includes:

[0139] The response time series within the first preset time window is queried from the time series database, and the slope of the time series is calculated by linear regression as the first time series feature reflecting the trend of response time change.

[0140] The error rate sequence within the second preset time window is queried from the time series database, and the error rate slope is calculated by linear regression as a second time series feature reflecting the trend of error rate change.

[0141] The time-series database is used to query all service call records within the most recent unit time period, and the P-quantile of the response time and the proportion of erroneous requests to the total number of requests are calculated as statistical features reflecting the current state of the service.

[0142] The average response time of the parent service of the current service within the past unit time is queried from the time series database, and the ratio of the average response time to the average response time of the current service is calculated as the first service association feature.

[0143] The error rate of all direct downstream services of the current service within a unit time period is queried from the time series database, and the maximum error rate is taken as the second service association feature.

[0144] The first time series feature, the second time series feature, the statistical feature, the first service association feature, and the second service association feature are standardized and then concatenated in a preset order to form a feature vector.

[0145] Optionally, the training process of the anomaly detection model includes:

[0146] Obtain the multidimensional feature vectors of each service during the historical normal period to form an unlabeled training sample set;

[0147] With the goal of fitting the distribution of normal business data in the training sample set, the isolated forest algorithm is used to train the training sample set until the model converges;

[0148] The isolated forest algorithm includes constructing a forest composed of multiple isolated trees, and when constructing each isolated tree, randomly selecting a subset of features from all features for node splitting.

[0149] Optional, also includes:

[0150] If the real-time anomaly score exceeds the anomaly detection dynamic threshold, the predicted failure time of the service is predicted by combining the preset anomaly score upper limit and the time step coefficient.

[0151] The calculated predicted failure time is added to the corresponding service entry in the abnormal service list and ultimately included in the root cause alarm information.

[0152] The intelligent alarm device for microservice architecture provided in this application embodiment can be applied to intelligent alarm devices for microservice architecture. Figure 3 The hardware structure block diagram of the intelligent alarm device with a microservice architecture is shown below. Figure 3 The hardware structure of a microservice architecture intelligent alarm device may include: at least one processor 1, at least one communication interface 2, at least one memory 3, and at least one communication bus 4;

[0153] In this embodiment of the application, the number of processor 1, communication interface 2, memory 3, and communication bus 4 is at least one, and processor 1, communication interface 2, and memory 3 communicate with each other through communication bus 4;

[0154] Processor 1 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention.

[0155] Memory 3 may include high-speed RAM, and may also include non-volatile memory, such as at least one disk storage device;

[0156] The memory stores a program, which the processor can call. The program is used for:

[0157] Collect Span data from the service call chain in the microservice architecture, preprocess it, and store it in a time-series database;

[0158] Periodically extract multi-dimensional features from the time-series database to construct a feature vector, wherein the multi-dimensional features include time-series features, statistical features, and inter-service correlation features;

[0159] The feature vectors are input into an anomaly detection model trained based on the isolated forest algorithm, and the real-time anomaly scores of each service are output.

[0160] Based on the real-time anomaly scores and dynamic anomaly detection thresholds of each service, an anomaly service list is generated, wherein the dynamic anomaly detection thresholds are calculated based on the mean and standard deviation of the anomaly score distribution of each service within a historical normal time window.

[0161] Root cause analysis is performed on each abnormal service in the abnormal service list based on the call chain topology, and at least one root cause alarm message is generated based on the aggregation of business domain relationships.

[0162] The root cause alarm information is output to the operation and maintenance platform.

[0163] Optionally, the refined and extended functions of the program can be referred to the above description.

[0164] This application embodiment also provides a readable storage medium that can store a program suitable for execution by a processor, the program being used for:

[0165] Collect Span data from the service call chain in the microservice architecture, preprocess it, and store it in a time-series database;

[0166] Periodically extract multi-dimensional features from the time-series database to construct a feature vector, wherein the multi-dimensional features include time-series features, statistical features, and inter-service correlation features;

[0167] The feature vectors are input into an anomaly detection model trained based on the isolated forest algorithm, and the real-time anomaly scores of each service are output.

[0168] Based on the real-time anomaly scores and dynamic anomaly detection thresholds of each service, an anomaly service list is generated, wherein the dynamic anomaly detection thresholds are calculated based on the mean and standard deviation of the anomaly score distribution of each service within a historical normal time window.

[0169] Root cause analysis is performed on each abnormal service in the abnormal service list based on the call chain topology, and at least one root cause alarm message is generated based on the aggregation of business domain relationships.

[0170] The root cause alarm information is output to the operation and maintenance platform.

[0171] Optionally, the refined and extended functions of the program can be referred to the above description.

[0172] This application also provides a computer program product, including a computer program, wherein the computer program is executed by a processor using the following method:

[0173] Collect Span data from the service call chain in the microservice architecture, preprocess it, and store it in a time-series database;

[0174] Periodically extract multi-dimensional features from the time-series database to construct a feature vector, wherein the multi-dimensional features include time-series features, statistical features, and inter-service correlation features;

[0175] The feature vectors are input into an anomaly detection model trained based on the isolated forest algorithm, and the real-time anomaly scores of each service are output.

[0176] Based on the real-time anomaly scores and dynamic anomaly detection thresholds of each service, an anomaly service list is generated, wherein the dynamic anomaly detection thresholds are calculated based on the mean and standard deviation of the anomaly score distribution of each service within a historical normal time window.

[0177] Root cause analysis is performed on each abnormal service in the abnormal service list based on the call chain topology, and at least one root cause alarm message is generated based on the aggregation of business domain relationships.

[0178] The root cause alarm information is output to the operation and maintenance platform.

[0179] Optionally, the refined and extended functions of the program can be referred to the above description.

[0180] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0181] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0182] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A micro-service architecture intelligent alarm method, characterized in that, The method comprises: collecting span data of a service call chain in a micro-service architecture, and storing the span data in a time series database after preprocessing; periodically extracting multi-dimensional features from the time series database to construct a feature vector, wherein the multi-dimensional features comprise time series features, statistical features, and inter-service correlation features; inputting the feature vector into an anomaly detection model trained based on an isolation forest algorithm, and outputting real-time anomaly scores of each service; generating an abnormal service list based on the real-time anomaly scores of each service and an anomaly detection dynamic threshold, wherein the anomaly detection dynamic threshold is calculated according to a mean value and a standard deviation of an anomaly score distribution of each service within a historical normal time window; performing root cause analysis on each abnormal service in the abnormal service list according to a call chain topology, and generating at least one root cause alarm information based on business domain relationship aggregation; outputting the root cause alarm information to an operation and maintenance platform.

2. The method of claim 1, wherein, The root cause analysis on each abnormal service in the abnormal service list according to the call chain topology comprises: constructing an abnormal service call graph according to a parent-child relationship of a call chain in the call chain topology; identifying a root cause service from the abnormal service call graph by applying a root cause tracing rule, wherein the root cause tracing rule comprises: if an anomaly score of a first service is higher than a preset value of anomaly scores of all downstream dependent services of the first service, the first service is determined as a candidate root cause service; and / or if a second service does not have a parent service in the abnormal service list, the second service is determined as a candidate root cause service. The process of generating root cause alarm information based on business domain relationship aggregation comprises:

3. The method of claim 2, wherein, determining a business domain to which each candidate root cause service belongs; aggregating multiple candidate root cause services belonging to the same business domain into a root cause alarm unit, and taking a service with the highest real-time anomaly score in each root cause alarm unit as a final root cause service; generating root cause alarm information based on the final root cause service of each root cause alarm unit and associated services of the final root cause service in the business domain. The process of extracting multi-dimensional features from the time series database to construct a feature vector comprises:

4. The method of claim 1, wherein, querying a response time sequence within a first preset time window from the time series database, and calculating a time series slope by linear regression as a first time series feature reflecting a response time trend; querying an error rate sequence within a second preset time window from the time series database, and calculating an error rate slope by linear regression as a second time series feature reflecting an error rate trend; querying all service call records within a unit time from the time series database, and calculating a P quantile of a response time and a proportion of error requests in total requests as statistical features reflecting a current state of a service; querying an average response time of a parent service of a current service within a unit time from the time series database, and calculating a ratio of the average response time to an average response time of the current service as a first service correlation feature; querying error rates of all direct downstream services of the current service within a unit time from the time series database, and taking a maximum error rate as a second service correlation feature; ​ The first time series feature, the second time series feature, the statistical feature, the first service association feature and the second service association feature are standardized and spliced in a preset order to form a feature vector.

5. The method of claim 1, wherein, The training process of the anomaly detection model comprises: obtaining the multi-dimensional feature vectors of each service in the historical normal period to form a training sample set without labels; training the training sample set using an isolation forest algorithm to fit the distribution of normal business data in the training sample set until the model converges; The isolation forest algorithm comprises constructing a forest composed of multiple isolation trees, and when constructing each isolation tree, a feature subset is randomly selected from all features for node splitting.

6. The method of claim 1, wherein, Further comprising: if the real-time anomaly score exceeds the anomaly detection dynamic threshold, a predicted failure time of the service is predicted by combining a preset anomaly score upper limit value and a time step coefficient; the predicted failure time calculated is added to the corresponding service entry in the abnormal service list and finally included in the root cause alarm information.

7. A microservice architecture intelligent alarm device, characterized in that, Comprise: a data acquisition unit configured to acquire Span data of a service call chain in a microservice architecture and store the preprocessed data in a time series database; a feature construction unit configured to periodically extract multi-dimensional features from the time series database to construct a feature vector, wherein the multi-dimensional features comprise time series features, statistical features and service association features; an anomaly score unit configured to input the feature vector into an anomaly detection model trained based on an isolation forest algorithm and output real-time anomaly scores of each service; an anomaly detection unit configured to generate an abnormal service list based on the real-time anomaly scores of each service and an anomaly detection dynamic threshold, wherein the anomaly detection dynamic threshold is calculated according to the mean and standard deviation of the anomaly score distribution of each service in a historical normal time window; a root cause alarm unit configured to perform root cause analysis on each abnormal service in the abnormal service list according to a call chain topology and generate at least one root cause alarm information based on business domain relationships; an alarm output unit configured to output the root cause alarm information to an operation and maintenance platform.

8. A microservice architecture intelligent alarm device, characterized in that, comprise a memory and a processor; the memory is configured to store a program; the processor is configured to execute the program to implement each step of the microservice architecture intelligent alarm method according to any one of claims 1-6.

9. A readable storage medium, having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement each step of the microservice architecture intelligent alarm method according to any one of claims 1-6.

10. A computer program product comprising a computer program, characterized in that, The computer program is executed by the processor to implement each step of the microservice architecture intelligent alarm method according to any one of claims 1-6.

Images