Multi-source network data operation and maintenance system based on micro-service architecture and AI cooperation

Abstract

The invention relates to the field of intelligent operation and maintenance, and discloses a multi-source network data operation and maintenance system based on micro-service architecture and AI collaboration, comprising the steps of collecting multi-source data of a micro-service system, and performing cleaning, format unification and time alignment on the collected data; based on a data result of the data acquisition module, constructing a micro-service call chain and a dependency graph, embedding a real-time performance index and a log feature in each node, and dynamically updating a service relation graph; carrying out real-time anomaly detection on the multi-source data, and judging the alarm effectiveness in combination with a dynamic threshold and an AI alarm confidence self-learning mechanism; the AI conducts reasoning along the call chain anomaly map, causal relationship reasoning is added, and the anomaly propagation influence range is predicted; and feeding back a root cause positioning result and the optimized alarm information to an operation and maintenance system, optimizing an alarm threshold and decision parameters in combination with historical records, and outputting an updated operation and maintenance decision scheme. The method has the advantage of improving the operation stability of the system.

Description

Technical Field

[0001] This invention relates to the field of intelligent operation and maintenance, specifically a multi-source network data operation and maintenance system based on microservice architecture and AI collaboration. Background Technology

[0002] Modern enterprise-level application systems mostly adopt a microservice architecture, consisting of a large number of interdependent services that complete business processes through network calls. However, the call relationships between microservices are complex and multi-layered. When system anomalies occur, they often propagate along the call chain, leading to overall performance degradation or partial business interruption. Current technologies suffer from low fault location efficiency and difficulty in accurately identifying root causes. Traditional methods mainly rely on log analysis, single-service monitoring metrics, or fixed thresholds, but these methods cannot fully utilize the dependencies between services, resulting in long troubleshooting times and a high risk of misjudgments or missed diagnoses. Furthermore, operation and maintenance systems face challenges such as high false alarm rates from multiple sources, static thresholds that are difficult to adapt to business fluctuations, and heterogeneous multi-source data (logs, metrics, and event sequences), making unified intelligent analysis difficult. Therefore, existing technologies in microservice operation and maintenance suffer from low efficiency, poor accuracy, insufficient intelligence, and data processing difficulties. Thus, designing a multi-source network data operation and maintenance system based on microservice architecture and AI collaboration to improve system stability is essential. Summary of the Invention

[0003] To address the shortcomings of existing technologies, this invention provides a multi-source network data operation and maintenance system based on microservice architecture and AI collaboration, which has the advantage of improving system operational stability and solves the problems mentioned in the background technology.

[0004] To achieve the aforementioned goal of improving system operational stability, this invention provides the following technical solution: a multi-source network data operation and maintenance system based on microservice architecture and AI collaboration, comprising:

[0005] Data acquisition module: Collects multi-source data from the microservice system, cleans the collected data, unifies the format and aligns the time, and determines whether the data is complete and usable. After completion, it enters the graph construction module.

[0006] The graph construction module: Based on the data results from the data acquisition module, it constructs a microservice call chain and dependency graph, embeds real-time performance indicators and log features in each node, dynamically updates the service relationship graph, and then enters the anomaly detection module.

[0007] Anomaly detection module: performs real-time anomaly detection on multi-source data and judges the validity of alarms by combining dynamic thresholds and AI alarm confidence self-learning mechanism. If an anomaly is detected, it enters the root cause reasoning module.

[0008] Root Cause Reasoning Module: The AI ​​performs reasoning along the call chain anomaly graph and incorporates causal relationship reasoning to predict the scope of anomaly propagation. After completing the root cause analysis, it enters the operation and maintenance decision module.

[0009] Operation and maintenance decision module: Feeds back the root cause analysis results and optimized alarm information to the operation and maintenance system, and optimizes alarm thresholds and decision parameters in combination with historical records, and outputs updated operation and maintenance decision solutions.

[0010] Preferably, the process for determining whether the data is complete and usable is as follows:

[0011] Perform continuous integrity verification on the collected logs, monitoring metrics, event sequences, and network traffic data, including checking for missing, duplicate, or abnormal data.

[0012] The collected data is formatted and aligned with time series to eliminate time deviations;

[0013] The system determines whether the data meets the requirements for subsequent analysis and map construction by setting integrity scoring thresholds and usability indicators. If the conditions are met, the system proceeds to the map construction module.

[0014] Preferably, the process of constructing the microservice call chain and dependency graph is as follows:

[0015] Extract request relationships, call times, response latency, and error rates between each microservice;

[0016] Map the microservice nodes and their call relationships into a graph structure, construct a preliminary dependency graph, and mark the call frequency and critical path between nodes;

[0017] The graph is subjected to topological analysis to identify service links, loops and potential dependency chains. After completion, the node feature embedding and dynamic update process begins.

[0018] Preferably, the process of dynamically updating the service relationship graph is as follows:

[0019] Add real-time performance metrics to each node in the graph, including CPU utilization, memory usage, response time, and error rate;

[0020] Vectorize the node-related log features and fuse them with performance metrics to form a multi-dimensional feature embedding.

[0021] The graph node features and edge weight information are dynamically updated through a timed or event-triggered mechanism, and then the anomaly detection module is entered.

[0022] Preferably, the real-time anomaly detection process for multi-source data is as follows:

[0023] The performance indicators of each node in the graph are compared with historical reference values ​​in real time to identify abnormal fluctuations;

[0024] By combining log characteristics, event sequences, and network traffic patterns, anomaly scores and alarm levels are calculated.

[0025] The detected abnormal events are classified, and the services and business scopes that may be affected are marked. After completion, the alarm validity judgment module is entered.

[0026] Preferably, the process of determining alarm validity by combining dynamic thresholds and an AI alarm confidence self-learning mechanism is as follows:

[0027] The alarm thresholds are dynamically adjusted based on business traffic fluctuations and historical alarm data.

[0028] AI models are used to calculate alarm confidence, and node characteristics, call chain propagation paths, and historical false alarm data are weighted and analyzed.

[0029] When an alarm is deemed valid, the anomaly information is transmitted to the root cause reasoning module for in-depth analysis.

[0030] Preferably, the AI ​​reasoning process along the call chain anomaly graph is as follows:

[0031] Starting from the affected node, analyze the anomaly propagation path upstream along the call chain;

[0032] A comprehensive analysis of the real-time performance metrics, log characteristics, and historical anomaly patterns of each node is conducted, and the probability of anomaly propagation and the priority of possible root causes are calculated by combining the weight of the call relationship between nodes.

[0033] By using graph traversal algorithms and AI inference methods based on probabilistic graphical models, the set of potential root cause nodes is sorted and filtered, and preliminary root cause analysis results are output.

[0034] Preferably, the process for predicting the impact range of abnormal propagation is as follows:

[0035] Based on the root cause localization results, the possible upstream and downstream propagation paths of the anomaly are analyzed step by step along the call chain to identify the affected nodes and service dependencies.

[0036] Combine real-time node performance metrics, call weights, and historical anomaly propagation data;

[0037] Calculate the probability of anomaly propagation and the potential impact range of each node; output the degree to which each node is affected by the anomaly.

[0038] The preferred process for outputting the updated operation and maintenance decision-making scheme is as follows:

[0039] Based on the degree to which each node is affected by the anomaly, analyze historical alarms, root cause localization, and operation and maintenance results to evaluate the effectiveness of alarm thresholds and policy parameters.

[0040] Utilize online learning and optimization algorithms to dynamically adjust alarm trigger sensitivity, priority ranking, and resource scheduling strategies;

[0041] Generate updated operation and maintenance decision-making solutions and output a comprehensive report that includes root cause nodes, alarm information, recommended actions, and expected business impact.

[0042] Compared with existing technologies, this invention provides a multi-source network data operation and maintenance system based on microservice architecture and AI collaboration, which has the following beneficial effects:

[0043] This invention ensures data integrity and availability through multi-source data collection, cleaning, and time alignment, providing high-quality input for subsequent analysis. By dynamically constructing microservice call chains and dependency graphs and embedding real-time performance metrics, it achieves visualization and continuous monitoring of inter-service relationships, enabling timely detection of potential bottlenecks or anomalies. The real-time anomaly detection module, through a dynamic threshold and AI alarm confidence self-learning mechanism, accurately identifies anomalies and reduces the risk of false positives and false negatives. The root cause reasoning module, combining causal relationship analysis along the call chain, predicts the scope of anomaly propagation, providing early warnings of potentially affected nodes. The operation and maintenance decision module feeds back root cause localization results and optimized alarm information to the operation and maintenance system, and optimizes alarm thresholds and scheduling strategies based on historical records and online learning mechanisms. This improves system response speed, reduces the risk of fault propagation, and optimizes resource utilization efficiency, significantly enhancing the overall stability, reliability, and operational intelligence of the microservice system. Attached Figure Description

[0044] Figure 1 This is a schematic diagram of the structure of the present invention. Detailed Implementation

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

[0046] Example 1: Please refer to Figure 1 As shown in the embodiment of the present invention, a smart feed distribution system for pigsties includes:

[0047] Data acquisition module: Collects multi-source data from the microservice system, cleans the collected data, unifies the format and aligns the time, and determines whether the data is complete and usable. After completion, it enters the graph construction module.

[0048] The process for determining data integrity and usability in the data acquisition module is as follows:

[0049] Perform continuous integrity verification on the collected logs, monitoring metrics, event sequences, and network traffic data, including checking for missing, duplicate, or abnormal data.

[0050] After data collection is completed, continuous integrity verification is performed on logs, monitoring metrics, event sequences, and network traffic data. For log data, timestamps are used to check for skipped or duplicate records. For monitoring metrics, missing and outlier values ​​are compared according to the collection frequency, and interpolation or anomaly marking is used for processing. For event sequences, sequence integrity rules are used to determine whether there are interruptions or abnormal event sequences. For network traffic data, missing packets are detected according to packet timestamps and sequence numbers. Throughout the process, a strategy combining batch processing and streaming processing is adopted to generate integrity reports for various types of data, including missing rate, duplication rate, and anomaly rate, providing basic indicators for subsequent judgment.

[0051] The collected data is formatted and aligned with time series to eliminate time deviations;

[0052] The data that has completed integrity verification is standardized in format, including unified timestamp format, unified data type, field name mapping and unit unification. Time series alignment is performed on multi-source data, data from different sources are resampled based on the minimum sampling interval, missing time points are interpolated to ensure that each data stream is synchronized on the time axis. For high-frequency data such as network traffic and monitoring indicators, window aggregation or moving average methods are used to generate unified sampling points. Time interval mapping is used on event sequences to map discrete events to a unified time axis, forming a standardized time series dataset that can be used for subsequent analysis.

[0053] The data is judged to meet the requirements of subsequent analysis and map construction by setting integrity scoring thresholds and usability indicators. If the conditions are met, the data will enter the map construction module.

[0054] Based on integrity metrics and formatted data, an integrity score is calculated for each batch of data, including a missing percentage score, a duplication rate score, and anomaly rate score. This is further combined with usability metrics, such as data coverage, temporal continuity, and key field integrity, to generate a comprehensive usability index. By comparing this index with a pre-set threshold, if the comprehensive score meets the requirements for subsequent map construction and anomaly analysis, the data batch is marked as usable and the data is transferred to the map construction module. If the threshold is not met, a data supplementation or anomaly marking process is triggered, providing a basis for system decision-making.

[0055] The graph construction module: Based on the data results from the data acquisition module, it constructs a microservice call chain and dependency graph, embeds real-time performance indicators and log features in each node, dynamically updates the service relationship graph, and then enters the anomaly detection module.

[0056] The process of building the microservice call chain and dependency graph in the graph construction module is as follows:

[0057] Extract request relationships, call times, response latency, and error rates between each microservice;

[0058] The system extracts call information between microservices from standardized logs, monitoring metrics, and event sequences transmitted from the data acquisition module. For each call record, it parses the service that initiated the request, the service that was called, the call timestamp, the response time, and the status code or error identifier. It also calculates the latency of each call, the success rate, and the error rate. High-frequency calls and batch requests are aggregated to generate metrics such as the number of calls between each pair of services, the average response latency, and the error rate, which are used for subsequent graph structure construction and critical path analysis.

[0059] Map the microservice nodes and their call relationships into a graph structure, construct a preliminary dependency graph, and mark the call frequency and critical path between nodes;

[0060] Each microservice is treated as a node in a graph. Node attributes include service name, service type, deployment instance, and real-time performance metrics. Service call relationships are mapped as directed edges, with edge attributes including call frequency, average latency, error rate, and critical request identifiers. For multi-instance services, node groups are generated using instance aggregation or hierarchical mapping methods to maintain a controllable number of nodes while retaining detailed call statistics. A preliminary dependency graph is formed, and the call intensity, critical paths, and high-latency edges between nodes are labeled, providing a foundation for topology analysis.

[0061] The graph is subjected to topological analysis to identify service links, loops and potential dependency chains. After completion, the node feature embedding and dynamic update process is carried out.

[0062] The constructed dependency graph is subjected to topological traversal analysis. Depth-first search or breadth-first search methods are used to identify complete service call chains. Loop detection is performed to discover potential service circular dependencies. Call frequency and latency distribution are analyzed, critical links and high-risk dependency chains are marked, and the in-degree, out-degree and intermediate centrality of each node are counted to identify nodes or links that have a significant impact on the system. After the topological analysis is completed, the graph data is prepared for the next step of node feature embedding and dynamic update process.

[0063] The process of dynamically updating the service relationship graph in the graph construction module is as follows:

[0064] Add real-time performance metrics to each node in the graph, including CPU utilization, memory usage, response time, and error rate;

[0065] The microservice monitoring system collects real-time performance data from each node, including CPU utilization, memory usage, request response time, request throughput, and error rate. Each node object has corresponding attribute fields added to the graph structure to store these metrics. The collection period can be set to seconds or minutes, adjusted according to system load and monitoring frequency. For services deployed with multiple instances, the average, maximum, and standard deviation are calculated by aggregating the instances to generate a multi-dimensional performance metric vector for each node. For example, in an e-commerce microservice system, the order service node has a CPU utilization of 75%, memory usage of 1.2GB, an average response time of 120ms, and an error rate of 0.5%. This data is dynamically written to the node attributes for subsequent feature embedding.

[0066] Vectorize the node-related log features and fuse them with performance metrics to form a multi-dimensional feature embedding.

[0067] Key features, such as the frequency of abnormal keywords, request parameter patterns, stack error types, and call stack lengths, are extracted from the log information collected from nodes. These log features are then converted into numerical vectors using text vectorization methods such as TF-IDF and Word2Vec encoding. Subsequently, the performance metric vectors are fused with the log feature vectors to form a multi-dimensional feature embedding for the nodes. For example, in the user authentication microservice, log fragments that frequently show "timeout" errors are vectorized and then fused with metrics such as response time and CPU usage to form a 128-dimensional node embedding vector, which is used for graph neural networks or subsequent anomaly analysis.

[0068] The graph node features and edge weight information are dynamically updated through a timed or event-triggered mechanism, and then the anomaly detection module is entered after completion.

[0069] Establish a timed or event-triggered mechanism to update the graph, for example, triggering an update every 5 seconds or whenever performance metrics exceed a set threshold. After the multi-dimensional feature vectors of nodes are updated, the weights of edges are also adjusted accordingly: edge attribute values ​​are updated based on the latest call frequency, latency, and error rate. Through this mechanism, the dependency graph can reflect changes in the microservice's operational status in real time. For example, when the payment service's call to the inventory service has a latency exceeding 200ms, the corresponding edge weight increases, reflecting a potential performance bottleneck. After updating nodes and edges, the graph can be used by the anomaly detection module for real-time analysis.

[0070] Anomaly detection module: performs real-time anomaly detection on multi-source data and judges the validity of alarms by combining dynamic thresholds and AI alarm confidence self-learning mechanism. If an anomaly is detected, it enters the root cause reasoning module.

[0071] The real-time anomaly detection process for multi-source data in the anomaly detection module is as follows:

[0072] The performance indicators of each node in the graph are compared with historical reference values ​​in real time to identify abnormal fluctuations;

[0073] Multi-dimensional performance metrics of each node in the microservice graph are collected in real time, including CPU utilization, memory usage, request response time, request throughput, and error rate. These real-time metrics are compared with historical reference values, which can be calculated using a sliding time window to determine the average, standard deviation, and quantiles, forming a performance benchmark. For example, for the order service node, the historical average response time is 100ms and the standard deviation is 20ms. When the real-time response time suddenly increases to 180ms, it is identified as an abnormal fluctuation through Z-score or normalized deviation calculation. Anomaly detection algorithms can use threshold detection, time series anomaly detection methods, or deep learning-based autoencoder prediction of residuals.

[0074] By combining log characteristics, event sequences, and network traffic patterns, anomaly scores and alarm levels are calculated.

[0075] Key events and error codes are extracted from logs at each node. Natural language processing or pattern matching is used to convert the text logs into structured feature vectors, such as the frequency of abnormal keywords and stack error patterns. Event sequence analysis detects abnormal sequences by statistically analyzing the frequency, time interval, or sequence pattern of events. Network traffic patterns collect the request rate, number of connections, and traffic distribution of each service and compare them with historical traffic patterns to identify abnormal traffic spikes or connection anomalies. For example, in a payment microservice, the request volume may surge from an average of 500 TPS to 2000 TPS in a short period of time, while a large number of "timeout" errors appear in the logs. Combining network traffic patterns, an anomaly score can be calculated. Performance indicators, log vectors, event sequences, and network traffic features are weighted and fused to obtain a comprehensive anomaly score, and alarm levels are generated according to set rules.

[0076] The detected abnormal events are classified, and the services and business scopes that may be affected are marked. After completion, the alarm validity judgment module is entered.

[0077] Anomalies are categorized based on anomaly scores and feature combinations, including performance bottlenecks, service errors, and network anomalies. Service dependency graphs are used to analyze upstream and downstream nodes affected by the anomalies, marking potentially affected services and business scopes. For example, when the inventory service is affected, call chain analysis marks the order processing and payment services as potentially indirectly affected, while also indicating the scope of business impact, such as order creation delays and payment failure risks. Anomaly event information is encapsulated into structured data objects, including anomaly type, triggering node, related metrics, and business scope, for use by the subsequent alarm validity assessment module.

[0078] The process of determining the validity of an alarm in the anomaly detection module, which combines dynamic thresholds with an AI alarm confidence self-learning mechanism, is as follows:

[0079] The alarm thresholds are dynamically adjusted based on business traffic fluctuations and historical alarm data.

[0080] Based on business traffic fluctuations and historical alarm data, the performance indicators of microservice nodes are first statistically analyzed over time to calculate the moving average, standard deviation, and peak distribution. These statistical characteristics are then used to dynamically adjust the thresholds. For example, during peak traffic periods, the upper limit of latency is allowed to be appropriately increased to avoid false alarms; during low traffic periods, the threshold is reduced to improve anomaly sensitivity. In practice, a sliding window can be used to calculate the average and standard deviation of the most recent 1 hour, 24 hours, or 7 days, and the thresholds are adjusted by weighting them according to the business time period to form a dynamic threshold curve.

[0081] AI models are used to calculate alarm confidence, and node characteristics, call chain propagation paths, and historical false alarm data are weighted and analyzed.

[0082] Each alarm event is used as input to construct a feature vector, including real-time node performance metrics, call chain propagation path, service dependencies, historical false alarm rate, and historical anomaly triggering conditions. An AI model calculates the confidence level of each alarm and outputs a probability value between 0 and 1. This model continuously updates the weight parameters through online learning to adapt to changes in microservice topology and traffic patterns. For example, for an error rate alarm of a payment service, the model will combine the service's historical false alarm count, the anomaly propagation probability of calling the upstream gateway, and the current traffic load to calculate the confidence level.

[0083] When an alarm is deemed valid, the anomaly information is transmitted to the root cause reasoning module for in-depth analysis.

[0084] The calculated alarm confidence score is compared with a set validity threshold. If the confidence score is higher than the threshold, the alarm is considered valid; otherwise, it is marked as a potential false alarm. For valid alarms, the system transmits the anomaly information, alarm type, affected nodes, and propagation path to the root cause reasoning module. During transmission, the information is encapsulated in a structured format, including timestamps, node identifiers, performance metric snapshots, and call chain topology data, ensuring that subsequent root cause analysis can directly access this data for deep causal reasoning and impact range prediction.

[0085] Root Cause Reasoning Module: The AI ​​performs reasoning along the call chain anomaly graph and incorporates causal relationship reasoning to predict the scope of anomaly propagation. After completing the root cause analysis, it enters the operation and maintenance decision module.

[0086] The reasoning process of AI along the call chain anomaly graph in the root cause reasoning module is as follows:

[0087] Starting from the affected node, analyze the anomaly propagation path upstream along the call chain;

[0088] Starting from the affected node where the anomaly is detected, the system traces each request path upstream along the call chain. The call chain information is collected through the microservice tracing system, including the call origin, target service, call timestamp, response status code, and latency. The call relationship of each node is represented by a graph structure. The edge weights between nodes are assigned based on call frequency, latency, and historical anomaly propagation. A list of potential anomaly propagation paths is generated through a graph traversal algorithm, providing basic path information for subsequent probability calculations.

[0089] A comprehensive analysis of the real-time performance metrics, log characteristics, and historical anomaly patterns of each node is conducted, and the probability of anomaly propagation and the priority of possible root causes are calculated by combining the weight of the call relationship between nodes.

[0090] The real-time performance metrics and log features collected from each node in the path are vectorized. Historical anomaly patterns are generated into anomaly templates through time series analysis or clustering methods to identify whether nodes exhibit similar abnormal behavior. The anomaly propagation contribution of each node is weighted by the call relationship weight between nodes. For example, in the payment transaction service, if the upstream gateway node has a high response anomaly rate and frequent calls, its propagation probability weight is higher than that of low-frequency call nodes.

[0091] Using graph traversal algorithms and AI inference methods based on probabilistic graphical models, the set of potential root cause nodes is sorted and filtered, and preliminary root cause analysis results are output.

[0092] The node feature vectors, call chain path weights, and historical anomaly templates are input into the AI ​​inference engine based on a probabilistic graphical model. The engine calculates the conditional probability of anomalies occurring at each node, evaluates the priority of potential root cause nodes, and outputs the anomaly propagation probability distribution of the nodes. Through sorting and filtering, a preliminary root cause set is formed, including the key nodes most likely to cause link anomalies and potentially affected upstream and downstream nodes. The output results record node identifiers, anomaly probability values, root cause priorities, and propagation path information in a structured format for use in the next step of causal relationship inference and impact range prediction.

[0093] The process of predicting the scope of anomaly propagation in the root cause reasoning module is as follows:

[0094] Based on the root cause localization results, the possible upstream and downstream propagation paths of the anomaly are analyzed step by step along the call chain to identify the affected nodes and service dependencies.

[0095] Based on the root cause localization results from the previous step, the system uses the anomaly source node as the starting point and traces possible upstream and downstream service nodes step by step along the call chain. Call chain data is collected through a microservice tracing platform, including service call order, call latency, request success rate, and error code distribution. The edge weight of each call chain is assigned a value based on call frequency, dependency strength, and historical anomaly propagation, in order to construct a complete potential anomaly propagation path graph and provide a structural foundation for calculating the scope of impact.

[0096] Combine real-time node performance metrics, call weights, and historical anomaly propagation data;

[0097] The real-time performance metrics collected at each node in the path are standardized and compared with the historical anomaly propagation data of the nodes. The propagation contribution factor of each node is formed by combining the call weight between nodes with the historical anomaly propagation pattern. For example, for the order processing service, if the upstream inventory service frequently causes response delays in historical anomalies, the propagation weight of the inventory node will be significantly higher than that of the low-dependency node.

[0098] Calculate the probability of anomaly propagation and the potential impact range for each node; output the degree to which each node is affected by the anomaly;

[0099] The real-time performance metrics, propagation weights, and historical anomaly templates of each node are input into the probabilistic graphical model to calculate the probability of each node being affected under the current anomaly. Combined with the topological relationship of the call chain path, the set of potentially affected nodes and their business correlation are calculated. The calculation results are organized into structured data, including the identifier of each node, the anomaly propagation probability, the potential impact range, and the business level of the affected services. The data can be used in subsequent operation and maintenance decision-making modules to realize alarm priority ranking, resource scheduling optimization, and service recovery strategy generation. The output format can be JSON or graph database node attributes, which facilitates automated analysis and visualization.

[0100] Operation and maintenance decision module: Feeds back the root cause analysis results and optimized alarm information to the operation and maintenance system, and optimizes alarm thresholds and decision parameters in combination with historical records, and outputs updated operation and maintenance decision solutions;

[0101] The process of outputting the updated operation and maintenance decision plan in the operation and maintenance decision module is as follows:

[0102] Based on the degree to which each node is affected by the anomaly, analyze historical alarms, root cause localization, and operation and maintenance results to evaluate the effectiveness of alarm thresholds and policy parameters.

[0103] The predicted impact of each node's anomalies is correlated with historical alarm data, root cause analysis results, and actual operation and maintenance records. For each alarm record, the triggering conditions, alarm level, false alarm / missed alarm situation, and corresponding operation results are extracted. The alarm hit rate, operation success rate, and recovery time distribution are calculated using statistical methods to quantify the execution effect of the current threshold and strategy parameters on historical data. For example, for a database service node, if the restart operation triggered by the past three high CPU alarms only resolves one performance anomaly, the threshold or triggering strategy needs to be adjusted.

[0104] Utilize online learning and optimization algorithms to dynamically adjust alarm trigger sensitivity, priority ranking, and resource scheduling strategies;

[0105] The results of the first step analysis are input into the online learning module, which uses gradient descent or reinforcement learning algorithms to dynamically update the alarm trigger sensitivity and priority ranking. At the same time, resource scheduling strategies are adjusted in combination with inter-node dependencies. The algorithm calculates the optimal combination of operations based on the anomaly propagation probability, node business level, and historical operation feedback. For example, in a microservice cluster, CPU and memory quotas are adjusted or standby instances are started to reduce potential business impact. The dynamic adjustment process includes real-time weight updates, historical data playback, and simulation verification to ensure that the strategy parameters are adapted to the current system state.

[0106] Generate updated operation and maintenance decision-making solutions and output a comprehensive report that includes root cause nodes, alarm information, recommended actions, and expected business impact;

[0107] The integrated and adjusted alarm thresholds, operation priorities, and resource scheduling strategies form a structured operation and maintenance decision-making scheme. The scheme output includes each potential root cause node, associated alarm information, recommended operation steps, and the expected scope and degree of impact on the business. The data can be stored as JSON or graph database node attributes, supports automated operation and maintenance platform calls and visualization interface display, and generates corresponding operation instructions for automatic execution by the operation and maintenance system or manual review.

[0108] 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 process, method, article, or apparatus.

[0109] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A multi-source network data operation and maintenance system based on microservice architecture and AI collaboration, characterized in that, include: Data acquisition module: Collects multi-source data from the microservice system, cleans the collected data, unifies the format and aligns the time, and determines whether the data is complete and usable. After completion, it enters the graph construction module. The graph construction module: Based on the data results from the data acquisition module, it constructs a microservice call chain and dependency graph, embeds real-time performance indicators and log features in each node, dynamically updates the service relationship graph, and then enters the anomaly detection module. Anomaly detection module: performs real-time anomaly detection on multi-source data and judges the validity of alarms by combining dynamic thresholds and AI alarm confidence self-learning mechanism. If an anomaly is detected, it enters the root cause reasoning module. Root Cause Reasoning Module: The AI ​​performs reasoning along the call chain anomaly graph and incorporates causal relationship reasoning to predict the scope of anomaly propagation. After completing the root cause analysis, it enters the operation and maintenance decision module. Operation and maintenance decision module: Feeds back the root cause analysis results and optimized alarm information to the operation and maintenance system, and optimizes alarm thresholds and decision parameters in combination with historical records, and outputs updated operation and maintenance decision solutions.

2. The multi-source network data operation and maintenance system based on microservice architecture and AI collaboration according to claim 1, characterized in that, The process for determining whether data is complete and usable is as follows: Perform continuous integrity verification on the collected logs, monitoring metrics, event sequences, and network traffic data, including checking for missing, duplicate, or abnormal data. The collected data is formatted and aligned with time series to eliminate time deviations; The system determines whether the data meets the requirements for subsequent analysis and map construction by setting integrity scoring thresholds and usability indicators. If the conditions are met, the system proceeds to the map construction module.

3. The multi-source network data operation and maintenance system based on microservice architecture and AI collaboration according to claim 2, characterized in that, The process of constructing the microservice call chain and dependency graph is as follows: Extract request relationships, call times, response latency, and error rates between each microservice; Map the microservice nodes and their call relationships into a graph structure, construct a preliminary dependency graph, and mark the call frequency and critical path between nodes; The graph is subjected to topological analysis to identify service links, loops and potential dependency chains. After completion, the node feature embedding and dynamic update process begins.

4. The multi-source network data operation and maintenance system based on microservice architecture and AI collaboration according to claim 3, characterized in that, The process of dynamically updating the service relationship diagram is as follows: Add real-time performance metrics to each node in the graph, including CPU utilization, memory usage, response time, and error rate; Vectorize the node-related log features and fuse them with performance metrics to form a multi-dimensional feature embedding. The graph node features and edge weight information are dynamically updated through a timed or event-triggered mechanism, and then the anomaly detection module is entered.

5. The multi-source network data operation and maintenance system based on microservice architecture and AI collaboration according to claim 4, characterized in that, The process of real-time anomaly detection for multi-source data is as follows: The performance indicators of each node in the graph are compared with historical reference values ​​in real time to identify abnormal fluctuations; By combining log characteristics, event sequences, and network traffic patterns, anomaly scores and alarm levels are calculated. The detected abnormal events are classified, and the services and business scopes that may be affected are marked. After completion, the alarm validity judgment module is entered.

6. The multi-source network data operation and maintenance system based on microservice architecture and AI collaboration according to claim 5, characterized in that, The process of determining alarm validity by combining dynamic thresholds and an AI alarm confidence self-learning mechanism is as follows: The alarm thresholds are dynamically adjusted based on business traffic fluctuations and historical alarm data. AI models are used to calculate alarm confidence, and node characteristics, call chain propagation paths, and historical false alarm data are weighted and analyzed. When an alarm is deemed valid, the anomaly information is transmitted to the root cause reasoning module for in-depth analysis.

7. The multi-source network data operation and maintenance system based on microservice architecture and AI collaboration according to claim 6, characterized in that, The AI's reasoning process along the call chain anomaly graph is as follows: Starting from the affected node, analyze the anomaly propagation path upstream along the call chain; A comprehensive analysis of the real-time performance metrics, log characteristics, and historical anomaly patterns of each node is conducted, and the probability of anomaly propagation and the priority of possible root causes are calculated by combining the weight of the call relationship between nodes. By using graph traversal algorithms and AI inference methods based on probabilistic graphical models, the set of potential root cause nodes is sorted and filtered, and preliminary root cause analysis results are output.

8. The multi-source network data operation and maintenance system based on microservice architecture and AI collaboration according to claim 7, characterized in that, The process of predicting the scope of impact of abnormal propagation is as follows: Based on the root cause localization results, the possible upstream and downstream propagation paths of the anomaly are analyzed step by step along the call chain to identify the affected nodes and service dependencies. Combine real-time node performance metrics, call weights, and historical anomaly propagation data; Calculate the probability of anomaly propagation and the potential impact range of each node; output the degree to which each node is affected by the anomaly.

9. The multi-source network data operation and maintenance system based on microservice architecture and AI collaboration according to claim 8, characterized in that, The process of outputting the updated operation and maintenance decision-making plan is as follows: Based on the degree to which each node is affected by the anomaly, analyze historical alarms, root cause localization, and operation and maintenance results to evaluate the effectiveness of alarm thresholds and policy parameters. Utilize online learning and optimization algorithms to dynamically adjust alarm trigger sensitivity, priority ranking, and resource scheduling strategies; Generate updated operation and maintenance decision-making solutions and output a comprehensive report that includes root cause nodes, alarm information, recommended actions, and expected business impact.

Images