Micro-service application full-link performance real-time monitoring system and detection method thereof
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- NANJING HUIZHI CULTURE MEDIA CO LTD
- Filing Date
- 2026-03-26
- Publication Date
- 2026-06-30
AI Technical Summary
Existing microservice performance monitoring solutions suffer from monitoring silos, non-real-time nature, and difficulty in root cause identification, failing to provide real-time insights and accurate alerts at the second or sub-second level.
It employs a distributed probe deployment module, a full-link tracing module, a performance indicator aggregation and analysis module, an intelligent anomaly detection module, and a real-time data storage module. Combined with dynamic baseline learning and multi-indicator correlation analysis, it achieves real-time performance monitoring throughout the entire process from data collection to visualization, supporting end-to-end latency down to the second level.
It enables real-time monitoring of end-to-end performance, breaks down monitoring silos, provides a global view of business requests, reduces false alarms and missed alarms of static threshold alarms, can perceive system status in near real-time, and greatly shortens the troubleshooting time.
Smart Images
Figure CN122309308A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computer software performance monitoring technology, specifically to a real-time monitoring system and detection method for the end-to-end performance of microservice applications. Background Technology
[0002] With the popularization of microservice architecture, monolithic applications are broken down into multiple independently deployed, loosely coupled services. This brings improved development flexibility and scalability, but also significantly increases the complexity of system operation and maintenance and performance diagnosis. An external user request often needs to traverse multiple different microservice nodes - such as gateways, authentication services, business services, databases, etc. - to complete, forming a complex call chain.
[0003] Existing performance monitoring solutions have the following limitations:
[0004] Monitoring silos: Traditional server monitoring—such as CPU and memory, middleware monitoring—such as database connection pools, and application monitoring—such as the time consumption of a single service interface—are independent of each other and lack a global perspective that spans the entire business request. When performance degradation or failure occurs, it is difficult to quickly locate which specific service or link has a problem.
[0005] Non-real-time nature: Many monitoring solutions are based on batch log analysis or timed sampling, with data latency ranging from several minutes to several hours. This cannot meet the need for real-time insights into online business at the second or sub-second level, especially when a fault occurs, and cannot provide immediate feedback.
[0006] Reliance on static thresholds: Alarms are mostly based on static thresholds set by experience, which cannot adapt to dynamic scenarios such as periodic fluctuations in business traffic and sudden events, and are prone to false alarms or missed alarms.
[0007] Root cause identification is difficult: only superficial symptoms of the problem can be found, such as slow overall response. There is a lack of effective tools to automatically analyze the root causes of performance problems, relying on manual troubleshooting by operations and maintenance personnel, which is inefficient.
[0008] Therefore, those skilled in the art provide a real-time performance monitoring system and detection method for the entire chain of microservice applications to solve the problems mentioned in the background art. Summary of the Invention
[0009] This invention provides a real-time monitoring system and method for the end-to-end performance of microservice applications to solve the problems of isolated monitoring dimensions, high data latency, inaccurate alarms, and difficulty in locating the root cause of problems in the existing technology.
[0010] Another objective of this invention is to provide a detection method that complements the system, enabling real-time performance monitoring of the entire process from data acquisition, processing, analysis to visualization, with end-to-end latency controlled within seconds.
[0011] A real-time performance monitoring system for the entire microservice application chain, comprising:
[0012] The distributed probe deployment module is used to deploy on microservice application nodes in a low-intrusive manner to collect performance data and call context in real time. The performance loss of the probe is ≤3%.
[0013] The end-to-end tracing module is used to receive and correlate call chain data with a unified link identifier reported by each probe to reconstruct the complete request call topology;
[0014] The performance metric aggregation and analysis module is used to perform streaming processing on the data output by the end-to-end tracing module and calculate service-level, topology-level, and instance-level performance metrics in real time.
[0015] The intelligent anomaly detection module is used to identify performance anomalies and locate suspected root cause services in real time based on dynamic baseline learning and multi-indicator correlation analysis.
[0016] The real-time data storage module is used to store aggregated performance metrics data and detailed call chain data;
[0017] The visualization and alarm module is used to display the system performance status and call chain in real time, and to trigger alarms when anomalies occur.
[0018] Preferably, the distributed probe deployment module is implemented using bytecode enhancement technology, sidecar proxy mode, JavaAgent technology, or eBPF probe technology. The collected data includes at least: interface call time, status code, SQL execution time, external API call time, and custom business metrics. The custom business metrics are configured by adding Tag key-value pairs in the configuration file or by selecting business scenarios in the visual interface.
[0019] Preferably, the intelligent anomaly detection module establishes a dynamic baseline of performance indicators through a time series prediction algorithm, and judges the abnormal state by the deviation between real-time data and the dynamic baseline, combined with a preset rule combination; the time series prediction algorithm is the Prophet algorithm, the ARIMA algorithm, or the LSTM algorithm.
[0020] Preferably, the intelligent anomaly detection module also performs multi-indicator correlation analysis. When multiple preset correlated indicators successively become abnormal within a 30-second time window, an alarm message containing root cause inference is generated. The dynamic baseline is learned and generated in a sliding window mode that can be configured for 5 minutes or 10 minutes, and the anomaly judgment threshold is configurable for 2-3 standard deviations.
[0021] Preferably, the real-time data storage module includes a time-series database and a distributed search database, which are used to store aggregate performance metrics and detailed call chain data, respectively; in the time-series database, second-level metrics are retained for 7 days, minute-level metrics are retained for 30 days, and hour-level metrics are retained for 1 year, while the retention period for detailed call chain data is configurable from 7 to 30 days.
[0022] A method for real-time performance monitoring of the entire microservice application chain includes the following steps:
[0023] S1: Real-time collection of call and performance data of each microservice node through distributed probes, with a sampling frequency of milliseconds;
[0024] S2: The collected data is reported in real time and the entire chain is traced and correlated to restore the complete call chain;
[0025] S3: Perform streaming aggregation on the associated call chain data and calculate multi-dimensional performance metrics in real time;
[0026] S4: Real-time anomaly detection and preliminary root cause localization are performed on the performance indicators based on the dynamic baseline;
[0027] S5: Store the indicator data and call chain data in the corresponding databases respectively;
[0028] S6: Visualizes real-time performance status and call chain, and triggers alarms when an anomaly is detected;
[0029] The end-to-end delay of steps S1 to S6 is within seconds.
[0030] Preferably, in step S1, a globally unique TraceID is generated for each external request, and the TraceID and the SpanID of the hierarchical relationship are passed during inter-service calls; the TraceID adopts the UUID-v4 format, the SpanID adopts the 64-bit integer format, and the parent and child Spans are associated through the parent SpanID.
[0031] Preferably, in step S4, the dynamic baseline is a time-varying reference range obtained by machine learning based on historical data of performance indicators and combined with periodicity and trend; the historical data retention period is configurable from 7 to 30 days, and the machine learning adopts the Prophet algorithm, ARIMA algorithm or LSTM algorithm.
[0032] Preferably, in step S6, the alarm information includes abnormal indicators, related services, possible impact range, and preliminary root cause location suggestions; the alarm is pushed through email, SMS, DingTalk, WeChat Work, or Webhook channels.
[0033] Preferably, in step S2, the data reporting adopts an efficient asynchronous method using UDP or asynchronous HTTP 2.0 protocol; in step S3, the streaming aggregation adopts the Apache Flink streaming engine, and the aggregation granularity is configurable at the second or minute level.
[0034] The technical effects and advantages of this invention are as follows:
[0035] End-to-end panoramic visibility: It enables complete call chain tracing from the user entry point to the lowest level service, breaks down monitoring silos, and provides a global view of business requests.
[0036] True real-time performance: From data collection and processing to displaying alarms, the entire process achieves latency at the second or even sub-second level, enabling the operations and maintenance team to perceive the system status in near real-time.
[0037] Intelligent analysis and localization: Through dynamic baseline technology and multi-dimensional correlation analysis, false alarms and false negatives of static threshold alarms are significantly reduced, and preliminary root cause localization can be automatically provided, greatly shortening the troubleshooting time.
[0038] Low intrusion and high performance: The probe design is lightweight, has minimal impact on application performance, is easy to deploy at large scale in complex production environments, and supports multi-technology stack applications.
[0039] Flexible scalability: The system's modular design supports rapid expansion to new monitoring metrics, new detection algorithms, and new notification channels. It also supports flexible configuration of parameters such as aggregation granularity, data retention period, and anomaly thresholds to adapt to the needs of microservice architectures of different industries and scales. Attached Figure Description
[0040] Figure 1 This is a schematic diagram of the overall architecture of a real-time performance monitoring system for the entire microservice application chain provided in this application embodiment;
[0041] Figure 2 This is a flowchart illustrating the main steps of a real-time performance monitoring method for the entire microservice application chain provided in this application embodiment. Detailed Implementation
[0042] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments. The embodiments of the present invention are given for illustrative and descriptive purposes only, and are not intended to be exhaustive or to limit the invention to the forms disclosed. Many modifications and variations will be apparent to those skilled in the art. The embodiments were chosen and described to better illustrate the principles and practical application of the invention, and to enable those skilled in the art to understand the invention and design various embodiments with various modifications suitable for a particular purpose.
[0043] Example 1
[0044] Please see Figures 1-2 In this embodiment, it is provided
[0045] A real-time performance monitoring system for the entire microservice application chain
[0046] The system includes the following modules:
[0047] Distributed probe deployment module: Automatically deployed on the host machine, container, or runtime environment where the microservice application resides, using either a lightweight agent or non-intrusive bytecode enhancement. For Java applications, Java Agent technology is preferred, while for non-Java applications such as Go and Python, eBPF probe technology can be used to ensure minimal impact on application performance (performance loss ≤3%, test conditions: in a scenario where single service node QPS=10000 and average interface latency=200ms, the increase in interface latency after probe deployment is ≤6ms).
[0048] Used to collect the following performance data in real time - sampling frequency at the millisecond level: service interface call time, call status - success / failure, HTTP status code, SQL execution time, external API call time, JVM memory / GC information - for Java applications, custom business metrics, etc.
[0049] Custom business metrics can be configured by adding tag key-value pairs in the configuration file, such as "businessType=login" and "orderId=123456", or by selecting business scenarios in the visual interface, to achieve performance aggregation for specific business processes.
[0050] The end-to-end tracing module receives call chain data (Span data) with a unified and unique link identifier (TraceID) from each probe. Data transmission between the probe and this module uses UDP or asynchronous HTTP 2.0 protocol to ensure high efficiency and low intrusion in data transmission.
[0051] This module is responsible for real-time association and splicing of all cross-service and cross-process call fragments (Spans) belonging to the same user request, restoring the complete request call topology and lifecycle, and generating an end-to-end full-link tracing tree. The TraceID adopts the UUID-v4 format, the SpanID adopts the 64-bit integer format, and the parent and child Spans are associated through the parent SpanID.
[0052] Performance metrics aggregation and analysis module: It interfaces with the full-link tracing module and uses the Apache Flink stream processing engine to perform streaming processing and aggregation on the raw tracing data. The aggregation granularity can be configured to be at the second or minute level.
[0053] Real-time calculation of the following key performance indicators (KPIs):
[0054] Service-level metrics: Requests per second (QPS), Response Time (RT), Error Rate, P90 / P99 percentile response time;
[0055] Topology-level metrics: service dependency graph, average network latency of cross-service calls, and inter-service traffic;
[0056] Instance-level metrics: The independent performance of each service instance;
[0057] Business-level metrics: Performance of specific business scenarios based on custom tag aggregation, such as the total time spent on "user login process" and "order payment process".
[0058] Intelligent anomaly detection module: Built-in detectors based on machine learning, such as dynamic baselines, unsupervised anomaly detection algorithms, and rule engines.
[0059] This module continuously learns the historical patterns of various performance indicators using a sliding window that can be configured to be 5 or 10 minutes. The historical data retention period can be configured to be 7-30 days. It uses Prophet, ARIMA or LSTM time series forecasting algorithms to establish a dynamic baseline, which will be automatically adjusted according to business periodicity, such as weekdays / weekends, peak / off-peak periods.
[0060] By comparing current metrics with a dynamic baseline in real time—the anomaly detection threshold is 2-3 standard deviations and is configurable—and combining preset intelligent rules such as "error rate increases by more than 50% for 3 consecutive sampling points" or "RT P99 value suddenly exceeds the baseline by 2 standard deviations," it automatically identifies abnormal patterns such as performance anomalies, potential service failures, or sudden increases in business traffic, and generates a list of suspected root cause services.
[0061] Meanwhile, the module also performs multi-indicator correlation analysis. When multiple preset correlated indicators successively become abnormal within a time window, such as 30 seconds, alarm information containing root cause inference is generated.
[0062] Real-time data storage module: Uses time-series databases such as InfluxDB and TDengine to store high-precision performance metric data, supporting high-speed writing - write rate ≥ 100,000 records / second and second-level query; among them, the retention period for second-level metrics is 7 days, the retention period for minute-level metrics is 30 days, and the retention period for hour-level metrics is 1 year.
[0063] At the same time, a distributed search database, such as Elasticsearch, is used to index and store detailed raw call chain (Trace) data. The retention period for a single Trace data can be configured to 7-30 days for in-depth drill-down analysis.
[0064] Visualization and Alerts Module: Provides a visual dashboard that displays a real-time global service map—dependency topology, key performance indicator trend charts, and a real-time call chain list. When the intelligent anomaly detection module triggers an alert, this module instantly pushes alert information through multiple notification channels—such as email, SMS, DingTalk, WeChat Work, and Webhook. The alert information includes the abnormal service, related indicators, potential impact scope, and preliminary root cause localization suggestions.
[0065] A method for real-time performance monitoring of the entire microservice application chain based on the above system
[0066] The method includes the following steps:
[0067] S1: Real-time data collection: Through distributed probes deployed on each microservice node, real-time call data, performance metrics, and log events are collected without loss - the sampling frequency is at the millisecond level.
[0068] Each cross-service call injects and transmits a unified TraceID-UUID-v4 format and SpanID-64-bit integer format. Parent and child Spans are associated through the parent SpanID to ensure the traceability of data throughout the entire chain. Custom business metrics are collected and configured by adding Tag key-value pairs in the configuration file or by selecting business scenarios in the visual interface.
[0069] S2: Real-time Link Tracing and Reporting: The probe will encapsulate the Span data with time-series relationships and report it to the system's data collection endpoint in real time via UDP or asynchronous HTTP 2.0 protocol in an efficient asynchronous manner, ensuring that data transmission is non-blocking, low-latency, and does not affect the performance of the application itself.
[0070] S3: Link Restoration and Metric Streaming Aggregation: After receiving Span data, the full-link tracing module restores the Span into a complete Trace-full-link call chain based on the association between TraceID and SpanID.
[0071] The performance metric aggregation and analysis module uses the Apache Flink stream processing engine to perform streaming computation on incoming Trace and Span data, generating aggregated performance metrics in real time across multiple dimensions such as services, instances, interfaces, and business scenarios at configurable aggregation granularity of seconds or minutes.
[0072] S4: Dynamic Baseline Learning and Anomaly Detection: The intelligent anomaly detection module continuously learns the historical patterns of various performance indicators using a sliding window that can be configured with 5 or 10 minutes. Historical data is retained for 7-30 days, and time-varying dynamic baselines are established using Prophet, ARIMA, or LSTM time series forecasting algorithms.
[0073] By comparing the current indicators with the dynamic baseline in real time (the anomaly judgment threshold is 2-3 standard deviations, which is configurable), and combining multi-indicator correlation analysis and preset intelligent rules, it can determine whether the current system status is abnormal, initially locate the source service of the anomaly, and generate a list of suspected root cause services and root cause inference suggestions.
[0074] S5: Data storage and indexing: Aggregated high-performance metrics are written to the time-series database according to preset retention periods - second-level metrics are retained for 7 days, minute-level metrics for 30 days, and hour-level metrics for 1 year; detailed call chains - trace data are indexed and written to the distributed search database - Elasticsearch. The retention period for a single trace data can be configured to 7-30 days for subsequent in-depth drill-down analysis and issue backtracking.
[0075] S6: Visual presentation and intelligent alerts: Dynamically refresh and display the performance dashboard, service dependency topology map, indicator trend curves and link details on the Dashboard, and support quick query of link data by TraceID, service name, time range and other conditions.
[0076] Once an anomaly is confirmed, an alarm event is immediately generated, and alarm information is pushed through configured notification channels such as email, SMS, and DingTalk. This includes the abnormal indicators, related services, the possible scope of impact, and preliminary root cause location suggestions to guide operations and maintenance personnel to quickly intervene and investigate.
[0077] The end-to-end latency of the above steps S1 to S6 is controlled within seconds, ensuring the real-time performance monitoring, anomaly detection and alarms, and meeting the needs of online business for second-level insight.
[0078] When using this invention:
[0079] Data Acquisition Layer - Probes: Deployed on all microservice nodes such as order service, user service, and payment service; probes use Java Agent technology, load when the application starts, automatically intercept calls to key components such as Servlet, Spring MVC, JDBC, and HttpClient, and generate Trace and Span data: TraceID is in UUID-v4 format, and SpanID is in 64-bit integer format, and is asynchronously reported to the data collection endpoint via UDP protocol; the performance loss of probes to applications is ≤3%, and in the test scenario of single service node QPS=10000 and average interface time=200ms, the increase in interface time after deploying probes is ≤6ms; at the same time, by adding Tag key-value pairs such as "businessType=order" and "orderId=123456" in the configuration file, custom indicators of the "order placement" business scenario are collected.
[0080] Data processing layer: includes a log collector - such as Fluentd to receive probe data, a message queue - such as Kafka to buffer high-concurrency data streams - supporting more than 100,000 data entries per second, a stream processing engine - such as Apache Flink to calculate aggregate metrics and correlation links in real time, with aggregation granularity configured at the second level; and an intelligent detection engine that runs a dynamic baseline model based on the Prophet time series prediction algorithm, with a sliding window configured at 5 minutes, an anomaly detection threshold configured at 2 standard deviations, and a historical data retention period configured at 7 days.
[0081] Data storage layer: InfluxDB time series database is used to store aggregated minute-level and second-level metrics - second-level metrics are retained for 7 days and minute-level metrics are retained for 30 days; Elasticsearch cluster is used to store full trace details data, with the retention period for a single trace data set configured to be 7 days.
[0082] Application Presentation Layer: A web-based console that provides real-time service topology diagrams, metric curves, and link query interfaces; the alarm center is responsible for managing alarm rules, silent policies, and notification routes, and supports two notification channels: DingTalk and WeChat Work.
[0083] Specific workflow, combined with Figure 2 :
[0084] A user initiates an "order placement" request, which is then routed to the order service via the API gateway.
[0085] The order service calls the user service to verify user information, calls the payment service to process payment, and finally operates on the database.
[0086] During this process, probes on each service generate Span data:
[0087] It includes TraceID=T1, parent SpanID, current SpanID, service name, interface name, start / end timestamp, status code, duration, etc., and is reported to the data collection endpoint in real time via UDP protocol.
[0088] The stream processing engine, Apache Flink, receives all T1-related Spans, reconstructs them into a complete call chain based on the association between TraceID and SpanID, and calculates the QPS, RT, and error rate of the "order placement interface" and the call latency of "order service -> payment service" in real time at the second-level aggregation granularity.
[0089] The intelligent detection engine reads the real-time stream of "order interface error rate" and compares it with a dynamic baseline learned from data from the same time over the past 7 days - a sliding window of 5 minutes.
[0090] If the current error rate is found to deviate significantly from the baseline—more than 2 standard deviations—an anomaly event is immediately triggered.
[0091] Meanwhile, the engine's correlation analysis revealed that the P99 value of the "payment interface" response time for "payment service" spiked simultaneously, while other service metrics remained normal, thus marking "payment service" as a suspected root cause.
[0092] The alarm module immediately sent an alarm to the operations and maintenance DingTalk group: "Critical: The error rate in the order placement process has suddenly increased to 5.2%, and the suspected root cause is the payment service."
[0093] Affected areas: All order requests. Please investigate immediately.
[0094] Operations personnel can click on the alarm in the console to drill down and view the detailed call chain for T1 and related time periods, quickly discovering that the timeout was caused by a third-party bank interface called by the payment service, and then take targeted action.
[0095] Optimized Implementation Examples - Multi-technology Stack, Multi-metric Correlation
[0096] In another embodiment, the microservice architecture includes
[0097] The system employs two technology stacks: Java (order service, user service) and Go (gateway service, log service). The distributed probe deployment module uses Java Agent technology for Java services and eBPF probe technology for Go services to ensure full data collection coverage across all service nodes. Custom business metrics are displayed through a visual interface, allowing users to select "user login" and "order payment" as the two core business scenarios for performance aggregation monitoring.
[0098] The intelligent anomaly detection module introduces multi-indicator association rule mining, with a sliding window configured to 10 minutes, anomaly judgment threshold configured to 3 standard deviations, and historical data retention period configured to 30 days. It also runs two time series prediction algorithms, Prophet and LSTM, to improve the accuracy of dynamic baseline.
[0099] For example, when the events of "application container memory usage increase" and "JVM Full GC frequency increase" occur successively within a 30-second time window along with "a core interface response time slows down", the system can automatically infer that memory leaks or GC problems may be the root cause of the interface performance degradation, and give a suggestion in the alarm to "check the memory and GC logs of the service instance", making the location more accurate.
[0100] The data storage layer uses TDengine time-series database instead of InfluxDB to store aggregated metrics, and the Elasticsearch cluster is deployed with 3 nodes to improve the query efficiency of trace data; the visualization and alarm module adds an email notification channel, supports configuring alarm priorities P1-P4 according to service level, and realizes hierarchical alarms and accurate push.
[0101] In this embodiment, the end-to-end latency from data acquisition (S1) to alarm triggering (S6) is controlled within 0.5-1 seconds, further improving the real-time monitoring effect and adapting to application scenarios with multiple technology stacks and large-scale microservice clusters.
[0102] Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. All other embodiments obtained by those skilled in the art and related fields based on the embodiments of the present invention without inventive effort should fall within the scope of protection of the present invention. Structures, devices, and operating methods not specifically described and explained in the present invention, unless otherwise specified or limited, shall be implemented according to conventional means in the art.
Claims
1. A real-time performance monitoring system for the entire chain of microservice applications, characterized in that, include: The distributed probe deployment module is used to deploy on microservice application nodes in a low-intrusive manner to collect performance data and call context in real time. The performance loss of the probe is ≤3%. The end-to-end tracing module is used to receive and correlate call chain data with a unified link identifier reported by each probe to reconstruct the complete request call topology; The performance metric aggregation and analysis module is used to perform streaming processing on the data output by the end-to-end tracing module and calculate service-level, topology-level, and instance-level performance metrics in real time. The intelligent anomaly detection module is used to identify performance anomalies and locate suspected root cause services in real time based on dynamic baseline learning and multi-indicator correlation analysis. The real-time data storage module is used to store aggregated performance metrics data and detailed call chain data; The visualization and alarm module is used to display the system performance status and call chain in real time, and to trigger alarms when anomalies occur.
2. The real-time performance monitoring system for the entire microservice application chain according to claim 1, characterized in that, The distributed probe deployment module is implemented using bytecode enhancement technology, sidecar proxy mode, Java Agent technology, or eBPF probe technology. The collected data includes at least: interface call time, status code, SQL execution time, external API call time, and custom business metrics. The custom business metrics are configured by adding tag key-value pairs in the configuration file or by selecting business scenarios in the visual interface.
3. The real-time performance monitoring system for the entire microservice application chain according to claim 1, characterized in that, The intelligent anomaly detection module establishes a dynamic baseline for performance indicators through a time series prediction algorithm, and judges the abnormal state by the deviation between real-time data and the dynamic baseline, combined with a preset rule combination; the time series prediction algorithm is the Prophet algorithm, the ARIMA algorithm, or the LSTM algorithm.
4. The real-time performance monitoring system for the entire microservice application chain according to claim 3, characterized in that, The intelligent anomaly detection module also performs multi-indicator correlation analysis. When multiple preset correlated indicators successively become abnormal within a 30-second time window, an alarm message containing root cause inference is generated. The dynamic baseline is learned and generated in a sliding window mode that can be configured for 5 minutes or 10 minutes, and the anomaly judgment threshold is configurable at 2-3 standard deviations.
5. A real-time performance monitoring system for the entire microservice application chain according to claim 1, characterized in that, The real-time data storage module includes a time-series database and a distributed search database, which are used to store aggregate performance metrics and detailed call chain data, respectively. In the time-series database, second-level metrics are retained for 7 days, minute-level metrics are retained for 30 days, and hour-level metrics are retained for 1 year. The retention period for detailed call chain data is configurable from 7 to 30 days.
6. A method for real-time performance monitoring of the entire microservice application chain according to any one of claims 1-5, characterized in that, Includes the following steps: S1: Real-time collection of call and performance data of each microservice node through distributed probes, with a sampling frequency of milliseconds; S2: The collected data is reported in real time and the entire chain is traced and correlated to restore the complete call chain; S3: Perform streaming aggregation on the associated call chain data and calculate multi-dimensional performance metrics in real time; S4: Real-time anomaly detection and preliminary root cause localization are performed on the performance indicators based on the dynamic baseline; S5: Store the indicator data and call chain data in the corresponding databases respectively; S6: Visualizes real-time performance status and call chain, and triggers alarms when an anomaly is detected; The end-to-end delay of steps S1 to S6 is within seconds.
7. The method for real-time performance detection of the entire microservice application chain according to claim 6, characterized in that, In step S1, a globally unique TraceID is generated for each external request, and the TraceID and the SpanID of the hierarchical relationship are passed during inter-service calls. The TraceID adopts the UUID-v4 format, the SpanID adopts the 64-bit integer format, and the parent and child Spans are associated through the parent SpanID.
8. A method for real-time performance monitoring of the entire microservice application chain according to claim 6, characterized in that, In step S4, the dynamic baseline is a time-varying reference range obtained by machine learning based on historical data of performance indicators and combining periodicity and trend; the historical data retention period is configurable from 7 to 30 days, and the machine learning adopts the Prophet algorithm, ARIMA algorithm or LSTM algorithm.
9. A method for real-time performance monitoring of the entire microservice application chain according to claim 6, characterized in that, In step S6, the alarm information includes abnormal indicators, related services, possible impact scope, and preliminary root cause location suggestions; the alarm is pushed through email, SMS, DingTalk, WeChat Work, or Webhook channels.
10. A method for real-time performance detection of the entire microservice application chain according to claim 6, characterized in that, In step S2, the data reporting adopts an efficient asynchronous method using UDP or asynchronous HTTP 2.0 protocol; in step S3, the streaming aggregation adopts the Apache Flink streaming engine, and the aggregation granularity is configurable at the second or minute level.