Monitoring methods and systems for cross-level traceability

Abstract

This application discloses a cross-level tracing monitoring method and system. The server-side method includes: generating and integrating a globally unique tracing identifier into an external business request to obtain the target business request; transmitting the globally unique tracing identifier in the target business request through each level of the microservice architecture as the target business request flows through a preset multi-level microservice architecture; collecting monitoring data generated when the target business request flows through each level of the microservice architecture; associating the monitoring data with the globally unique tracing identifier to obtain the monitoring data of each level of the microservice architecture; and performing cross-level correlation analysis on the monitoring data of each level of the microservice architecture to identify abnormal patterns and locate the root causes of the abnormal patterns. By using this application, monitoring data isolated at each level can be correlated and integrated through the globally unique tracing identifier, thereby achieving cross-level tracing and root cause location of abnormal events in the system, significantly improving system availability and operational efficiency.

Description

Technical Field

[0001] This application relates to the fields of high-end manufacturing and industrial internet technology, and in particular to a monitoring method and system for cross-level traceability. Background Technology

[0002] With the deep integration of high-end manufacturing and the Industrial Internet, manufacturing processes increasingly rely on the collaborative operation of manufacturing cloud platforms, which consist of equipment layers, edge computing layers, platform service layers, and application management layers. When the management layer issues an instruction, the instruction is decomposed by the platform service layer and then distributed to thousands of device controllers for execution via the edge gateway layer. During this process, anomalies at any level can trigger cascading failures, ultimately leading to production line interruptions. Therefore, achieving real-time monitoring and intelligent early warning across the entire supply chain and across all levels is a key requirement for ensuring the high availability and stability of modern manufacturing.

[0003] Currently, monitoring relies primarily on traditional centralized log collection, performance metric acquisition, and threshold-based alerting mechanisms. However, due to the multi-tiered microservice architecture adopted by manufacturing cloud platforms, requests flow between multiple services, making current monitoring methods unable to cross microservice boundaries. This results in information breakdown and difficulty in tracing the source of errors. Furthermore, alerting mechanisms dependent on single points and static thresholds cannot effectively identify complex anomaly patterns arising from cross-level and multi-metric spatiotemporal correlations, leading to frequent false negatives.

[0004] Therefore, how to perform full-link monitoring of business requests under a multi-level microservice architecture and accurately identify and locate the root causes of cross-level abnormal patterns is a technical problem that urgently needs to be solved. Summary of the Invention

[0005] This application provides a monitoring method and system for cross-level traceability. To provide a basic understanding of some aspects of the disclosed embodiments, a brief summary is given below. This summary is not intended as a general commentary, nor is it intended to identify key / important components or describe the scope of protection of these embodiments. Its sole purpose is to present some concepts in a simple form as a prelude to the detailed description that follows.

[0006] Firstly, embodiments of this application provide a cross-level tracing monitoring method, applied to a server, the method comprising: Upon receiving an external business request from a client, a globally unique tracking identifier is generated and incorporated into the external business request to obtain the target business request; During the process of the target business request flowing through the preset multi-level microservice architecture, the globally unique tracking identifier in the target business request is automatically passed through each level of the microservice architecture. Collect monitoring data generated when target business requests flow through each layer of the microservice architecture; By associating monitoring data with globally unique tracking identifiers, monitoring data for each level of the microservice architecture can be obtained. Perform cross-level correlation analysis on monitoring data of microservice architecture at each level to identify abnormal patterns and locate the root causes of these abnormal patterns.

[0007] Optionally, a globally unique tracking identifier is generated and incorporated into the external business request to obtain the target business request, including: Parse external business requests to obtain parsed data; From the parsed data, obtain multiple random factors, which include at least the current first timestamp, machine identifier, process identifier, and sequence number; Multiple random factors are combined and encoded to obtain a composite code, which serves as a globally unique tracking identifier. The target business request is obtained by injecting a globally unique tracking identifier into the metadata of the external business request.

[0008] Optionally, the globally unique tracking identifier in the target business request can be automatically passed across all levels of the microservice architecture, including: During the process of a target business request initiating a call from the current layer microservice to the downstream layer microservice, a globally unique tracing identifier is extracted from the current execution context information; where the current layer microservice and the downstream layer microservice are adjacent microservice architectures in a preset multi-level microservice architecture; Inject a globally unique tracing identifier into the request metadata of a service call so that the globally unique tracing identifier is passed down to downstream microservices along with the service call; When a downstream microservice receives a service call, it extracts a globally unique tracking identifier from the request metadata and sets the globally unique identifier as the execution context information of the downstream microservice itself.

[0009] Optionally, cross-level correlation analysis can be performed on monitoring data of each layer of the microservice architecture to identify anomalous patterns and pinpoint their root causes, including: The monitoring data of each layer of the microservice architecture are integrated to obtain the cross-layer call topology diagram corresponding to the target business request; the cross-layer call topology diagram is used to represent the call dependency relationship between each layer of microservices through which the target business request flows; Spatiotemporal correlation pattern analysis is performed based on cross-level call topology graphs to identify whether there are cross-level abnormal patterns; In the presence of cross-level anomaly patterns, reverse backtracking analysis is performed along the cross-level call topology to determine the propagation path of the anomaly indicators in the cross-level call topology. Based on the propagation path, the root cause of the abnormal pattern is located to the specific layer and specific microservice node in the call topology graph.

[0010] Optionally, monitoring data from each layer of the microservice architecture can be integrated to obtain a cross-layer call topology diagram corresponding to the target business request, including: Extract context information representing the microservice call relationship from the monitoring data of each level of the microservice architecture; the context information includes at least a parent span identifier for identifying the source of the call and a current span identifier for identifying the current call. Based on the parent-child dependency relationship between the parent span identifier and the current span identifier, a directed graph is constructed for all microservice nodes through which the target business request flows; where each microservice node corresponds to a current span identifier, and the directed edges between nodes are determined by the pointing relationship between the parent span identifier and the current span identifier. The monitoring data corresponding to each microservice node is mounted to the corresponding node in the directed graph based on the globally unique tracking identifier and the current span identifier, so as to generate a cross-level call topology graph containing the complete call chain and monitoring data.

[0011] Optionally, spatiotemporal correlation pattern analysis can be performed based on cross-level call topology graphs to identify whether cross-level anomalous patterns exist, including: From the cross-level call topology graph, traverse and obtain multi-dimensional time-series monitoring data of at least two different microservice nodes; among which, the multi-dimensional time-series monitoring data includes at least performance metrics; Based on multi-dimensional time-series monitoring data from at least two different microservice nodes, identify whether there are abnormal indicator changes that are correlated in the time dimension and span at least two levels in the spatial dimension. Treat any abnormal changes in indicators as cross-level anomaly patterns. Among them, the abnormal indicator change is different from the alarm mode when a single indicator of any node exceeds the preset static threshold.

[0012] Optionally, based on multi-dimensional time-series monitoring data from at least two different microservice nodes, identify whether there are anomalous metric changes that are correlated in the time dimension and span at least two levels in the spatial dimension, including: For multi-dimensional time-series monitoring data of at least two different microservice nodes, calculate the deviation of the performance indicators of each microservice node from its historical baseline within the corresponding time window. Correlation analysis is performed on multiple deviation sequences to determine whether there is a positive or negative linkage relationship among them that meets a preset correlation threshold. When there is a linkage relationship and the nodes involved in the linkage relationship are spatially distributed across at least two different levels in the cross-level call topology, it is determined that there is an abnormal indicator change that is correlated in the time dimension and spans at least two levels in the spatial dimension.

[0013] Optionally, based on the propagation path, the root cause of the abnormal pattern can be located to a specific layer and microservice node in the call topology graph, including: In the cross-level call topology diagram, determine the starting node of the propagation path, and obtain the time-series monitoring data of each affected node sequentially along the propagation path starting from the starting node; Compare the performance indicators in the time-series monitoring data of each affected node with their historical baseline to determine the starting point, magnitude, and rate of change of the time-series deviation; By analyzing the starting point, magnitude, and rate of change of the time sequence deviation, the final microservice node that first deviates in time sequence and is located at the upstream call position in the propagation path is identified. The final microservice node is determined as the specific microservice node in the abnormal mode; The specific layer to which a particular microservice node belongs is used as the specific layer of the abnormal mode.

[0014] Optionally, collect monitoring data generated as target business requests flow through each layer of the microservice architecture, including: By using a lightweight data collection probe pre-installed in a pre-defined multi-level microservice architecture, at least one of the following data is collected synchronously during the processing of the target business request: Performance metrics data should include at least CPU utilization, memory usage, interface response time, and network input / output. Runtime log data contains information output by the microservice architecture that records its running status or business events; Call event data is used to record the start, end, result status, and time consumption of inter-service calls.

[0015] Secondly, embodiments of this application provide a monitoring system for cross-level tracing, the system comprising: The globally unique tracking identifier injection module is used to generate and incorporate a globally unique tracking identifier into the external business request when it receives an external business request sent by the client, so as to obtain the target business request. The Globally Unique Tracking Identifier Transmission Module is used to automatically transmit the globally unique tracking identifier in the target business request across each level of the microservice architecture as the target business request flows through the preset multi-level microservice architecture. The monitoring data acquisition module is used to collect monitoring data generated when target business requests flow through each layer of the microservice architecture. The parameter association module is used to associate monitoring data with globally unique tracking identifiers to obtain monitoring data for each level of the microservice architecture. The root cause identification and localization module is used to perform cross-level correlation analysis on monitoring data of microservice architecture at each level in order to identify abnormal patterns and locate the root causes of abnormal patterns.

[0016] The technical solutions provided in this application embodiment may include the following beneficial effects: In this embodiment, on the one hand, by generating a globally unique tracking identifier for each external business request and automatically passing it in all subsequent service calls, it ensures that all monitoring data generated by the same business at different levels can be associated with this unique identifier. The system can construct a complete cross-level call topology based on the globally unique tracking identifier, intuitively displaying all service dependencies from management layer instructions to device layer execution. When an anomaly occurs, the propagation path of the anomaly in the entire link can be quickly traced based on this identifier, achieving full-link visibility and accurate source tracing. On the other hand, the cross-level call topology contains multi-dimensional time-series monitoring data from multiple nodes. These data are sequentially related in time and propagate spatially, enabling the system to accurately identify anomaly propagation patterns, significantly reducing false alarms caused by isolated judgments and significantly improving the detection rate of hidden, progressive faults. Furthermore, based on the full-link monitoring data linked by the globally unique identifier, the system can compare the differences between the current link indicators and the baseline pattern in real time, providing complete contextual data support for rapid fault diagnosis and root cause localization, significantly improving the observability and operational efficiency of the distributed system.

[0017] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0019] Figure 1 This is a schematic diagram of the method flow of a cross-level tracing monitoring method provided in an embodiment of this application; Figure 2 This is a schematic diagram of a globally unique tracking identifier in a scenario provided by an embodiment of this application; Figure 3 This is a schematic diagram illustrating the process of generating and incorporating a globally unique tracking identifier into an external request, as provided in an embodiment of this application. Figure 4 This is a schematic diagram illustrating the process of automatically transmitting a globally unique tracking identifier, as provided in an embodiment of this application. Figure 5 This is a cross-level call topology diagram for an application scenario provided in this application embodiment; Figure 6 This is a schematic diagram illustrating a cross-level topology graph generation process provided in an embodiment of this application; Figure 7 This is a schematic diagram of a cross-level anomaly pattern recognition process provided in an embodiment of this application; Figure 8 This is a schematic diagram of a root cause node identification process provided in an embodiment of this application; Figure 9 This is a schematic diagram illustrating the result displayed by the client in one scenario provided by an embodiment of this application; Figure 10 This is a schematic diagram of the structure of a cross-level traceability monitoring system provided in an embodiment of this application; Figure 11 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0020] The following description and accompanying drawings fully illustrate specific embodiments of this application to enable those skilled in the art to practice them.

[0021] It should be understood that the described embodiments are merely some, not all, of the embodiments in this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.

[0022] In the following description, when referring to the accompanying drawings, the same numbers in different drawings denote the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of systems and methods consistent with some aspects of this application as detailed in the appended claims.

[0023] In the description of this application, it should be understood that the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances. Furthermore, in the description of this application, unless otherwise stated, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship.

[0024] Currently, manufacturing cloud platforms mainly rely on traditional centralized log collection, performance indicator acquisition, and threshold-based alarm mechanisms for monitoring.

[0025] The inventors of this application recognized that, due to the multi-level microservice architecture adopted by manufacturing cloud platforms, requests flow between multiple services, and current monitoring methods cannot cross microservices, resulting in information not being interconnected and unable to be traced. Secondly, alarm mechanisms relying on single points and static thresholds cannot effectively identify complex anomaly patterns composed of spatiotemporal correlations between multiple levels and indicators, leading to frequent missed alarms. Finally, the inability to anticipate risk trends and issue warnings before actual failures prevents the system from implementing automated risk avoidance or intervention measures before critical operations, easily causing production interruptions.

[0026] To address the aforementioned issues, this application provides a cross-level tracing monitoring method and system to resolve the problems existing in the related technical issues. In the embodiments of this application, on the one hand, by generating a globally unique tracing identifier for each external business request and automatically passing it in all subsequent service calls, it ensures that all monitoring data generated by the same business at different levels can be associated with this unique identifier. The system can construct a complete cross-level call topology based on the globally unique tracing identifier, intuitively displaying all service dependencies from management layer instructions to device layer execution. When an anomaly occurs, the propagation path of the anomaly in the entire link can be quickly traced based on this identifier, achieving full-link visibility and accurate tracing. On the other hand, the cross-level call topology contains multi-dimensional time-series monitoring data from multiple nodes. These data have temporal correlation and spatial propagation relationships, enabling the system to accurately identify anomaly propagation patterns, significantly reducing false alarms caused by isolated judgments, and significantly improving the detection rate of hidden, progressive faults. On the other hand, based on the end-to-end monitoring data linked by globally unique identifiers, the system can compare the differences between the current link indicators and the baseline pattern in real time, and provide complete contextual data support for rapid fault diagnosis and root cause localization, significantly improving the observability and operational efficiency of the distributed system. The following is a detailed description using exemplary embodiments.

[0027] The following will be combined with the appendix Figure 1 - Appendix Figure 9 This application provides a detailed description of the cross-level tracing monitoring method provided in its embodiments. This method can be implemented using a computer program and can run on a cross-level tracing monitoring system based on the von Neumann architecture. The computer program can be integrated into an application or run as a standalone utility application.

[0028] Please see Figure 1 This is a flowchart illustrating a cross-level tracing monitoring method provided in this application, applied to the server side. For example... Figure 1As shown, the method in this application embodiment includes the following steps: S101, When the server receives an external business request sent by the client, it generates and incorporates a globally unique tracking identifier into the external business request to obtain the target business request; In this system, the server is a collection of microservices that collaborate to complete a business request. The client is a program or terminal that initiates a request to the server. An external business request is an instruction or call initiated from the client to perform a specific business operation. For example, a software update or firmware upgrade instruction from a management system for a production line. A globally unique trace identifier is an absolutely unique string within the distributed system, used to uniquely identify a specific business request. This identifier follows the request throughout its lifecycle, traversing all service layers, and is used to subsequently correlate and connect all related monitoring data. For example, a globally unique trace identifier in one scenario might be... Figure 2 As shown, the request type in this scenario is firmware upgrade.

[0029] In some embodiments of this application, the specific process of generating and incorporating a globally unique tracking identifier into an external business request to obtain a target business request includes: parsing the external business request to obtain parsed data; obtaining multiple random factors from the parsed data, wherein the multiple random factors include at least the current first timestamp, machine identifier, process identifier, and sequence number; combining and encoding the multiple random factors to obtain a composite code as a globally unique tracking identifier; and injecting the globally unique tracking identifier into the metadata of the external business request to obtain the target business request.

[0030] The random factor is a fundamental component in generating unique identifiers. By combining these factors, it is ensured that IDs generated in a distributed environment are not duplicated. The machine identifier is the unique ID of the physical server where the service is deployed. The process identifier is the unique ID (such as a PID) of the process running this service on the server. The sequence number is an incrementing sequence number within the same time unit (such as milliseconds), used to distinguish multiple requests generated by the same process at the same time. Metadata is data that describes data; in HTTP requests, it refers to the request header.

[0031] In one possible implementation, a factory's MES system (client) sends a command to the cloud platform gateway (server): "Upgrade the firmware of robot L001 on production line to V2.0." The original request is an HTTP POST request with the URL / api / v1 / firmware / upgrade and a Body containing {"line": "L001", "version": "V2.0"}. Upon receiving the request, the gateway parses the following: Header: Content-Type: application / json, Body: {"line":"L001", "version": "V2.0"}, Method: POST. The gateway extracts the following factors from the parsed data: first timestamp: 1713691234567 (milliseconds of the request arriving at the gateway), machine identifier: GW-Node-01 (the ID of this node in the gateway cluster), process identifier: 8080 (the port number on which the gateway service runs), and sequence number: 001 (this is the first request within this millisecond). Combining the above factors according to the rule of [timestamp]-[machine]-[process]-[serial number] yields: Globally Unique Trace Identifier = "1713691234567-GW-Node-01-8080-001". The final gateway writes this globally unique trace identifier into external service requests to obtain the target service request, for example: POST / api / v1 / firmware / upgrade HTTP / 1.1; Content-Type: application / json; X-Trace-ID: 1713691234567-GW-Node-01-8080-001#<- Injected identifier; {"line": "L001", "version": "V2.0"}# The original business data remains unchanged.

[0032] For example Figure 3 As shown, Figure 3 This is a schematic diagram illustrating the process of generating and incorporating a globally unique trace identifier into an external request, as provided in this application. First, the system receives an external business request from a client; then, it parses the request to obtain request data; next, it extracts multiple random factors such as timestamp, machine identifier, process identifier, and sequence number from the parsed data; then, it combines and encodes these random factors to generate a globally unique trace identifier (Trace ID); finally, it injects this Trace ID into the request's metadata; and finally, it forms a target business request carrying the trace identifier.

[0033] S102, During the process of the target business request flowing through the preset multi-level microservice architecture, the server automatically transmits the globally unique tracking identifier in the target business request to each level of the microservice architecture. The pre-defined multi-level microservice architecture is a system structure comprised of multiple microservices with different functions and levels, pre-defined and deployed before monitoring implementation. The system structure includes a management layer, a platform service layer, an edge gateway layer, and a device layer. Management layer: Application management, business decision-making (e.g., ERP, MES). Platform service layer: Core business logic microservices (e.g., firmware management, device management). Edge gateway layer: The middleware layer responsible for protocol conversion, edge computing, and traffic distribution. Device layer: Physical devices, controllers, and their proxy services. Each level of the microservice architecture is a specific service node belonging to a different level within the pre-defined multi-level microservice architecture.

[0034] In some embodiments of this application, the specific process of automatically transmitting the globally unique tracking identifier in the target business request across different levels of the microservice architecture includes: extracting the globally unique tracking identifier from the current execution context information during the process of the target business request initiating a call from the current level microservice to the downstream level microservice; wherein the current level microservice and the downstream level microservice are adjacent microservice architectures in a preset multi-level microservice architecture; injecting the globally unique tracking identifier into the request metadata of the service call so that the globally unique tracking identifier is transmitted to the downstream level microservice along with the service call; when the downstream level microservice receives the service call, extracting the globally unique tracking identifier from the request metadata and setting the globally unique identifier as the execution context information of the downstream level microservice itself.

[0035] In one possible implementation, assume a firmware upgrade request flows through: API Gateway (L2) -> Firmware Management Service (L3) -> Device Management Service (L3) -> Edge Service (L4). In the Firmware Management Service: the TraceID is extracted from its current execution context. When calling the Device Management Service, the TraceID is injected into the request metadata (HTTP Header) and sent. In the Device Management Service: the request is received, and the TraceID is extracted from the request metadata. This TraceID is set to its own execution context (processing business logic, logging, and metrics are all automatically associated with this TraceID). If a call to the Edge Service is needed, the TraceID is extracted from its own context and injected into the request metadata for the next call, and so on.

[0036] For example Figure 4 As shown, Figure 4This is a schematic diagram illustrating the process of automatically passing a globally unique trace identifier provided in this application. First, the system extracts an existing Trace ID from the current execution context. Then, it injects the Trace ID into the metadata of the call request initiated to the downstream microservice, achieving cross-service transmission. After receiving the request, the downstream microservice retrieves the Trace ID from the request metadata and sets it as its own execution context, ensuring that the downstream service and subsequent calls can continue to use the ID. At this point, the system determines whether there are any downstream layers. If so, it loops through the extraction → injection → transmission → setting process, allowing the Trace ID to penetrate all layers. When there are no more downstream layers, the process terminates.

[0037] S103, The server collects monitoring data generated when the target business request flows through each layer of the microservice architecture; In some embodiments of this application, the specific process of collecting monitoring data generated when a target business request flows through each level of the microservice architecture includes: using a lightweight data collection probe pre-installed in the preset multi-level microservice architecture, simultaneously collecting at least one of the following data during the processing of the target business request: performance indicator data, which includes at least CPU utilization, memory usage, interface response time, and network input / output; runtime log data, which contains information output by the microservice architecture that records its runtime status or business events; and call event data, which records the start, end, result status, and time consumption of inter-service calls.

[0038] S104, the server associates the monitoring data with a globally unique tracing identifier to obtain the monitoring data of each level of the microservice architecture; In one possible implementation, taking a firmware upgrade request for production line equipment as an example, the globally unique trace ID (TraceID) is known to be 1713691234567-GW-Node-01-8080-001. The request flow path is: client → API gateway → firmware management service → edge computing node → device controller. When the request carrying the above TraceID flows through each service, the probes of each service will collect raw, isolated monitoring data. For example, the API gateway logs "Received firmware upgrade request for device: Robot-A001". The firmware management service collects a performance metric: CPU utilization: 78%. The edge computing node records a call event: "Called devicecontroller, latency: 150ms". The device controller records an error log: "Firmware versioncheck failed". Before or simultaneously with each data collection and preparation for reporting to the central storage system, the collection probe performs a crucial operation: automatically retrieving the globally unique trace ID of this request from the execution context of the current service. Add this identifier as an inseparable field to the monitoring data record that will be reported.

[0039] Finally, after correlation, the final result is: {"message":"Received firmware upgrade request for device: Robot-A001","trace_id":"1713691234567-GW-Node-01-8080-001", "service":"api-gateway",…}; {"metric":"cpu_usage","value":78,"trace_id":"1713691234567-GW-Node-01-8080-001","service": "firmware-mgmt", …}; {"event":"rpc_call","target":"device-controller","latency": 150,"trace_id": "1713691234567-GW-Node-01-8080-001", "service": "edge-node", …}; {"level":"ERROR","message":"Firmware version check failed","trace_id":"1713691234567-GW-Node-01-8080-001","service":"device-controller", …}.

[0040] It should be noted that all four sets of data mentioned above are marked with the same TraceID. Although they come from different microservices at different levels (gateway layer, service layer, edge layer, and device layer), the system can instantly retrieve them all through this common trace_id field and recombine them into a complete, cross-level data view describing this specific firmware upgrade request.

[0041] S105, the server performs cross-level correlation analysis on the monitoring data of each level of the microservice architecture to identify abnormal patterns and locate the root cause of the abnormal patterns.

[0042] In some embodiments of this application, the specific process of performing cross-level correlation analysis on monitoring data of microservice architecture at each level to identify abnormal patterns and locate the root cause of abnormal patterns includes: integrating the monitoring data of microservice architecture at each level to obtain a cross-level call topology diagram corresponding to the target business request; wherein, the cross-level call topology diagram is used to characterize the call dependency relationship between microservices at each level through which the target business request flows; performing spatiotemporal correlation pattern analysis based on the cross-level call topology diagram to identify whether there are cross-level abnormal patterns; in the case of cross-level abnormal patterns, performing reverse backtracking analysis along the cross-level call topology diagram to determine the propagation path of the abnormal indicators in the cross-level call topology diagram; and locating the root cause of the abnormal pattern to the specific level and specific microservice node in the call topology diagram according to the propagation path.

[0043] The propagation path is that in the cross-level call topology graph, the root cause node triggers the anomaly, and through the inter-service call relationship, it gradually affects and spreads to one or more downstream nodes, eventually forming an ordered sequence of nodes and edges through which the anomaly has passed.

[0044] In some embodiments of this application, the specific process of integrating monitoring data from each level of the microservice architecture to obtain a cross-level call topology graph corresponding to a target business request includes: extracting context information representing the microservice call relationship from the monitoring data of each level of the microservice architecture; wherein the context information includes at least a parent span identifier for identifying the call source and a current span identifier for identifying the current call; constructing a directed graph of all microservice nodes through which the target business request flows, based on the parent-child dependency relationship between the parent span identifier and the current span identifier; wherein each microservice node corresponds to a current span identifier, and the directed edges between nodes are determined by the pointing relationship between the parent span identifier and the current span identifier; mounting the monitoring data corresponding to each microservice node to the corresponding node in the directed graph based on the globally unique tracking identifier and the current span identifier, to generate a cross-level call topology graph containing a complete call chain and monitoring data. One example of a cross-level call topology graph in an application scenario is... Figure 5 As shown.

[0045] For example Figure 6 As shown, Figure 6 This application provides a schematic diagram of the process for generating a cross-level call topology graph. First, monitoring data is collected in parallel from three dimensions: performance metrics (such as CPU, memory, and response time), runtime logs (operation records and error information during service runtime), and call events (events such as the triggering and termination of calls between services). These data are then aggregated to form a unified monitoring data set. Next, the cross-level call topology graph construction phase begins: parent-child span identifiers (used to mark the parent-child relationship of service calls) are extracted from the monitoring data, and then a directed graph is constructed based on these identifiers (with nodes representing microservices and directed edges representing call relationships). Subsequently, the collected monitoring data is mounted onto the corresponding graph nodes (associating the monitoring data of each microservice node with its position in the topology structure). Finally, based on the graph structure with data mounting, a cross-level call topology graph is generated, intuitively presenting the call dependencies between microservices at each level through which the target business request flows and the association with the corresponding monitoring data, providing a visual and structured foundation for subsequent analysis.

[0046] In some embodiments of this application, the specific process of performing spatiotemporal correlation pattern analysis based on cross-level call topology graphs to identify the existence of cross-level abnormal patterns includes: traversing and obtaining multi-dimensional time-series monitoring data of at least two different microservice nodes from the cross-level call topology graph; wherein, the multi-dimensional time-series monitoring data includes at least performance indicators; identifying whether there are abnormal indicator changes that are correlated in the time dimension and span at least two levels in the spatial dimension based on the multi-dimensional time-series monitoring data of at least two different microservice nodes; taking the abnormal indicator changes as cross-level abnormal patterns; wherein, the abnormal indicator changes are different from the alarm pattern where a single indicator of any node exceeds a preset static threshold.

[0047] Specifically, the process of identifying abnormal indicator changes that are correlated in the time dimension and span at least two levels in the spatial dimension, based on multidimensional time-series monitoring data from at least two different microservice nodes, includes: calculating the deviation of the performance indicators of each microservice node from its historical baseline within the corresponding time window for the multidimensional time-series monitoring data from at least two different microservice nodes; performing correlation analysis on multiple deviation sequences to determine whether there is a positive or negative linkage relationship between the multiple deviation sequences that meets a preset correlation threshold; and determining that abnormal indicator changes that are correlated in the time dimension and span at least two levels in the spatial dimension have occurred when there is a linkage relationship and the nodes involved in the linkage relationship are spatially distributed at at least two different levels in the cross-level call topology.

[0048] For example Figure 7 As shown, Figure 7 This application provides a schematic diagram of a cross-level anomaly pattern recognition process. First, monitoring data from microservices at different levels is integrated. Next, this integrated multi-node time-series data (metric data changing over time) is traversed. Then, the deviation of each performance metric is calculated (measuring the degree of difference between the metric and the normal state). Afterward, deviation sequence correlation analysis is performed (analyzing whether there are correlation patterns in the deviation data of different nodes and at different times). The process then proceeds to a judgment stage: first, it is determined whether there is a linkage relationship (i.e., whether the deviations of multiple nodes / multiple metrics change in tandem). If not, it is determined to be a normal pattern. If a linkage relationship exists, it is further determined whether this linkage spans at least two levels (i.e., whether the anomaly propagates between services at different levels). If it does not span at least two levels, it is also determined to be a normal pattern. If it spans at least two levels, it is identified as a cross-level anomaly pattern. This process achieves accurate identification of cross-level anomaly patterns or exclusion of normal patterns.

[0049] In some embodiments of this application, the specific process of locating the root cause of an abnormal mode to a specific level and specific microservice node in the call topology graph according to the propagation path includes: determining the starting node of the propagation path in the cross-level call topology graph, and sequentially obtaining the timing monitoring data of each affected node along the propagation path starting from the starting node; comparing the performance indicators and their historical baselines in the timing monitoring data of each affected node to determine the timing deviation starting point, deviation magnitude, and rate of change; identifying the final microservice node that first deviated in timing and is located at the upstream call position in the propagation path based on the timing deviation starting point, deviation magnitude, and rate of change; determining the final microservice node as the specific microservice node of the abnormal mode; and taking the level to which the specific microservice node belongs as the specific level of the abnormal mode.

[0050] For example Figure 8 As shown, Figure 8 This application provides a schematic diagram of a root cause node identification process. First, based on monitoring data and topology analysis, cross-level anomaly patterns are identified (i.e., confirming the existence of service call anomalies across multiple levels). Next, the propagation path is traced back along the cross-level call topology (tracing the transmission route of the anomaly from the downstream node affected by the anomaly). Then, data on the affected nodes is obtained (collecting monitoring data such as performance metrics and logs of each node along the path). After that, the deviation starting point and magnitude are analyzed (determining which node the anomaly started from and how much it deviated from the normal state). Then, by comparing the deviation starting order of each node, the upstream deviation node (i.e., the source node where the anomaly initially occurred) is located. Finally, the root cause is output, clarifying the specific level and specific microservice node where the root cause of the anomaly is located.

[0051] In some embodiments of this application, after identifying an abnormal pattern and locating its root cause, the identification result can be visualized and encapsulated, and the visualized result can be sent to the client for display. One scenario where the client displays the result is as follows: Figure 9 As shown.

[0052] In this embodiment, on the one hand, by generating a globally unique tracking identifier for each external business request and automatically passing it in all subsequent service calls, it ensures that all monitoring data generated by the same business at different levels can be associated with this unique identifier. The system can construct a complete cross-level call topology based on the globally unique tracking identifier, intuitively displaying all service dependencies from management layer instructions to device layer execution. When an anomaly occurs, the propagation path of the anomaly in the entire link can be quickly traced based on this identifier, achieving full-link visibility and accurate source tracing. On the other hand, the cross-level call topology contains multi-dimensional time-series monitoring data from multiple nodes. These data are sequentially related in time and propagate spatially, enabling the system to accurately identify anomaly propagation patterns, significantly reducing false alarms caused by isolated judgments and significantly improving the detection rate of hidden, progressive faults. Furthermore, based on the full-link monitoring data linked by the globally unique identifier, the system can compare the differences between the current link indicators and the baseline pattern in real time, providing complete contextual data support for rapid fault diagnosis and root cause localization, significantly improving the observability and operational efficiency of the distributed system.

[0053] The following are system embodiments of this application, which can be used to execute the method embodiments of this application. For details not disclosed in the system embodiments of this application, please refer to the method embodiments of this application.

[0054] Please see Figure 10 This illustration shows a schematic diagram of a cross-level tracing monitoring system provided in an exemplary embodiment of this application. This cross-level tracing monitoring system can be implemented as all or part of an electronic device through software, hardware, or a combination of both. System 1 includes a globally unique tracking identifier injection module 10, a globally unique tracking identifier transmission module 20, a monitoring data acquisition module 30, a parameter association module 40, and a root cause identification and location module 50.

[0055] The globally unique tracking identifier injection module 10 is used to generate and incorporate a globally unique tracking identifier into the external business request when it receives an external business request sent by the client, so as to obtain the target business request. The globally unique tracing identifier transmission module 20 is used to automatically transmit the globally unique tracing identifier in the target business request in each level of the microservice architecture as the target business request flows through the preset multi-level microservice architecture. The monitoring data acquisition module 30 is used to collect monitoring data generated when the target business request flows through each layer of the microservice architecture. The parameter association module 40 is used to associate monitoring data with globally unique tracking identifiers to obtain monitoring data for each level of the microservice architecture. The root cause identification and localization module 50 is used to perform cross-level correlation analysis on monitoring data of microservice architecture at each level in order to identify abnormal patterns and locate the root causes of abnormal patterns.

[0056] It should be noted that the cross-level tracing monitoring system provided in the above embodiments is only illustrated by the division of the above functional modules when executing the cross-level tracing monitoring method. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the cross-level tracing monitoring system and the cross-level tracing monitoring method embodiments provided in the above embodiments belong to the same concept, and the implementation process is detailed in the method embodiments, which will not be repeated here.

[0057] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0058] In this embodiment, on the one hand, by generating a globally unique tracking identifier for each external business request and automatically passing it in all subsequent service calls, it ensures that all monitoring data generated by the same business at different levels can be associated with this unique identifier. The system can construct a complete cross-level call topology based on the globally unique tracking identifier, intuitively displaying all service dependencies from management layer instructions to device layer execution. When an anomaly occurs, the propagation path of the anomaly in the entire link can be quickly traced based on this identifier, achieving full-link visibility and accurate source tracing. On the other hand, the cross-level call topology contains multi-dimensional time-series monitoring data from multiple nodes. These data are sequentially related in time and propagate spatially, enabling the system to accurately identify anomaly propagation patterns, significantly reducing false alarms caused by isolated judgments and significantly improving the detection rate of hidden, progressive faults. Furthermore, based on the full-link monitoring data linked by the globally unique identifier, the system can compare the differences between the current link indicators and the baseline pattern in real time, providing complete contextual data support for rapid fault diagnosis and root cause localization, significantly improving the observability and operational efficiency of the distributed system.

[0059] This application also provides a computer-readable medium having program instructions stored thereon, which, when executed by a processor, implement the cross-level tracing monitoring method provided in the above-described method embodiments.

[0060] This application also provides a computer program product containing instructions that, when run on a computer, cause the computer to execute the cross-level tracing monitoring method of the various method embodiments described above.

[0061] Please see Figure 11 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 11As shown, the electronic device 1000 may include a memory 1001. Various functions of the electronic device 1000 and data processing are performed by running or executing instructions, programs, code sets, or instruction sets stored in the memory 1001, and by calling data stored in the memory 1001.

[0062] The memory 1001 may include random access memory (RAM) or read-only memory. Optionally, the memory 1001 may include a non-transitory computer-readable storage medium. The memory 1001 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 1001 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Figure 11 As shown, the memory 1001, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and a monitoring application for cross-level traceability.

[0063] exist Figure 11 In the electronic device 1000 shown, the cross-level traceability monitoring application stored in memory 1001 is invoked, and the following operations are performed: Upon receiving an external business request from a client, a globally unique tracking identifier is generated and incorporated into the external business request to obtain the target business request; During the process of the target business request flowing through the preset multi-level microservice architecture, the globally unique tracking identifier in the target business request is automatically passed through each level of the microservice architecture. Collect monitoring data generated when target business requests flow through each layer of the microservice architecture; By associating monitoring data with globally unique tracking identifiers, monitoring data for each level of the microservice architecture can be obtained. Perform cross-level correlation analysis on monitoring data of microservice architecture at each level to identify abnormal patterns and locate the root causes of these abnormal patterns.

[0064] In one embodiment, when the processor 1001 generates and incorporates a globally unique tracking identifier into an external business request to obtain the target business request, it specifically performs the following operations: Parse external business requests to obtain parsed data; From the parsed data, obtain multiple random factors, which include at least the current first timestamp, machine identifier, process identifier, and sequence number; Multiple random factors are combined and encoded to obtain a composite code, which serves as a globally unique tracking identifier. The target business request is obtained by injecting a globally unique tracking identifier into the metadata of the external business request.

[0065] In one embodiment, when processor 1001 automatically propagates the globally unique tracking identifier in the target business request across the microservice architecture at each level, it specifically performs the following operations: During the process of a target business request initiating a call from the current layer microservice to the downstream layer microservice, a globally unique tracing identifier is extracted from the current execution context information; where the current layer microservice and the downstream layer microservice are adjacent microservice architectures in a preset multi-level microservice architecture; Inject a globally unique tracing identifier into the request metadata of a service call so that the globally unique tracing identifier is passed down to downstream microservices along with the service call; When a downstream microservice receives a service call, it extracts a globally unique tracking identifier from the request metadata and sets the globally unique identifier as the execution context information of the downstream microservice itself.

[0066] In one embodiment, when processor 1001 performs cross-level correlation analysis on monitoring data of microservice architecture at each level to identify abnormal patterns and locate the root cause of the abnormal patterns, it specifically performs the following operations: The monitoring data of each layer of the microservice architecture are integrated to obtain the cross-layer call topology diagram corresponding to the target business request; the cross-layer call topology diagram is used to represent the call dependency relationship between each layer of microservices through which the target business request flows; Spatiotemporal correlation pattern analysis is performed based on cross-level call topology graphs to identify whether there are cross-level abnormal patterns; In the presence of cross-level anomaly patterns, reverse backtracking analysis is performed along the cross-level call topology to determine the propagation path of the anomaly indicators in the cross-level call topology. Based on the propagation path, the root cause of the abnormal pattern is located to the specific layer and specific microservice node in the call topology graph.

[0067] In one embodiment, when processor 1001 integrates monitoring data from various levels of the microservice architecture to obtain a cross-level call topology diagram corresponding to the target business request, it specifically performs the following operations: Extract context information representing the microservice call relationship from the monitoring data of each level of the microservice architecture; the context information includes at least a parent span identifier for identifying the source of the call and a current span identifier for identifying the current call. Based on the parent-child dependency relationship between the parent span identifier and the current span identifier, a directed graph is constructed for all microservice nodes through which the target business request flows; where each microservice node corresponds to a current span identifier, and the directed edges between nodes are determined by the pointing relationship between the parent span identifier and the current span identifier. The monitoring data corresponding to each microservice node is mounted to the corresponding node in the directed graph based on the globally unique tracking identifier and the current span identifier, so as to generate a cross-level call topology graph containing the complete call chain and monitoring data.

[0068] In one embodiment, when processor 1001 performs spatiotemporal correlation pattern analysis based on cross-level call topology graphs to identify whether cross-level anomalous patterns exist, it specifically performs the following operations: From the cross-level call topology graph, traverse and obtain multi-dimensional time-series monitoring data of at least two different microservice nodes; among which, the multi-dimensional time-series monitoring data includes at least performance metrics; Based on multi-dimensional time-series monitoring data from at least two different microservice nodes, identify whether there are abnormal indicator changes that are correlated in the time dimension and span at least two levels in the spatial dimension. Treat any abnormal changes in indicators as cross-level anomaly patterns. Among them, the abnormal indicator change is different from the alarm mode when a single indicator of any node exceeds the preset static threshold.

[0069] In one embodiment, when processor 1001 executes multi-dimensional time-series monitoring data based on at least two different microservice nodes to identify whether there are anomalous metric changes that are correlated in the time dimension and span at least two levels in the spatial dimension, it specifically performs the following operations: For multi-dimensional time-series monitoring data of at least two different microservice nodes, calculate the deviation of the performance indicators of each microservice node from its historical baseline within the corresponding time window. Correlation analysis is performed on multiple deviation sequences to determine whether there is a positive or negative linkage relationship among them that meets a preset correlation threshold. When there is a linkage relationship and the nodes involved in the linkage relationship are spatially distributed across at least two different levels in the cross-level call topology, it is determined that there is an abnormal indicator change that is correlated in the time dimension and spans at least two levels in the spatial dimension.

[0070] In one embodiment, when the processor 1001 locates the root cause of the abnormal mode to a specific level and specific microservice node in the call topology graph according to the propagation path, it specifically performs the following operations: In the cross-level call topology diagram, determine the starting node of the propagation path, and obtain the time-series monitoring data of each affected node sequentially along the propagation path starting from the starting node; Compare the performance indicators in the time-series monitoring data of each affected node with their historical baseline to determine the starting point, magnitude, and rate of change of the time-series deviation; By analyzing the starting point, magnitude, and rate of change of the time sequence deviation, the final microservice node that first deviates in time sequence and is located at the upstream call position in the propagation path is identified. The final microservice node is determined as the specific microservice node in the abnormal mode; The specific layer to which a particular microservice node belongs is used as the specific layer of the abnormal mode.

[0071] In one embodiment, when the processor 1001 executes the monitoring data generated when collecting target business requests flowing through each layer of the microservice architecture, it specifically performs the following operations: By using a lightweight data collection probe pre-installed in a pre-defined multi-level microservice architecture, at least one of the following data is collected synchronously during the processing of the target business request: Performance metrics data should include at least CPU utilization, memory usage, interface response time, and network input / output. Runtime log data contains information output by the microservice architecture that records its running status or business events; Call event data is used to record the start, end, result status, and time consumption of inter-service calls.

[0072] In this embodiment, on the one hand, by generating a globally unique tracking identifier for each external business request and automatically passing it in all subsequent service calls, it ensures that all monitoring data generated by the same business at different levels can be associated with this unique identifier. The system can construct a complete cross-level call topology based on the globally unique tracking identifier, intuitively displaying all service dependencies from management layer instructions to device layer execution. When an anomaly occurs, the propagation path of the anomaly in the entire link can be quickly traced based on this identifier, achieving full-link visibility and accurate source tracing. On the other hand, the cross-level call topology contains multi-dimensional time-series monitoring data from multiple nodes. These data are sequentially related in time and propagate spatially, enabling the system to accurately identify anomaly propagation patterns, significantly reducing false alarms caused by isolated judgments and significantly improving the detection rate of hidden, progressive faults. Furthermore, based on the full-link monitoring data linked by the globally unique identifier, the system can compare the differences between the current link indicators and the baseline pattern in real time, providing complete contextual data support for rapid fault diagnosis and root cause localization, significantly improving the observability and operational efficiency of the distributed system.

[0073] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The cross-level tracing monitoring program can be stored in a computer-readable storage medium. When executed, the program can include the processes of the embodiments of the above methods. The storage medium for the cross-level tracing monitoring program can be a magnetic disk, optical disk, read-only memory, or random access memory, etc.

[0074] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A monitoring method for cross-level tracing, characterized in that, Applied to the server side, the method includes: Upon receiving an external business request from a client, a globally unique tracking identifier is generated and incorporated into the external business request to obtain the target business request; During the process of the target business request flowing through the preset multi-level microservice architecture, the globally unique tracking identifier in the target business request is automatically transmitted in each level of the microservice architecture. Collect monitoring data generated when the target business request flows through each layer of the microservice architecture; The monitoring data is associated with the globally unique tracking identifier to obtain the monitoring data of each level of the microservice architecture; Cross-level correlation analysis is performed on the monitoring data of the microservice architecture at each level to identify abnormal patterns and locate their root causes. This includes: integrating the monitoring data of the microservice architecture at each level to obtain a cross-level call topology diagram corresponding to the target business request; wherein, the cross-level call topology diagram is used to represent the call dependencies between the microservices at each level through which the target business request flows; performing spatiotemporal correlation pattern analysis based on the cross-level call topology diagram to identify whether there are cross-level abnormal patterns; in the case of cross-level abnormal patterns, performing reverse backtracking analysis along the cross-level call topology diagram to determine the propagation path of the abnormal indicators in the cross-level call topology diagram; and locating the root cause of the abnormal pattern to the specific level and specific microservice node in the call topology diagram according to the propagation path. The step of performing spatiotemporal correlation pattern analysis based on the cross-level call topology to identify whether there are cross-level abnormal patterns includes: traversing the cross-level call topology to obtain multi-dimensional time-series monitoring data of at least two different microservice nodes; wherein, the multi-dimensional time-series monitoring data includes at least performance indicators; based on the multi-dimensional time-series monitoring data of the at least two different microservice nodes, identifying whether there are abnormal indicator changes that are correlated in the time dimension and span at least two levels in the spatial dimension; taking the occurrence of the abnormal indicator changes as cross-level abnormal patterns; the abnormal indicator changes are different from the alarm patterns where a single indicator of any node exceeds a preset static threshold; The step of identifying whether there are abnormal indicator changes that are correlated in the time dimension and span at least two levels in the spatial dimension based on the multidimensional time-series monitoring data of the at least two different microservice nodes includes: calculating the deviation of the performance indicators of each microservice node from its historical baseline within the corresponding time window for the multidimensional time-series monitoring data of the at least two different microservice nodes; performing correlation analysis on multiple deviation sequences to determine whether there is a positive or negative linkage relationship between the multiple deviation sequences that meets a preset correlation threshold; and determining that there is an abnormal indicator change that is correlated in the time dimension and spans at least two levels in the spatial dimension when the linkage relationship exists and the nodes involved in the linkage relationship are spatially distributed in at least two different levels in the cross-level call topology graph.

2. The method according to claim 1, characterized in that, The process of generating and incorporating a globally unique tracking identifier into the external business request to obtain the target business request includes: Parse the external business request to obtain parsed data; From the parsed data, multiple random factors are obtained, including at least the current first timestamp, machine identifier, process identifier, and sequence number; The multiple random factors are combined and encoded to obtain a composite code, which serves as a globally unique tracking identifier. The globally unique tracking identifier is injected into the metadata of the external business request to obtain the target business request.

3. The method according to claim 1, characterized in that, The automatic transmission of the globally unique tracking identifier in the target business request across all levels of the microservice architecture includes: During the process of the target business request initiating a call from the current layer microservice to the downstream layer microservice, the globally unique tracking identifier is extracted from the current execution context information; wherein, the current layer microservice and the downstream layer microservice are adjacent microservice architectures in the preset multi-level microservice architecture; The globally unique tracing identifier is injected into the request metadata of the service call, so that the globally unique tracing identifier is passed to the downstream microservice along with the service call; When the downstream microservice receives a service call, it extracts the globally unique tracking identifier from the request metadata and sets the globally unique tracking identifier as the execution context information of the downstream microservice itself.

4. The method according to claim 1, characterized in that, The monitoring data of each layer of the microservice architecture are integrated to obtain a cross-layer call topology diagram corresponding to the target business request, including: From the monitoring data of the microservice architecture at each level, extract context information that represents the microservice call relationship; wherein, the context information includes at least a parent span identifier for identifying the call source and a current span identifier for identifying the current call; Based on the parent-child dependency relationship between the parent span identifier and the current span identifier, a directed graph is constructed from all microservice nodes through which the target business request flows; wherein, each microservice node corresponds to a current span identifier, and the directed edges between nodes are determined by the pointing relationship between the parent span identifier and the current span identifier; The monitoring data corresponding to each microservice node is mounted to the corresponding node in the directed graph based on the globally unique tracking identifier and the current span identifier, so as to generate a cross-level call topology graph containing a complete call chain and monitoring data.

5. The method according to claim 1, characterized in that, The step of locating the root cause of the abnormal pattern to a specific level and microservice node in the call topology graph based on the propagation path includes: In the cross-level call topology diagram, the starting node of the propagation path is determined, and the time-series monitoring data of each affected node is obtained sequentially along the propagation path starting from the starting node; By comparing the performance indicators in the time-series monitoring data of each affected node with their historical baseline, the starting point, magnitude, and rate of change of the time-series deviation can be determined. By analyzing the starting point, magnitude, and rate of change of the time-series deviation, the final microservice node that first deviates in time and is located at the upstream call position in the propagation path is identified. The final microservice node is determined as the specific microservice node of the abnormal mode; The specific layer to which the microservice node belongs is taken as the specific layer of the abnormal mode.

6. The method according to any one of claims 1-5, characterized in that, The monitoring data collected when the target business request flows through each layer of the microservice architecture includes: Using a lightweight data collection probe pre-installed in the preset multi-level microservice architecture, at least one of the following data is collected synchronously during the processing of the target business request: Performance metrics data, which include at least CPU utilization, memory usage, interface response time, and network input / output. Operation log data, which includes information output by the microservice architecture that records its running status or business events; Call event data is used to record the start, end, result status, and time consumption of inter-service calls.

7. A monitoring system for cross-level traceability implemented using the method described in any one of claims 1-6, characterized in that, The system includes: The globally unique tracking identifier injection module is used to generate and incorporate a globally unique tracking identifier into the external business request when it receives an external business request sent by the client, so as to obtain the target business request. The globally unique tracking identifier transmission module is used to automatically transmit the globally unique tracking identifier in the target business request at each level of the microservice architecture as the target business request flows through the preset multi-level microservice architecture. The monitoring data acquisition module is used to collect monitoring data generated when the target business request flows through each layer of the microservice architecture. The parameter association module is used to associate the monitoring data with the globally unique tracking identifier to obtain the monitoring data of the microservice architecture at each level. The root cause identification and localization module is used to perform cross-level correlation analysis on the monitoring data of the microservice architecture at each level in order to identify abnormal patterns and locate the root causes of the abnormal patterns.

Images