A C++ based micro-service real-time performance monitoring and self-healing system, method, device and medium
By implementing a C++-based real-time performance monitoring and self-healing system for microservices, we have achieved efficient fault diagnosis and automated repair, solving the problems of data processing latency and root cause localization in high-concurrency scenarios in existing technologies, and improving the stability and operational efficiency of microservice clusters.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- CHENGDU ZHONGKE HEXUN TECH CO LTD
- Filing Date
- 2025-12-22
- Publication Date
- 2026-04-17
AI Technical Summary
Existing microservice monitoring systems experience unexpected data processing latency in high-concurrency scenarios, with root cause localization being time-consuming and inaccurate, and self-healing operations lacking specificity, leading to the spread of faults and business losses.
A microservice real-time performance monitoring and self-healing system based on C++ is adopted, including data acquisition, real-time analysis, fault diagnosis and self-healing execution modules. Through multi-threaded parallel acquisition, real-time calculation, fault correlation analysis and automated repair, efficient fault location and repair are achieved.
It significantly improves the intelligence and stability of microservice cluster operation and maintenance, quickly identifies the root cause of failure and automatically repairs it, reduces operation and maintenance costs, and improves the reliability and continuity of microservice clusters.
Smart Images

Figure CN121364984B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of error detection technology, and in particular to a C++-based microservice real-time performance monitoring and self-healing system, method, device and medium. Background Technology
[0002] With the widespread adoption of microservice architecture in fields such as the internet and finance, enterprises are breaking down monolithic applications into multiple independently deployed, elastically scalable microservice nodes. This significantly improves business iteration efficiency, but also brings problems such as increased cluster size and complex service dependencies. During microservice operation, anomalies such as CPU overload, memory leaks, and network congestion can easily trigger a chain of failures. If these failures cannot be monitored and repaired in a timely manner, they will lead to business interruptions and a decline in user experience. Therefore, real-time performance monitoring and self-healing capabilities have become core requirements for ensuring the stable operation of microservice clusters.
[0003] Existing microservice monitoring systems are mostly developed based on interpreted languages such as Java and Python. Their core data processing and analysis modules suffer from operational efficiency bottlenecks, and their fault diagnosis often focuses on anomaly detection for single nodes and single metrics, failing to fully integrate microservice dependency models and making it difficult to identify the propagation path of faults along dependency chains. This leads to unexpected data processing latency in high-concurrency scenarios, time-consuming and inaccurate root cause localization, and even when self-healing operations are triggered, they often fail to quickly restore services due to insufficient targeting. This not only increases manual maintenance costs but also easily causes serious business losses due to fault propagation. Summary of the Invention
[0004] To address the problems in existing technologies where data processing latency exceeds expectations in high-concurrency scenarios, root cause location is time-consuming and inaccurate, and even when self-healing operations are triggered, service recovery is often difficult due to insufficient targeting, this invention provides a C++-based microservice real-time performance monitoring and self-healing system, method, device, and medium.
[0005] The technical solution adopted in this invention is:
[0006] The microservice real-time performance monitoring and self-healing system based on C++ provided by this invention includes a data acquisition module, a real-time analysis module, a fault diagnosis module, and a self-healing execution module that are sequentially connected by communication. Each module is implemented using C++ compilation to ensure high processing efficiency; wherein:
[0007] The data acquisition module performs multi-threaded parallel acquisition and format standardization processing on the raw running data of each microservice node in the microservice cluster, and outputs structured running data in a unified format. The raw running data includes node CPU utilization, memory usage, disk I / O rate, network throughput, interface response time and error logs.
[0008] The real-time analysis module performs real-time calculations and anomaly threshold comparisons on structured operational data in a unified format based on preset performance indicators, and outputs abnormal events and corresponding performance deviation data. The preset performance indicators are expressed as follows: CPU utilization threshold ≤ 85%; memory utilization threshold ≤ 90%; disk I / O rate upper limit ≤ 100MB / s; network throughput lower limit ≥ 10MB / s; interface response time upper limit ≤ 500ms; and error log generation frequency threshold ≤ 5 entries / minute.
[0009] The fault diagnosis module combines the pre-stored microservice dependency model to perform fault correlation analysis and root cause location on abnormal events and corresponding performance deviation data, and outputs self-healing instructions.
[0010] The self-healing execution module performs syntax parsing and execution permission verification on the self-healing instructions, and calls the corresponding repair interface to perform automated repair operations.
[0011] Furthermore, the data acquisition module includes a node communication submodule, a multi-threaded scheduling submodule, a format parsing submodule, a data standardization submodule, and a data caching submodule, which are connected sequentially; wherein:
[0012] The node communication submodule is used to establish TCP / IP long connections with each microservice node in the microservice cluster, receive raw running data sent by each node in real time, and transmit the raw running data to the multi-threaded scheduling submodule.
[0013] After receiving the raw running data transmitted by the node communication submodule, the multi-threaded scheduling submodule dynamically allocates thread resources according to the number of nodes and data types to achieve parallel acquisition and processing of raw data of different nodes and different types, and distributes the parallel processed raw running data to the format parsing submodule.
[0014] The format parsing submodule performs format recognition and field extraction on the received parallel raw data, parses out intermediate data containing indicator names, collection timestamps, and numerical / text content, and transmits the intermediate data to the data standardization submodule.
[0015] The data standardization submodule maps fields, converts units, and filters outliers from the intermediate data output by the format parsing submodule according to the template, generating structured runtime data in a unified format. Outliers include invalid null values and values that are outside the physical range.
[0016] Furthermore, invalid null values are field values that are null, empty strings, or numeric or text content with a default missing identifier.
[0017] Furthermore, the methods for determining whether something exceeds the physical range are as follows: CPU utilization and memory usage: the effective range is 0%~100%, and values exceeding this range are considered to be outside the physical range; disk I / O rate and network throughput: the effective range is ≥0, and negative values are considered to be outside the physical range; interface response time: the effective range is ≥0ms, and negative values are considered to be outside the physical range; error log generation frequency: the effective range is ≥0 entries / minute, and negative values are considered to be outside the physical range.
[0018] Furthermore, the real-time analysis module includes a data verification and grouping submodule, a real-time indicator calculation submodule, and an anomaly detection and event encapsulation submodule, which are connected sequentially; wherein:
[0019] The data verification and grouping submodule uses a C++ asynchronous non-blocking I / O mechanism to receive the unified format structured running data output by the data acquisition module. It performs field integrity verification and time sequence continuity checks on the unified format structured running data. After filtering out duplicate and incomplete data, it groups and caches the data according to node identifier and indicator type, and then transmits the grouped valid data to the indicator real-time calculation submodule.
[0020] The quantitative standard for the "maximum tolerance interval" of timing continuity checks is as follows: CPU utilization and memory usage: maximum tolerance interval of 3 seconds; disk I / O rate and network throughput: maximum tolerance interval of 15 seconds; interface response time: maximum tolerance interval of 300ms; error log: maximum tolerance interval of 10 seconds.
[0021] The real-time metric calculation submodule has a built-in streaming computing engine implemented in C++. It performs real-time calculations on the received grouped valid data according to the metric type: for numerical metrics such as CPU utilization, memory usage, disk I / O rate, and network throughput, it calculates the average, peak, and volatility within a sliding window; for interface response time, it calculates the 95th percentile and timeout frequency; for error logs, it counts the cumulative number of entries per unit time and the proportion of each error type; and outputs the calculated data containing the calculation results, original timestamps, and metric dimension information, and transmits it to the anomaly detection and event generation submodule.
[0022] The quantitative standards for sliding window length and statistical units are as follows: CPU utilization, memory usage, disk I / O rate, and network throughput: sliding window length 1 minute; interface response time: sliding window length 5 minutes; error log statistical unit time: 1 minute; the exception judgment and event generation submodule pre-stores preset performance indicator thresholds and multi-indicator association rules;
[0023] After receiving the calculation data from the real-time indicator calculation submodule, each indicator is compared with its corresponding threshold to calculate the performance deviation value. When the deviation value exceeds the preset judgment threshold, it is marked as abnormal. Then, the node identifier, indicator type, occurrence time, calculated value, threshold, and deviation value of the abnormal indicator are integrated to generate an abnormal event containing a unique event ID. The abnormal event and the corresponding performance deviation data are then output to the fault diagnosis module.
[0024] The specific rules for the association between the "judgment threshold" and the "performance indicator threshold" in the anomaly judgment are as follows: In the anomaly judgment and event generation submodule, the quantitative standard for "deviation value exceeding the preset judgment threshold" is as follows: For CPU utilization and memory usage: the judgment threshold is 10% of the performance threshold, that is, a deviation value ≥ 8.5% or 9% is judged as an anomaly; For disk I / O rate and network throughput: the judgment threshold is 10% of the performance threshold, that is, an actual disk I / O value ≥ 110MB / s and an actual network throughput value ≤ 9MB / s is judged as an anomaly; For interface response time: the judgment threshold is 50ms, that is, an actual 95th percentile value ≥ 550ms is judged as an anomaly; For error log generation frequency: the judgment threshold is 1 record / minute, that is, an actual frequency ≥ 6 records / minute is judged as an anomaly.
[0025] Furthermore, the fault diagnosis module includes, in sequence, an abnormal data receiving and preprocessing submodule, a dependency resolution and correlation analysis submodule, and a root cause localization and self-healing instruction generation submodule; wherein:
[0026] The abnormal data receiving and preprocessing submodule receives abnormal events and corresponding performance deviation data output by the real-time analysis module, performs format integrity verification, duplicate event filtering and time sequence sorting on the data, generates an ordered abnormal dataset, and transmits the abnormal dataset to the dependency resolution and association analysis submodule.
[0027] The dependency resolution and correlation analysis submodule pre-stores the microservice dependency model. After loading the pre-stored microservice dependency model, it matches the abnormal events in the abnormal dataset with the nodes and dependencies in the model, analyzes the propagation path of the abnormal events on the dependency chain, identifies abnormal correlation clusters, outputs correlation analysis results containing the correlation of abnormal nodes, propagation order and performance deviation data linkage characteristics, and transmits them to the root cause localization and self-healing instruction generation submodule.
[0028] The root cause localization and self-healing instruction generation submodule has a built-in fault mode library and rule reasoning engine. After receiving the correlation analysis results, it matches the performance deviation data linkage characteristics of the abnormal correlation cluster with the fault mode library and locates the root cause of the fault through rule reasoning. Then, it matches the predefined self-healing strategy according to the root cause type, generates a structured self-healing instruction containing instruction ID, target node, operation type, and execution parameters, and outputs the self-healing instruction to the self-healing execution module.
[0029] Furthermore, the self-healing execution module includes a self-healing instruction parsing submodule, an execution permission verification submodule, and a self-healing operation execution and result feedback submodule, which are connected in sequence; wherein:
[0030] The self-healing instruction parsing submodule receives the self-healing instructions output by the fault diagnosis module, performs format verification and syntax parsing on the instructions, extracts the core information of the instructions, generates standardized executable instructions, and transmits them to the execution permission verification submodule.
[0031] The execution permission verification submodule pre-stores the microservice node operation permission table. After receiving the standardized executable instruction, it queries the permission table based on the target node ID to verify whether the current system has the permission to perform the corresponding operation on the node. If the permission verification passes, the executable instruction is directly transmitted to the self-healing operation execution and result feedback submodule. If the permission verification fails, an error message indicating insufficient permissions is generated and the process is terminated.
[0032] The self-healing operation execution and result feedback submodule receives executable instructions that have passed permission verification, calls the preset repair interface corresponding to the target node to perform automated repair operations; monitors the operation execution process in real time, records the operation start time, end time and execution status; after the operation is completed, it generates a result report containing instruction ID, target node, operation result and execution time, and feeds the result report back to the fault diagnosis module on the one hand, and writes the result report to the local operation log on the other hand.
[0033] Based on the same inventive concept, this invention also provides a C++-based method for real-time performance monitoring and self-healing of microservices. The aforementioned C++-based real-time performance monitoring and self-healing system for microservices is implemented, including the following steps:
[0034] Step S100: Perform multi-threaded parallel collection and format standardization processing on the raw running data of each microservice node in the microservice cluster, and output structured running data in a unified format; wherein, the raw running data includes node CPU utilization, memory usage, disk I / O rate, network throughput, interface response time and error logs;
[0035] Step S200: Based on preset performance indicators, perform real-time calculations and anomaly threshold comparisons on structured operational data in a unified format, and output abnormal events and corresponding performance deviation data; wherein, the preset performance indicators are expressed as: CPU utilization threshold ≤ 85%; memory utilization threshold ≤ 90%; disk I / O rate upper limit ≤ 100MB / s; network throughput lower limit ≥ 10MB / s; interface response time upper limit ≤ 500ms; error log generation frequency threshold ≤ 5 entries / minute;
[0036] Step S300: Combine the pre-stored microservice dependency model to perform fault correlation analysis and root cause localization on abnormal events and corresponding performance deviation data, and output self-healing instructions.
[0037] Step S400: Perform syntax parsing and execution permission verification on the self-healing command, and call the corresponding repair interface to perform automated repair operations.
[0038] Based on the same inventive concept, the present invention also provides a computer device, including: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the computer instructions to perform the above-mentioned C++-based microservice real-time performance monitoring and self-healing method.
[0039] Based on the same inventive concept, the present invention also provides a computer-readable storage medium storing computer instructions, which are used to cause a computer to execute the above-described C++-based microservice real-time performance monitoring and self-healing method.
[0040] The beneficial effects of this invention are:
[0041] This invention provides a C++-based microservice real-time performance monitoring and self-healing system, method, device, and medium. Through C++ compilation, all modules operate efficiently. Coupled with a closed-loop architecture of "data acquisition - real-time analysis - fault diagnosis - self-healing execution," it significantly improves the intelligence and stability of microservice cluster operations. The data acquisition module's multi-threaded parallel acquisition mechanism, combined with standardized format processing, ensures comprehensive coverage of various operational data such as CPU utilization and memory usage, while also achieving data format uniformity, laying the foundation for subsequent analysis. The real-time analysis module performs real-time calculations and threshold comparisons based on clearly defined preset performance indicators, quickly capturing abnormal indicators and performance deviations, preventing anomalies from escalating. The fault diagnosis module utilizes a microservice dependency model to achieve fault correlation analysis and accurate root cause location, solving the problem of fault diagnosis caused by complex microservice dependencies. The self-healing execution module, through instruction parsing, permission verification, and automated repair operations, can quickly respond to faults without manual intervention, significantly shortening fault recovery time. The overall system balances real-time performance, accuracy, and automation, effectively reducing operational costs and improving the reliability and continuity of microservice cluster operation. Attached Figure Description
[0042] 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 some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0043] Figure 1 A block diagram of a C++-based microservice real-time performance monitoring and self-healing system;
[0044] Figure 2 This is a flowchart of a C++-based microservice real-time performance monitoring and self-healing method. Detailed Implementation
[0045] In the description of this invention, it should be understood that the terms "center," "longitudinal," "lateral," "length," "width," "thickness," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," "outer," "clockwise," "counterclockwise," "axial," "radial," and "circumferential" indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this invention.
[0046] The following disclosure provides many different embodiments or examples for implementing different structures of the present invention. To simplify the disclosure of the present invention, the components and arrangements of specific examples are described below. Of course, these are merely examples and are not intended to limit the present invention.
[0047] The embodiments of the invention will now be described in detail with reference to the accompanying drawings.
[0048] As attached Figure 1 As shown, the microservice real-time performance monitoring and self-healing system based on C++ provided by this invention includes a data acquisition module 1, a real-time analysis module 2, a fault diagnosis module 3, and a self-healing execution module 4, which are sequentially connected by communication. Each module is implemented using C++ compilation to ensure high processing efficiency; wherein:
[0049] Data acquisition module 1 performs multi-threaded parallel acquisition and format standardization processing on the raw running data of each microservice node in the microservice cluster, and outputs structured running data in a unified format.
[0050] The raw data includes node CPU utilization, memory usage, disk I / O rate, network throughput, interface response time, and error logs.
[0051] The real-time analysis module 2 performs real-time calculations and anomaly threshold comparisons on structured operational data in a unified format based on preset performance indicators, and outputs abnormal events and corresponding performance deviation data.
[0052] The preset performance indicators are expressed as follows:
[0053] CPU utilization threshold ≤ 85%;
[0054] Memory usage threshold ≤ 90%;
[0055] Disk I / O speed limit, such as ≤100MB / s;
[0056] Network throughput minimum ≥ 10MB / s;
[0057] The maximum interface response time is ≤500ms.
[0058] Error log generation frequency threshold ≤ 5 entries / minute;
[0059] The fault diagnosis module 3 combines the pre-stored microservice dependency model to perform fault correlation analysis and root cause location on abnormal events and corresponding performance deviation data, and outputs self-healing instructions.
[0060] The self-healing execution module 4 performs syntax parsing and execution permission verification on the self-healing instructions, and calls the corresponding repair interface to perform automated repair operations.
[0061] Furthermore, the data acquisition module 1 includes a node communication submodule, a multi-threaded scheduling submodule, a format parsing submodule, a data standardization submodule, and a data caching submodule, which are connected in sequence; wherein:
[0062] The node communication submodule is used to establish TCP / IP long connections with each microservice node in the microservice cluster, receive raw running data sent by each node in real time, and transmit the raw running data to the multi-threaded scheduling submodule.
[0063] After receiving the raw running data transmitted by the node communication submodule, the multi-threaded scheduling submodule dynamically allocates thread resources according to the number of nodes and data types to achieve parallel acquisition and processing of raw data of different nodes and different types, and distributes the parallel processed raw running data to the format parsing submodule.
[0064] The format parsing submodule performs format recognition and field extraction on the received parallel raw data, parses out intermediate data containing indicator names, collection timestamps, and numerical / text content, and transmits the intermediate data to the data standardization submodule.
[0065] The data standardization submodule maps fields, converts units, and filters outliers from the intermediate data output by the format parsing submodule according to the template, generating structured runtime data in a unified format.
[0066] Outliers include invalid null values and values that are outside the physical range.
[0067] Furthermore, invalid null values are null values, empty strings, or numeric or text content with default missing identifiers (such as "N / A" or "-").
[0068] Furthermore, the method for determining whether something is beyond the physical range is as follows:
[0069] CPU utilization and memory usage: The effective range is 0% to 100%. Values outside this range (such as -3% or 110%) are considered to be outside the physical range.
[0070] Disk I / O rate and network throughput: The valid range is ≥0 (the unit is consistent with the collection protocol, such as MB / s), and negative numbers are judged as exceeding the physical range;
[0071] Interface response time: The valid range is ≥0ms; negative numbers are considered to be outside the physical range.
[0072] Error log generation frequency: The valid range is ≥0 entries / minute, and negative numbers are judged as exceeding the physical range.
[0073] Furthermore, the real-time analysis module 2 includes a data verification and grouping submodule, a real-time indicator calculation submodule, and an anomaly detection and event encapsulation submodule, which are connected sequentially; wherein:
[0074] The data verification and grouping submodule uses a C++ asynchronous non-blocking I / O mechanism to receive the unified format structured running data output by the data acquisition module 1. It performs field integrity verification (verifies whether required fields such as node ID, indicator type, timestamp, and indicator value are complete) and time sequence continuity check (checks whether the time stamp interval between adjacent data exceeds the preset maximum tolerance interval, which is preset through the configuration file). After filtering out duplicate data (based on the combination of node ID, indicator type, and timestamp) and incomplete data (data with missing required fields), it groups and caches the data according to node identifier and indicator type, and then transmits the grouped valid data to the real-time indicator calculation submodule.
[0075] The quantitative standard for the "maximum tolerance interval" of the time sequence continuity check is as follows:
[0076] CPU utilization and memory usage (collection frequency 1 time / second): maximum tolerable interval of 3 seconds (i.e., if the interval between adjacent data timestamps exceeds 3 seconds, it is judged as a timing break).
[0077] Disk I / O rate and network throughput (sampling frequency 1 time / 5 seconds): maximum tolerable interval 15 seconds;
[0078] Interface response time (sampling frequency 1 time / 100ms): maximum tolerance interval 300ms;
[0079] Error log (real-time push): Maximum tolerance interval is 10 seconds (i.e., if no new log is received within 10 seconds, it is judged as a timing break).
[0080] The real-time indicator calculation submodule has a built-in streaming computing engine implemented in C++, which performs real-time calculations on the received grouped valid data according to the indicator type:
[0081] For numerical metrics such as CPU utilization, memory usage, disk I / O rate, and network throughput, calculate the average, peak, and volatility within a sliding window (the window length is set via a configuration file);
[0082] For the interface response time, calculate the 95th percentile value and the timeout frequency (the timeout criterion is that the response time exceeds the upper limit of the interface response time in the preset performance indicators).
[0083] For error logs, count the cumulative number of entries and the percentage of each error type within a unit of time (the unit of time length is set through the configuration file);
[0084] The output includes the calculation results, original timestamps, and indicator dimension information (node identifier, indicator type), and is transmitted to the anomaly detection and event generation submodule.
[0085] The quantitative standards for sliding window length and statistical units are as follows:
[0086] CPU utilization, memory usage, disk I / O rate, network throughput: sliding window length 1 minute (containing 60 data points, 1 point per second);
[0087] Interface response time: Sliding window length 5 minutes (including 3000 data points, 1 point every 100ms);
[0088] Error log statistics unit of time: 1 minute (consistent with the frequency threshold unit for easy direct comparison).
[0089] The anomaly detection and event generation submodule pre-stores preset performance indicator thresholds and multi-indicator association rules (association rules include the linkage judgment when disk I / O rate exceeds the upper limit and CPU utilization exceeds the threshold, the linkage judgment when network throughput is below the lower limit and interface response time exceeds the upper limit, etc.). After receiving the calculation data from the real-time indicator calculation submodule, it compares each indicator with the corresponding threshold and calculates the performance deviation value (for numerical indicators, it is the difference between the actual calculated value and the threshold; for percentage indicators, it is the ratio of the actual percentage to the threshold). When the deviation value exceeds the preset judgment threshold (the judgment threshold is set through the configuration file), it is marked as an anomaly. Then, it integrates the node identifier, indicator type, occurrence time, calculated value, threshold, and deviation value of the anomaly indicator to generate an anomaly event containing a unique event ID (the event format is {event ID, node ID, indicator type, occurrence time, calculated value, threshold, deviation value}), and outputs the anomaly event and the corresponding performance deviation data to the fault diagnosis module 3.
[0090] The specific association rules between the "judgment threshold" and the "performance index threshold" in anomaly detection are as follows:
[0091] In the anomaly detection and event generation submodule, the quantification standard for "deviation value exceeding the preset detection threshold" is as follows:
[0092] For CPU utilization (threshold 85%) and memory usage (threshold 90%): The judgment threshold is 10% of the performance threshold (relative value), that is, when the deviation (actual value - threshold) is ≥8.5% (CPU) or 9% (memory), it is judged as abnormal (e.g., CPU actual is 94%, deviation 9% ≥ 8.5%, triggering an abnormality).
[0093] For disk I / O rate (upper limit 100MB / s) and network throughput (lower limit 10MB / s): the judgment threshold is 10% (absolute value) of the performance threshold, that is, when the actual value of disk I / O is ≥110MB / s (100+10) and the actual value of network throughput is ≤9MB / s (10-1), it is judged as abnormal.
[0094] For interface response time (upper limit 500ms): the judgment threshold is 50ms (absolute value), that is, when the actual 95th percentile value is ≥550ms, it is judged as abnormal;
[0095] Error log generation frequency (threshold 5 entries / minute): The judgment threshold is 1 entry / minute (absolute value), that is, when the actual frequency is ≥6 entries / minute, it is judged as abnormal.
[0096] Furthermore, the fault diagnosis module 3 includes, in sequence, an abnormal data receiving and preprocessing submodule, a dependency resolution and correlation analysis submodule, and a root cause location and self-healing instruction generation submodule; wherein:
[0097] The abnormal data receiving and preprocessing submodule receives abnormal events and corresponding performance deviation data output by the real-time analysis module 2, performs format integrity verification (verifies whether required fields such as event ID, node ID, indicator type, and performance deviation value are complete), duplicate event filtering (determines duplicates based on the combination of event ID and occurrence timestamp), and time-series sorting (arranges in ascending order by event occurrence timestamp), generates an ordered abnormal dataset, and transmits the abnormal dataset to the dependency parsing and association analysis submodule.
[0098] The dependency resolution and correlation analysis submodule pre-stores a microservice dependency model (the model contains the call chain relationship, resource dependency relationship and hierarchical structure information of each microservice node, and is updated synchronously through configuration files or service registry). After loading the pre-stored microservice dependency model, it matches the abnormal events in the abnormal dataset with the nodes and dependencies in the model, analyzes the propagation path of the abnormal events on the dependency chain (such as whether the abnormality of service A causes the dependent services B and C to become abnormal in succession), identifies the abnormal correlation cluster (i.e. the set of abnormal nodes with direct or indirect dependency relationships), outputs the correlation analysis results containing the correlation relationship of abnormal nodes, propagation order and performance deviation data linkage characteristics, and transmits them to the root cause localization and self-healing instruction generation submodule.
[0099] The root cause localization and self-healing instruction generation submodule includes a built-in fault mode library (which stores preset fault types and feature mappings, such as "sudden increase in CPU utilization (CPU utilization rises from the normal range (≤60%) to over 80% within 1 minute) + continuous increase in memory usage (memory usage increases at a rate of ≥5% / minute for 5 consecutive minutes)" corresponding to the "memory leak" fault, and "sudden decrease in network throughput (network throughput drops from the normal range (≥20MB / s) to ≤5MB / s within 30 seconds) + interface response time exceeds the limit" corresponding to the "network link congestion" fault) and rule-based reasoning. The engine (a decision tree reasoning algorithm implemented in C++) receives the correlation analysis results and matches the performance deviation data linkage characteristics of the abnormal correlation cluster with the fault mode library. It then uses rule reasoning to locate the root cause of the fault (including the root cause node identifier, fault type, and scope of impact). Subsequently, it matches a predefined self-healing strategy according to the root cause type (such as "restart service node" strategy for "memory leak" and "switch to backup network link" strategy for "network link blockage"). It generates a structured self-healing instruction containing instruction ID, target node, operation type, and execution parameters, and outputs the self-healing instruction to the self-healing execution module 4.
[0100] Furthermore, the self-healing execution module 4 includes a self-healing instruction parsing submodule, an execution permission verification submodule, and a self-healing operation execution and result feedback submodule, which are connected in sequence; wherein:
[0101] The self-healing instruction parsing submodule receives the self-healing instruction output by the fault diagnosis module 3, performs format verification (verifies whether the instruction contains required fields such as target node identifier, operation type, and execution parameters) and syntax parsing (converts the abstract operation type in the instruction into a specific machine-recognizable command format), extracts the core information of the instruction (target node ID, operation to be executed, and operation parameters), generates a standardized executable instruction, and transmits it to the execution permission verification submodule.
[0102] The execution permission verification submodule pre-stores the microservice node operation permission table (recording the types of operations and permission levels allowed to be executed by each node). After receiving the standardized executable instruction, it queries the permission table according to the target node ID to verify whether the current system has the permission to execute the corresponding operation on the node. If the permission verification passes, the executable instruction is directly transmitted to the self-healing operation execution and result feedback submodule. If the permission verification fails, an error message indicating insufficient permissions is generated and the process is terminated.
[0103] The self-healing operation execution and result feedback submodule receives executable instructions that have passed permission verification, calls the preset repair interfaces corresponding to the target node (such as node restart interface, resource expansion interface, network switching interface, etc.) to perform automated repair operations; monitors the operation execution process in real time, records the operation start time, end time and execution status (success / failure); after the operation is completed, it generates a result report containing instruction ID, target node, operation result and execution time, and feeds the result report back to the fault diagnosis module 3 on the one hand, and writes the result report to the local operation log (stored in order of timestamp).
[0104] As attached Figure 2 As shown, based on the same inventive concept, this embodiment also provides a C++-based microservice real-time performance monitoring and self-healing method. The aforementioned C++-based microservice real-time performance monitoring and self-healing system is implemented, including the following steps:
[0105] Step S100: Perform multi-threaded parallel collection and format standardization processing on the raw running data of each microservice node in the microservice cluster, and output structured running data in a unified format.
[0106] The raw data includes node CPU utilization, memory usage, disk I / O rate, network throughput, interface response time, and error logs.
[0107] Step S200: Based on preset performance indicators, perform real-time calculation and anomaly threshold comparison on structured operation data in a unified format, and output abnormal events and corresponding performance deviation data.
[0108] The preset performance indicators are expressed as follows:
[0109] CPU utilization threshold ≤ 85%;
[0110] Memory usage threshold ≤ 90%;
[0111] Disk I / O speed limit, such as ≤100MB / s;
[0112] Network throughput minimum ≥ 10MB / s;
[0113] The maximum interface response time is ≤500ms.
[0114] Error log generation frequency threshold ≤ 5 entries / minute;
[0115] Step S300: Combine the pre-stored microservice dependency model to perform fault correlation analysis and root cause localization on abnormal events and corresponding performance deviation data, and output self-healing instructions.
[0116] Step S400: Perform syntax parsing and execution permission verification on the self-healing command, and call the corresponding repair interface to perform automated repair operations.
[0117] Based on the same inventive concept, this embodiment also provides a computer device, including: a memory and a processor, which are interconnected. The memory stores computer instructions, and the processor executes the computer instructions to perform the aforementioned C++-based microservice real-time performance monitoring and self-healing method.
[0118] Based on the same inventive concept, this embodiment also provides a computer-readable storage medium storing computer instructions, which are used to cause a computer to execute the aforementioned C++-based microservice real-time performance monitoring and self-healing method.
Claims
1. A microservice real-time performance monitoring and self-healing system based on C++, characterized in that, It includes a data acquisition module, a real-time analysis module, a fault diagnosis module, and a self-healing execution module, all connected in sequence. Each module is implemented using C++ compilation to ensure high processing efficiency; among them: The data acquisition module performs multi-threaded parallel acquisition and format standardization processing on the raw running data of each microservice node in the microservice cluster, and outputs structured running data in a unified format. The raw data includes node CPU utilization, memory usage, disk I / O rate, network throughput, interface response time, and error logs. The real-time analysis module performs real-time calculations and anomaly threshold comparisons on structured operational data in a unified format based on preset performance indicators, and outputs abnormal events and corresponding performance deviation data. The preset performance indicators are expressed as follows: CPU utilization threshold ≤ 85%; Memory usage threshold ≤ 90%; Disk I / O speed limit, such as ≤100MB / s; Network throughput minimum ≥ 10MB / s; The maximum interface response time is ≤500ms. Error log generation frequency threshold ≤ 5 entries / minute; The fault diagnosis module combines the pre-stored microservice dependency model to perform fault correlation analysis and root cause location on abnormal events and corresponding performance deviation data, and outputs self-healing instructions. The self-healing execution module performs syntax parsing and execution permission verification on the self-healing instructions, and calls the corresponding repair interface to perform automated repair operations. The fault diagnosis module includes, in sequence, an abnormal data receiving and preprocessing submodule, a dependency resolution and correlation analysis submodule, and a root cause localization and self-healing instruction generation submodule; wherein: The abnormal data receiving and preprocessing submodule receives abnormal events and corresponding performance deviation data output by the real-time analysis module, performs format integrity verification, duplicate event filtering and time sequence sorting on the data, generates an ordered abnormal dataset, and transmits the abnormal dataset to the dependency resolution and association analysis submodule. The dependency resolution and correlation analysis submodule pre-stores the microservice dependency model. After loading the pre-stored microservice dependency model, it matches the abnormal events in the abnormal dataset with the nodes and dependencies in the model, analyzes the propagation path of the abnormal events on the dependency chain, identifies abnormal correlation clusters, outputs correlation analysis results containing the correlation of abnormal nodes, propagation order and performance deviation data linkage characteristics, and transmits them to the root cause localization and self-healing instruction generation submodule. The root cause localization and self-healing instruction generation submodule has a built-in fault mode library and rule reasoning engine. After receiving the correlation analysis results, it matches the performance deviation data linkage characteristics of the abnormal correlation cluster with the fault mode library and locates the root cause of the fault through rule reasoning. Then, it matches the predefined self-healing strategy according to the root cause type, generates a structured self-healing instruction containing instruction ID, target node, operation type, and execution parameters, and outputs the self-healing instruction to the self-healing execution module.
2. The C++-based microservice real-time performance monitoring and self-healing system according to claim 1, characterized in that, The data acquisition module includes a node communication submodule, a multi-threaded scheduling submodule, a format parsing submodule, a data standardization submodule, and a data caching submodule, which are connected sequentially; among them: The node communication submodule is used to establish TCP / IP long connections with each microservice node in the microservice cluster, receive raw running data sent by each node in real time, and transmit the raw running data to the multi-threaded scheduling submodule. After receiving the raw running data transmitted by the node communication submodule, the multi-threaded scheduling submodule dynamically allocates thread resources according to the number of nodes and data types to achieve parallel acquisition and processing of raw data of different nodes and different types, and distributes the parallel processed raw running data to the format parsing submodule. The format parsing submodule performs format recognition and field extraction on the received parallel raw data, parses out intermediate data containing indicator names, collection timestamps, and numerical / text content, and transmits the intermediate data to the data standardization submodule. The data standardization submodule maps fields, converts units, and filters outliers from the intermediate data output by the format parsing submodule according to the template, generating structured runtime data in a unified format. Outliers include invalid null values and values that are outside the physical range.
3. The C++-based microservice real-time performance monitoring and self-healing system according to claim 2, characterized in that, Invalid null values are fields that are null, empty strings, or numeric or text content with a default missing identifier.
4. The C++-based microservice real-time performance monitoring and self-healing system according to claim 2, characterized in that, The method for determining whether something is outside the physical limits is as follows: CPU utilization and memory usage: The effective range is 0% to 100%. Values exceeding this range are considered to be outside the physical range. Disk I / O rate and network throughput: The valid range is ≥0, and negative numbers are considered to be outside the physical range; Interface response time: The valid range is ≥0ms; negative numbers are considered to be outside the physical range. Error log generation frequency: The valid range is ≥0 entries / minute, and negative numbers are judged as exceeding the physical range.
5. The C++-based microservice real-time performance monitoring and self-healing system according to claim 1, characterized in that, The real-time analysis module includes a data verification and grouping submodule, a real-time indicator calculation submodule, and an anomaly detection and event encapsulation submodule, which are connected sequentially; among them: The data verification and grouping submodule uses a C++ asynchronous non-blocking I / O mechanism to receive the unified format structured running data output by the data acquisition module. It performs field integrity verification and time sequence continuity checks on the unified format structured running data. After filtering out duplicate and incomplete data, it groups and caches the data according to node identifier and indicator type, and then transmits the grouped valid data to the indicator real-time calculation submodule. The real-time indicator calculation submodule has a built-in streaming computing engine implemented in C++, which performs real-time calculations on the received grouped valid data according to the indicator type: For numerical metrics such as CPU utilization, memory usage, disk I / O rate, and network throughput, calculate the average, peak, and volatility within a sliding window; Calculate the 95th percentile value and timeout frequency for the interface response time; For error logs, calculate the cumulative number of entries per unit time and the percentage of each error type; The output includes the calculation results, original timestamps, and indicator dimension information, and is transmitted to the anomaly detection and event generation submodule. The anomaly detection and event generation submodule pre-stores preset performance indicator thresholds and multi-indicator association rules. After receiving the calculation data from the real-time indicator calculation submodule, it compares each indicator with its corresponding threshold to calculate the performance deviation value. When the deviation value exceeds the preset judgment threshold, it is marked as an anomaly. Then, it integrates the node identifier, indicator type, occurrence time, calculated value, threshold, and deviation value of the anomaly indicator to generate an anomaly event containing a unique event ID, and outputs the anomaly event and the corresponding performance deviation data to the fault diagnosis module.
6. The microservice real-time performance monitoring and self-healing system based on C++ according to claim 1, characterized in that, The self-healing execution module includes a self-healing instruction parsing submodule, an execution permission verification submodule, and a self-healing operation execution and result feedback submodule, which are connected sequentially. Among them: The self-healing instruction parsing submodule receives the self-healing instructions output by the fault diagnosis module, performs format verification and syntax parsing on the instructions, extracts the core information of the instructions, generates standardized executable instructions, and transmits them to the execution permission verification submodule. The execution permission verification submodule pre-stores the microservice node operation permission table. After receiving the standardized executable instruction, it queries the permission table based on the target node ID to verify whether the current system has the permission to perform the corresponding operation on the node. If the permission verification passes, the executable instruction is directly transmitted to the self-healing operation execution and result feedback submodule. If the permission verification fails, an error message indicating insufficient permissions is generated and the process is terminated. The self-healing operation execution and result feedback submodule receives executable instructions that have passed permission verification, calls the preset repair interface corresponding to the target node to perform automated repair operations; monitors the operation execution process in real time, records the operation start time, end time and execution status; after the operation is completed, it generates a result report containing instruction ID, target node, operation result and execution time, and feeds the result report back to the fault diagnosis module on the one hand, and writes the result report to the local operation log on the other hand.
7. A C++-based method for real-time performance monitoring and self-healing of microservices, characterized in that, The implementation of the C++-based microservice real-time performance monitoring and self-healing system as described in any one of claims 1-6 includes the following steps: Step S100: Perform multi-threaded parallel collection and format standardization processing on the raw running data of each microservice node in the microservice cluster, and output structured running data in a unified format. The raw data includes node CPU utilization, memory usage, disk I / O rate, network throughput, interface response time, and error logs. Step S200: Based on preset performance indicators, perform real-time calculation and anomaly threshold comparison on structured operation data in a unified format, and output abnormal events and corresponding performance deviation data. The preset performance indicators are expressed as follows: CPU utilization threshold ≤ 85%; Memory usage threshold ≤ 90%; Disk I / O speed limit, such as ≤100MB / s; Network throughput minimum ≥ 10MB / s; The maximum interface response time is ≤500ms. Error log generation frequency threshold ≤ 5 entries / minute; Step S300: Combine the pre-stored microservice dependency model to perform fault correlation analysis and root cause localization on abnormal events and corresponding performance deviation data, and output self-healing instructions. Step S400: Perform syntax parsing and execution permission verification on the self-healing command, and call the corresponding repair interface to perform automated repair operations.
8. A computer device, characterized in that, include: The system includes a memory and a processor, which are interconnected. The memory stores computer instructions, and the processor executes these computer instructions to perform a C++-based microservice real-time performance monitoring and self-healing method as described in claim 7.
9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to execute the C++-based microservice real-time performance monitoring and self-healing method as described in claim 7.
Citation Information
Patent Citations
Back-end system fault self-recovery method and device, storage medium and computer equipment
CN120768800A
Microservice performance problem diagnosis and repair method and system
CN121029569A