Method, system, device, product and medium for monitoring online microservice applications

Abstract

The application relates to the field of Internet information technology and provides a monitoring method, system, device, product and medium for online micro-service application, the online micro-service application comprises a plurality of micro-service components, the micro-service components are deployed on a host; the method is applied to an agent on the host, and the method comprises the following steps: collecting original monitoring data of monitoring events and obtaining a causal relationship between different monitoring events; generating a vertex corresponding to a monitoring event; generating an edge representing a causal relationship between monitoring events corresponding to two vertices and sending the edge to a manager, so that the manager connects all edges of a same user request to obtain a path, generates a unique path identifier of the path, and returns the path identifier to the agent; obtaining the path identifier returned by the manager, performing data aggregation on the original monitoring data of the same vertex in the same path identifier, obtaining a performance snapshot, and deleting a vertex corresponding to a non-exceptional monitoring event; and sending an abnormal vertex corresponding to an abnormal monitoring event and the performance snapshot to a collector.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of Internet information, and in particular to a monitoring method, system, device, product and medium for online micro-service application. BACKGROUND

[0002] Currently, the architecture of online micro-service application leads to multiple components and complex interactions, and the traditional distributed tracking framework generates a large amount of fine-grained raw monitoring data. Fault detection and risk detection are involved in online micro-service application, the fault detection scheme needs to directly check single request data, but it is not sensitive to risk (slow change) and is prone to false positives or false negatives; the risk detection scheme needs to analyze the continuous change trend of data.

[0003] The current distributed tracking framework cannot provide ideal data support for micro-service risk detection and analysis. First, these frameworks usually directly transmit raw monitoring data to centralized servers without processing. With a large number of indicators added to the tracking data, the total amount of raw data in the production environment can easily reach several terabytes. This brings huge transmission and storage burden. SUMMARY

[0004] To overcome the problems in the related art, the present application provides a monitoring method, system, device, product and medium for online micro-service application.

[0005] According to a first aspect of an embodiment of the present application, a monitoring method for online micro-service application is provided, the online micro-service application comprising a plurality of micro-service components, the micro-service components being deployed on a host;

[0006] The method is applied to an agent deployed on the host in a cluster, the cluster further comprising a manager and a collector;

[0007] The method comprises:

[0008] Collecting raw monitoring data of monitoring events related to user requests occurring in the micro-service components in the host and obtaining the causal relationship between different monitoring events;

[0009] According to a preset abnormal condition, the raw monitoring data is identified to determine whether the monitoring events are abnormal, and a vertex corresponding to the monitoring events is generated; wherein the vertex contains the raw monitoring data of the monitoring events;

[0010] An edge representing the causal relationship between the monitoring events corresponding to two vertices is generated and sent to the manager, so that the manager connects all edges of the same user request to obtain a path, generates a unique path identifier of the path and returns it to the agent;

[0011] After obtaining the path identifier returned by the manager, performing data aggregation on the original monitoring data of the same vertex in the same path identifier, and obtaining a performance snapshot containing the aggregation result, the vertex corresponding to the non-exceptional monitoring event is deleted.

[0012] The abnormal vertex and the performance snapshot are sent to the collector.

[0013] According to a second aspect of the embodiment of the present application, a monitoring method of an online micro-service application is provided, the online micro-service application comprising a plurality of micro-service components, the micro-service components being deployed on a host;

[0014] The method is applied to a manager in a cluster, the cluster further comprising a collector and an agent deployed on the host; the agent is configured to perform the steps of the method of the first aspect; and the method comprises:

[0015] Obtaining an edge sent by the agent, the edge representing a causal relationship between monitoring events corresponding to two vertices;

[0016] Connecting all edges of the same user request to obtain a path, generating a unique path identifier of the path and returning the path identifier to the agent.

[0017] According to a third aspect of the embodiment of the present application, a monitoring method of an online micro-service application is provided, the online micro-service application comprising a plurality of micro-service components, the micro-service components being deployed on a host;

[0018] The method is applied to a collector in a cluster, the cluster further comprising a manager and an agent deployed on the host; the agent is configured to perform the steps of the method of the first aspect, and the manager is configured to perform the steps of the method of the second aspect; and the method comprises:

[0019] Receiving an abnormal vertex and a performance snapshot sent by the agent;

[0020] According to the user request to which each abnormal vertex belongs, a trace chain connected by the causal relationship between each abnormal vertex of the same user request is generated and stored, the trace chain being used as data for fault detection of the online micro-service application.

[0021] According to each performance snapshot, a performance snapshot graph connected by the causal relationship between each vertex in the same path is generated and stored, the performance snapshot graph being used for risk detection of the online micro-service application.

[0022] According to a fourth aspect of the embodiment of the present application, a monitoring system of an online micro-service application is provided, the online micro-service application comprising a plurality of micro-service components, the micro-service components being deployed on a host;

[0023] The monitoring system comprises a manager, a collector and an agent deployed on the host;

[0024] The agent is configured to perform the steps of the method of the first aspect;

[0025] The manager is configured to perform the steps of the method of the second aspect;

[0026] The collector is configured to perform the steps of the method of the third aspect.

[0027] According to a fifth aspect of the embodiments of the present application, a computer device is provided, comprising a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the method embodiments of any one of the first aspect to the third aspect when executing the computer program.

[0028] According to a sixth aspect of the embodiments of the present application, a computer readable storage medium is provided, which stores a computer program, and the computer program is executable by a processor to implement the steps of the method embodiments of any one of the first aspect to the third aspect.

[0029] According to a seventh aspect of the embodiments of the present application, a computer program product is provided, comprising a computer program, and the computer program is executable by a processor to implement the steps of the method embodiments of any one of the first aspect to the third aspect.

[0030] The technical solutions provided by the embodiments of the present application can include the following beneficial effects:

[0031] In the embodiments of the present application, an agent deployed on the host is designed to collect and aggregate data on the data source side; wherein the agent can collect original monitoring data of monitoring events, determine whether the monitoring events are abnormal, and generate a vertex containing the original monitoring data of the monitoring events; the agent sends the edges representing the causal relationship between the monitoring events corresponding to the two vertices to the manager, the manager connects all the edges of the same user request to obtain a path, generates a unique path identifier of the path and returns it to the agent; the agent aggregates the original monitoring data of the same vertex in the same path identifier to obtain a performance snapshot containing the aggregation result, and then deletes the vertices corresponding to the non-abnormal monitoring events; the agent sends the abnormal vertex and the performance snapshot to the collector.

[0032] As can be seen, for normal monitoring events, the original monitoring data can be summarized at a proper granularity for more complex analysis. For abnormal monitoring events, detailed and fine-grained original monitoring data is saved separately. Therefore, the embodiments realize double-focus monitoring, which can significantly reduce the original monitoring data and the amount of data to be transmitted.

[0033] It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application, as claimed. BRIEF DESCRIPTION OF DRAWINGS

[0034] Figure 1 is a schematic diagram of a monitoring system of an online microservice application according to an example embodiment of the present application.

[0035] Figure 2A is a flow chart of a monitoring method of an online microservice application according to an example embodiment of the present application.

[0036] Figure 2B is a schematic diagram of data processing according to an example embodiment of the present application.

[0037] Figure 2C is a schematic diagram of data collection according to an example embodiment of the present application.

[0038] Figure 3 is a flow chart of another monitoring method of an online microservice application according to an example embodiment of the present application.

[0039] Figure 4 is a flow chart of another monitoring method of an online microservice application according to an example embodiment of the present application.

[0040] Figure 5 is a hardware structure diagram of a computer device where a monitoring apparatus of an online microservice application is located according to an example embodiment of the present application. DETAILED DESCRIPTION

[0041] The example embodiments will now be described in detail with reference to the accompanying drawings. If the description of the example embodiments refers to accompanying drawings, then the description is illustrative of the example embodiments and does not limit the present application. Unless otherwise defined, all terms (including technical and scientific terms) used in the present application have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and the present application, and will not be interpreted in an overly literal or overly formal sense unless expressly so defined herein.

[0042] The terminology used in the present application is for the purpose of describing particular embodiments only and is not intended to be limiting of the present application. As used in the description of the application and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term “and / or” as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

[0043] It should be understood that, although the terms first, second, third, etc. can be employed in this application to describe various information, these information should not be limited to these terms. These terms are only used to differentiate one piece of information from another piece of information of the same type. For example, without departing from the scope of the application, the first information can also be referred to as the second information, and similarly, the second information can also be referred to as the first information. Depending on the context, the word "if" as used herein can be interpreted as "when" or "upon" or "in response to determining".

[0044] The user information (including but not limited to user equipment information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in the present application are all information and data authorized by the user or authorized by all parties, and the collection, use and processing of related data need to comply with relevant laws, regulations and standards in the relevant region, and provide corresponding operation portal for user to choose authorization or refusal.

[0045] (1) Online applications gradually migrate from monolithic architecture to microservice architecture

[0046] In the early stage of the development of data centers and cloud computing, online applications are usually organized, written, and compiled as a completely independent program, and are uniformly published, deployed, put online, and run in this form. This application architecture is also known as monolithic architecture. Although monolithic architecture has certain simplicity in management, as the functions of online applications become more complex and the number of online application users gradually increases, its limitations gradually appear. First, monolithic architecture online applications must be scaled horizontally to cope with increasing workloads. The operation and maintenance personnel or scheduling platform needs to copy the entire online application program multiple times and distribute it to different computing nodes for independent operation. This performance expansion method not only easily leads to low resource utilization, but also may cause other problems, such as server performance bottlenecks and load balancing difficulties. In addition, the performance bottleneck or error of any one logical function in the monolithic architecture may affect the performance and reliability of the entire system, thereby further limiting its expansion capability. Second, monolithic architecture greatly increases the deployment and operation and maintenance difficulty of online applications. When the development team needs to modify a specific function or add a new function, the entire application program must be rebuilt and deployed. This not only increases the complexity and time cost of development and testing, but also may cause unexpected failures of other unrelated functions. At the same time, since all functions are tightly coupled, share the same computing resources and running environment, the failure of any one function will have a serious negative impact on other parts, thereby increasing the vulnerability of the system.

[0047] With the rapid development and increasing maturity of cloud-native technologies, more and more online applications are migrating from traditional monolithic architectures to microservice architectures in consideration of service performance, economic benefits, and flexibility. These applications are therefore referred to as online microservice applications. Microservice architecture decomposes monolithic applications into multiple independent, loosely coupled service components, each of which focuses on completing specific functions. This partitioning not only improves system flexibility but also enables each component to be developed, deployed, and scaled independently, thereby greatly improving development efficiency and system maintainability. For example, when code changes or function extensions are needed, developers only need to focus on specific microservices rather than the entire system, reducing the complexity and potential risks of changes.

[0048] Microservice architecture has many advantages in terms of development, deployment, and management. First, since services are independently deployed, development teams can use technology stacks that meet their business needs in different services, thereby improving the flexibility of technology selection. Second, microservice architecture supports parallel development, allowing different teams to develop multiple services simultaneously without interfering with each other, thereby shortening the product development cycle. In addition, microservice architecture also supports independent scaling, allowing the system to dynamically allocate resources based on the needs of specific services, thereby achieving higher resource utilization and performance optimization.

[0049] (II) Online microservice application monitoring technology

[0050] Although microservice architecture provides many conveniences, it has also given rise to complex dependency relationships between components in online microservice applications. Therefore, compared to online applications based on monolithic architecture, online microservice applications face new operational challenges in terms of business performance bottleneck analysis, fault impact assessment, and system stability guarantee. To address these challenges, online microservice application monitoring technology has emerged. By collecting system state information, these monitoring technologies enable operators to perform performance fault analysis and troubleshooting tasks such as data monitoring, root cause analysis (RCA), and system diagnosis. As of now, online microservice application monitoring technology can be divided into three different technology routes according to its data source: metrics monitoring, which uses aggregable scattered metrics as data sources; logging monitoring, which is driven by system and application events and saves logs with natural semantics; and distributed tracing, which aims to save causal relationships by linking components through user transaction requests. This embodiment mainly focuses on distributed tracing as the research object.

[0051] (Three) Distributed Tracing Technology

[0052] The earliest research on distributed tracing technology dates back to 2003, when Magpie was published in the 9th Conference on Hot Topics in Operating Systems (HOTOS). It was officially established by Dapper, published in Google Technical Report in 2012. Its output, commonly known as Distributed Traces, includes two types of information: life cycle (or Span) and its corresponding related indicators; the causal relationship and execution order between spans.

[0053] Compared with the other two types of online microservice application monitoring technologies, distributed tracing technology provides the necessary end-to-end view of user transaction requests. Its main purpose is to use spans as boundaries to subdivide end-to-end latency into finer units and generate workflow-centric output. Therefore, compared with the other two types of online microservice application monitoring technologies, distributed tracing is more suitable as the core pillar of online microservice application monitoring technology, linking the other two types of technology.

[0054] (Four) Microservice Failures and Risks

[0055] In the complex production environment of data centers, online microservice applications often encounter problems such as performance fluctuations and changes in workloads. According to whether it will immediately affect the end-to-end user experience, these microservice anomalies (Anomalies) changes can be divided into failures (Failures) or risks (Risks).

[0056] Network interruptions, service unavailability, and user request execution time too long are among the most serious microservice anomalies, directly affecting user experience. Such failures are very obvious, rapidly deteriorating, and will produce end-to-end symptoms. To detect microservice failures, the existing approach is to establish an alarm system and pre-configure threshold-based detection rules based on business-related indicators such as request latency. In addition, operations personnel need to collect detailed indicators, distributed traces, and logs to quickly analyze their root causes. In this process, the distributed tracing framework is an indispensable tool. It provides an important and comprehensive view of user requests in loosely coupled microservices, making it a key tool for analyzing failures.

[0057] However, faults are not the whole story of microservice anomalies. In addition to faults, in recent years, operations personnel have begun to shift their focus from fault detection to risk detection and analysis for online microservice applications. Unlike faults, risks manifest as slow, persistent, and subtle performance degradation. Their root causes can include faulty hardware, resource contention, random packet loss, abnormal system calls, and security attacks. While these risks do not immediately lead to end-to-end outages, this does not mean that the importance of identifying risks in microservice production environments can be ignored. Whether in the rapidly developing automotive industry or in e-commerce companies that require high reliability, detecting and analyzing risks is essential. Quickly and accurately identifying risks helps to successfully prevent faults from occurring. When performance changes or resource pressure reappears, it often indicates that the execution conditions have become uncertain and unstable. In production environments, the number of daily alerts can easily reach hundreds, and a significant portion of them are proven to be precursors to faults, i.e., risks. If not discovered and mitigated in time, these risks will spread and have a greater impact. However, if these risks can be quickly and accurately detected, preventive measures can be taken to avoid faults.

[0058] In this context, distributed tracing technology is particularly important. By refining the life cycle of requests, recording relevant metrics and causal relationships, distributed tracing can effectively help detect and analyze these risks. It not only helps to identify existing faults, but also provides early warnings for risks that may turn into faults in the future, thereby improving the stability and predictability of the entire system.

[0059] (4) Technical problems of existing online microservice application monitoring frameworks

[0060] Given the significant differences in the characteristics of faults and risks in online microservice applications, the detection or analysis algorithms for faults and risks should differ in their inputs. Currently, most fault detection methods, such as threshold assumptions and classification models, are designed to individually examine the data for each user transaction request. They are called instance-based algorithms. Although instance-based algorithms have been widely used in fault detection, they are not as effective in detecting risks. These algorithms face a dilemma: either accept false positives caused by performance fluctuations or tolerate false negatives and detection delays.

[0061] Unlike instance-based algorithms, algorithms that can detect trends in continuous data changes are called sequence-based algorithms. They have a significant advantage in detecting abnormal state accumulation and have been widely used in the past few years. However, current distributed tracking frameworks do not provide ideal data support for microservice risk detection and analysis. First, these frameworks usually transmit raw data directly to centralized servers without processing. With a large number of indicators added to the tracking data, the total amount of raw data in the production environment can easily reach petabytes (PBs). This brings a huge transmission and storage burden. Second, the generated monitoring results are too granular, making it difficult for sequence-based algorithms to run efficiently. All data must be thoroughly traversed to complete preprocessing tasks such as generating histograms using time windows or calculating the 90th percentile. The large amount of data required to detect risks greatly reduces the performance of sequence-based algorithms.

[0062] Based on this, the scheme provides an online microservice application monitoring scheme, which designs an agent deployed on the host, collects and aggregates data on the data source side, and for normal monitoring events, the original monitoring data can be summarized at a suitable granularity for more complex analysis. For abnormal monitoring events, detailed and fine-grained original monitoring data is saved separately. Therefore, the embodiment realizes double-focus monitoring, which can significantly reduce the original monitoring data and reduce the amount of data to be transmitted. Next, the embodiments of the application will be described in detail.

[0063] The embodiment of the application provides an online microservice application monitoring system; the online microservice application comprises a plurality of microservice components, and the microservice components are deployed on a host.

[0064] The monitoring system comprises a manager, a collector and an agent deployed on the host.

[0065] The number of microservice components constituting the online microservice application is arbitrary, and the embodiment does not limit this.

[0066] The number of hosts contained in the cluster can also be arbitrary, and the microservice components running in the host can also be arbitrary; in the cluster, the same microservice component can run on one or more hosts, and the embodiment does not limit this. The host of the embodiment can be a physical machine or a virtual machine.

[0067] In the embodiment, an agent can be deployed on a host. For example, in order to monitor each microservice component, an agent can be deployed on each host. Of course, other deployment manners can also be used in actual applications, for example, an agent can not be deployed on some hosts, and the embodiment does not limit this. In the application scheme, the agent is used as a collection side, and can collect data in a specific manner in the application scheme.

[0068] In the embodiment, the number of managers and the number of collectors can also be arbitrary. Optionally, the machine (physical machine or virtual machine) where the manager is located can be different from the host where the agent is deployed, and the machine (physical machine or virtual machine) where the collector is located can be different from the host where the agent is deployed. Of course, it is also possible that a certain manager and a certain agent are deployed on the same host, and a certain collector and a certain agent are deployed on the same host. In actual applications, the manager and the collector are scalable in the cluster.

[0069] As shown in Figure 1 , Figure 1 is a schematic diagram of a monitoring system according to an exemplary embodiment of the application; Figure 1 In the embodiment, microservice component A and microservice component B running in a certain host are taken as an example for description.

[0070] Figure 1 In the embodiment, three types of components in the monitoring system are shown: agents, managers, and collectors. In the embodiment, an agent can be deployed on each host. These agents are used for data collection and filtering at the data source; optionally, non-intrusive monitoring can be used for online microservice components, and the agent can collect data obtained from eBPF programs and intrusive custom extensions. Based on the monitoring data, vertices representing monitoring events and edges representing causal relationships are constructed and cached. The agent in the embodiment will further perform in-set calculations, such as data filtering, interaction with the manager and the collector for path and performance snapshot assembly, and data aggregation.

[0071] The manager and the collector can be designed and implemented to run throughout the system and be expanded according to actual workloads. They establish communication with the agent based on the coordinated assembly of path and performance snapshots. The manager is mainly responsible for receiving edges from the agent, assembling them into paths, and returning path identifiers to the agent. Optionally, data filtering results can also be transmitted to the related agent through lightweight tags, and these tags guide the agent to specially reserve the corresponding vertices. The collector receives vertices and performance snapshots transmitted by the agent, generates trace chains and performance snapshot graphs, and reports them as inputs to the alarm system and the risk detection system. In the embodiment, the performance snapshot graph can also be persistently saved to provide data support for future user queries.

[0072] Next, the agent is taken as the execution subject, and the method flow executed in the agent is described. As shown in Figure 2A Figure 2A is a flowchart of a monitoring method according to an exemplary embodiment of the present application, which can include the following steps:

[0073] In step 202, original monitoring data of monitoring events related to user requests occurring in the microservice components in the host are collected, and the causal relationship between different monitoring events is obtained;

[0074] In step 204, the original monitoring data is identified according to a preset abnormal condition to determine whether the monitoring events are abnormal, and a vertex corresponding to the monitoring events is generated; wherein the vertex contains the original monitoring data of the monitoring events;

[0075] In step 206, an edge representing the causal relationship between the monitoring events corresponding to two vertices is generated and sent to the manager, so that the manager connects all edges of the same user request to obtain a path, generates a unique path identifier of the path and returns it to the agent;

[0076] In step 208, the path identifier returned by the manager is obtained, the original monitoring data of the same vertex in the same path identifier is aggregated, a performance snapshot containing the aggregation result is obtained, and the vertex corresponding to the non-abnormal monitoring event is deleted;

[0077] In step 210, the abnormal vertex corresponding to the abnormal monitoring event and the performance snapshot are sent to the collector.

[0078] In this embodiment, the agent is designed to intelligently process data at the data collection source (i.e. each monitored host), and to distinguish between "abnormalities that need to be retained in detail" and "normal data that can be aggregated", thereby realizing double-focus monitoring, i.e. simultaneously and efficiently supporting fault analysis (which requires fine-grained details) and risk analysis (which requires aggregated views) within one framework.

[0079] In this embodiment, considering that an online microservice application is composed of multiple microservice components, the execution process of a user request is therefore disassembled, recorded and intelligently aggregated. For example, a single user operation (such as "placing an order") can trigger multiple microservices (order, inventory, payment, etc.). A fault can occur in any link. Tracing by user request granularity can restore the complete business execution path and see the whole process from the initiation to the termination of the request. The user request is the "main line of business logic" that connects various microservice components, and taking it as the monitoring granularity can convert technical indicators into business value and realize precise operation and maintenance.

[0080] ​The embodiment designs a unified edge driving paradigm, which includes vertices, edges, paths, and performance snapshots.

[0081] (1) Vertex;

[0082] In the embodiment, one vertex corresponds to one specific monitoring event related to processing a user request occurring in one microservice component. The monitoring event is captured by an agent deployed on a host, and the specific capturing method will be described in subsequent embodiments.

[0083] When the monitoring event occurs, the agent can collect the original monitoring data of the monitoring event. The original monitoring data can include any information, including but not limited to: event identification, timestamp, location (such as the identification of the microservice component), various indicators (such as CPU usage, memory usage, network packet size, retransmission times), context information (such as user request identification), etc., which are not limited in the embodiment.

[0084] As an example, the monitoring event of the embodiment can have multiple implementation ways; as an example, the monitoring event can include: an arrival event of a user request arriving at a microservice component, and a leaving event of a user request leaving the microservice component. In other examples, the data collection can also be realized by modifying the code inside the online microservice application, and the monitoring event can be a monitoring event inside the microservice component, such as a monitoring event of any function inside the component, such as a function call event, etc., which can be flexibly realized according to the needs in actual application, and the embodiment is not limited thereto.

[0085] As an example, a user order request arrives at a microservice component A, and the internal service of the component starts to process the logic of deducting inventory. The agent captures this "start processing" event, creates a vertex V_inventory_start, records the start time, component name, user request identification Trace ID, and various indicators.

[0086] The deduction inventory logic is executed. The user order request leaves the microservice component A, and the agent captures the "end processing" event, creates a vertex V_inventory_end, records the end time, execution time ( = end time - start time), user request identification Trace ID, and various indicators. The two vertices (V_inventory_start and V_inventory_end) collectively describe the complete event of the inventory service processing the request.

[0087] In addition, after the user order request leaves the microservice component A, other microservice components can be triggered, and the agent can continue to capture the subsequent monitoring events and original monitoring events.

[0088] (2) Edge;

[0089] An edge represents a causal relationship between two vertices, also captured by the agent, can be inferred based on network communication or function calls. An edge can include: an identification of the edge, an identification of the user request, a vertex identification of the start vertex of the edge, a vertex identification of the end vertex of the edge.

[0090] For example, the two monitoring events in the above example: the arrival event of the user request arriving at microservice component A, and the departure event of the user request leaving microservice component A, these two monitoring events can constitute an edge. After leaving microservice component A, it continues to enter microservice component B, then the departure event of microservice component A and the arrival event of microservice component B can constitute an edge. These edges are all associated with the same user request.

[0091] (3) Path;

[0092] A path represents the execution flow experienced by a complete user request (Trace ID). It is composed of a set of vertices and edges connected to each other in execution order, forming a directed acyclic graph. The path is not directly collected, but assembled by the manager.

[0093] In this embodiment, the agent can send the captured to the manager. Among them, the agent can send the edges of the same user request to the same manager.

[0094] The manager can connect all edges belonging to the same request according to the start and end points of the edge and the shared user request identifier, forming a complete topology structure, which is called a path in this embodiment, which represents a complete call chain graph of a user request.

[0095] The manager generates a unique path identifier (Path ID) for this path, which can be implemented by hash calculation, for example. Requests with the same path (topology) will get the same Path ID, even if the Trace ID is different. For example, taking placing an order to purchase a product through an e-commerce APP as an example, assuming that the process of purchasing a product needs to go through multiple microservice components: Gateway → Order → Inventory → Payment, different user order requests will form the same path, and the path IDs of these different user requests are the same.

[0096] As an example, a path can contain the following information:

[0097] Path ID, which represents the unique identifier of the path;

[0098] Topology: describes which vertices the user request has flowed through and the calling order (edge) between them;

[0099] The associated user request identifier.

[0100] Other information can also be included in actual applications, which are not limited in this embodiment.

[0101] Different functions of the online microservice application are different paths, so the path represents a function of the online microservice application; the path identifier is a key basis for subsequent aggregation performance snapshots, which defines which data of which vertex in which path needs to be aggregated.

[0102] (4) Performance snapshot

[0103] The performance snapshot refers to the aggregation result of each original monitoring data of the same vertex in the same path identifier. When the agent receives the path identifier returned by the manager, it can start aggregation processing. For example, the agent checks the original monitoring data of each vertex corresponding to the path identifier in the local cache, and provides a preset aggregation algorithm for each original monitoring data of each vertex to obtain the aggregation result of the vertex.

[0104] As an example, the aggregation result can include any preset aggregation information, including but not limited to, for example, request count, average execution time, error rate, histogram, average CPU usage, average memory usage, etc. This embodiment is not limited in this regard. After obtaining the performance snapshot of each vertex of the path identifier containing the aggregation result, the vertex corresponding to the non-exceptional monitoring event is deleted. Therefore, this embodiment can compress a large amount of original monitoring data of the vertex into a lightweight aggregation result.

[0105] In this embodiment, the collection-side computing is innovatively introduced to reduce processing delay and alleviate the data ingestion burden of bifocal monitoring. This process changes the role of the traditional agent and offloads data processing and computing tasks to them. The agent was previously limited to data collection and transmission, but now it has more functions such as data filtering, data aggregation, and interaction with the manager and collector. These functions allow the agent to bypass the need to send a large amount of raw monitoring data directly to the centralized server. Instead, raw monitoring data can be processed near its source, providing an effective solution to the growing data volume of bifocal monitoring.

[0106] In actual applications, identifying whether a monitoring event is abnormal, i.e., identifying whether a vertex is an abnormal vertex, can be based on a preset abnormal condition for identifying original monitoring data, which can be flexibly configured according to actual needs. As an example, it can be a threshold-based abnormal condition. The original monitoring data of a normal vertex can be deleted after aggregation, so this can also be understood as data filtering.

[0107] In order to keep track of the chain of fine-grained abnormal and subsequent abnormal monitoring events, the first function of the collection side computing in this embodiment implements data filtering. All vertices are filtered after collection, and some indicators in the original monitoring data of the vertices can be compared with the preset threshold. If an indicator exceeds the threshold, it can be considered that the monitoring event is abnormal; of course, other determination methods can also be used, and this embodiment does not limit this.

[0108] For abnormal monitoring events, the corresponding vertices can be marked as abnormal, for example, 1 is used as a label representing abnormality, and other methods can also be used in actual applications, and this embodiment does not limit this. The edges with the abnormal vertices can also carry labels representing the abnormal vertices.

[0109] For the manager, the manager can know which vertices in the edges sent by the agent are abnormal vertices. The manager can also send the abnormal vertices to other related agents, for example, the vertices marked as abnormal are returned to the path identifier of the other related agent. Here, the other related agent refers to the agent that stores the vertices having a causal relationship with the abnormal vertices, so as to indicate that the original monitoring data of the user request should be kept separately instead of being aggregated. For example, in this embodiment, a user request Q arrives at component A in host 1, and the request leaves and arrives at component B in host 2. In host 1, the agent identifies that the arrival event and / or the leaving event corresponding to the user request Q is an abnormal event, and in the manager side, the manager can pass the order identifier corresponding to the abnormal arrival event and / or the abnormal leaving event of the user request Q in component A of host 1 to the agent in host 2. That is, as long as an event in a user request is identified as an abnormal event, since the manager can obtain the vertices corresponding to the monitoring events of the user request sent by each agent, the manager can know the abnormal monitoring event of a user request, and can pass the abnormal monitoring event to other agents related to the user request. Through the above transmission of the manager, other monitoring events of the user request can be identified as abnormal events, even if the abnormal event occurs in the component of the other host and can not be identified by the agent itself. However, since the manager transmits the abnormal information of the user request, all monitoring events of the user request are ultimately identified as abnormal and kept, instead of being deleted. In other words, in addition to determining whether the monitoring event is abnormal based on the above preset abnormal condition for identifying the monitoring event obtained from the original monitoring data, the agent also determines whether the monitoring event is abnormal by combining the information transmitted by the manager, for example, the information transmitted by the manager can be user request identifier and the like.

[0110] In this embodiment, the edges sent by the agent to the manager are used for incremental path construction. The construction process is terminated by a configurable timeout, after which each path receives a global identifier, i.e., a path ID. These path IDs are calculated by performing a breadth-first search on the topology of each path, so that paths with the same topology are assigned the same path ID. Then, the path ID and report label are assigned back to the agent, triggering subsequent data aggregation.

[0111] In this embodiment, research revealed that due to the randomness of the system, this assembly process is designed to be executed through a centralized manager. For example, consider the gateway component, which is expected to be accessed by all requests originating from outside the cluster. At the gateway, the complete path of a specific user's request cannot be determined solely based on the information obtained.

[0112] As mentioned earlier, performance snapshots are aggregations of raw monitoring data with the same path ID and the same vertex. For example, the aggregation results may include results in the form of percentiles or histograms of generated metrics. These take up much less space than the raw monitoring data and are ideal lightweight outputs for dual-focus monitoring.

[0113] like Figure 2B The diagram shown illustrates a data processing method according to an exemplary embodiment of this application. Different colored squares represent vertices and performance snapshots generated by different components. See the leftmost manager, which shows three different paths it assembles (although the vertices are the same, the edges are different). The manager can generate three different path IDs.

[0114] Data aggregation begins when the agent receives the path ID sent back by the manager. Vertices with the same path ID are aggregated progressively to form a performance snapshot. Vertices with a label set to 1 are stored separately, while vertices without that label are deleted after aggregation. Optionally, the aggregation method can be further refined, for example, based on other fine-grained information (such as user ID or user request ID), such as aggregating raw monitoring data from the same user request or the same user based on the same path and the same vertex. This fine-grained information can be specified by the operator, and this embodiment does not limit it.

[0115] Regarding specific aggregation methods, for the metrics in the raw monitoring data of each vertex, users can define their own aggregation functions or use the default aggregation methods provided in this embodiment. For example, incremental aggregation can be used, including but not limited to: (1) constants, which record changes in stable metrics (such as version numbers); (2) counters, which track discrete data and their occurrence frequency (such as error codes); (3) histograms, which group data according to user-defined boundaries (such as packet size); and (4) percentiles, which are used to describe the statistical distribution of data (such as 99 percent latency).

[0116] (5) Trace chain and performance snapshot map

[0117] The vertices and performance snapshots can be transmitted to the collector periodically. The transmission interval is configurable, and can be set to 10 minutes, for example. When the vertices and performance snapshots are submitted to the collector, they go through a process similar to path construction. With the topology information in the performance snapshots and vertices, the collector can generate trace chains and performance snapshot maps.

[0118] For example, the structure of vertices connected by edges is called a trace chain, which is used to individually preserve the raw monitoring data for a particular user request. A trace chain is a complete, raw monitoring data (vertices and edges) preserved, execution path record for a single abnormal user request. It is essentially a distributed trace that preserves raw monitoring data. Since the agent sent the abnormal vertex, the collector can use the vertex containing raw monitoring data to reconstruct the complete, fine-grained execution record of this particular abnormal request, i.e., the trace chain, according to the edges. The trace chain can contain a structure similar to the path (vertices + edges + order), and also contains raw monitoring data that has not been aggregated.

[0119] In addition, the embodiment also designs a performance snapshot map, which aggregates raw monitoring data based on the functions (i.e., request types) of microservice components. Due to the single responsibility principle of microservices, the path reflects the execution process of the user request and can be regarded as a function identifier. By aggregating vertices and generating performance snapshots connected by edges, our paradigm seamlessly combines the performance snapshot map with the trace chain. Note that in a production implementation, performance snapshots can be generated more granularly. For example, an operator can build performance snapshots based on user IDs and paths.

[0120] Among them, the collector can receive performance snapshots from all agents; and the collector also receives edge information (or obtains path topology information from the manager) for building trace chains. The collector knows the topology of the path (which component calls which component), so it can connect the performance snapshots belonging to the same path ID, different components (Location) with edges based on the topology of the path, so as to obtain the performance snapshot map. As shown in Figure 2B The three performance snapshot maps finally constructed by the collector are consistent with the three paths constructed by the manager.

[0121] The performance snapshot map selects only the central identifier of the path for the following reasons: first, the path is not only essential to ensure functional consistency, but also provides critical global information for microservice troubleshooting. Second, other global information that can be used to perform more granular vertex aggregation (e.g., user ID) can be directly accessed in each microservice component by parsing user requests. In a production environment, the storage space occupied by the vertex is significantly larger than the edge. Therefore, compared with transmitting raw vertices and edges, transmitting only edges (even multiple times) provides a significant advantage in acquisition.

[0122] From the perspective of the operator of the monitoring system of the present embodiment, the monitoring system of the present embodiment ultimately generates two types of output: trace chains, which provide fine-grained, detailed, individual retention of exceptions and exception events; and performance snapshot maps, which serve as lightweight output for microservice risk troubleshooting. They are ultimately stored in persistent storage, and can also be subjected to advanced analysis queries as needed.

[0123] Next, the process of the agent collecting data is exemplified. As an example, the agent can include: an eBPF (extended Berkeley Packet Filter) program running in the kernel space of the host, which is hooked on a system call hook related to network communication in the operating system of the host;

[0124] The agent collects raw monitoring data of monitoring events related to user requests occurring in the microservice component in the host and acquires causal relationships between different monitoring events, including:

[0125] The eBPF program collects raw monitoring data of monitoring events related to user requests occurring in the microservice component in the host and acquires causal relationships between different monitoring events in response to a trigger request when the microservice component executes the system call related to network communication.

[0126] As an example, in order to achieve non-intrusive monitoring of online microservice applications, the present embodiment is designed and implemented based on the eBPF mechanism.

[0127] As shown in Figure 2C , it is a data collection schematic diagram according to an exemplary embodiment of the present specification, which includes three main elements: dual-focus monitoring data collection, context propagation, and customized extension.

[0128] The present application finds that the execution of microservice components is triggered and limited by the narrow-waist communication behavior of transport layer APIs. That is, the execution of microservice components is essentially triggered and limited by network communication behavior. A service component receives a request, processes it, and sends a request / response. This "narrow waist" refers to transport layer APIs (such as Linux kernel recvmsg, recvmmsg, readv, read, recvfrom, sendmsg, sendmmsg, writev, write, sendto, etc. system calls), which are the only way to communicate over the network.

[0129] Therefore, in actual application, a set of system calls related to network communication can be selected, and the specific system calls and the number thereof can be flexibly configured according to needs, and the present embodiment does not limit this. Then, the agent on each host will mount the eBPF program responsible for data collection to these hooks. These kernel system calls related to network communication will serve as monitoring points, i.e., the trigger points of the eBPF program.

[0130] When the microservice components execute these system calls (for example, send an HTTP request sendmsg, or receive a response recvmsg), the corresponding eBPF program will be triggered automatically. The triggered eBPF program can safely and efficiently capture the key information at the moment, generate a monitoring event, and start collecting metrics as raw monitoring data, including but not limited to: component performance (e.g., execution time), connection state (e.g., retransmission times), resource utilization (e.g., CPU usage), workload characteristics (e.g., load length), etc. Some basic identifiers can also be obtained, such as process ID (PID), file descriptor (FD), source / destination IP and port, etc. Combined with these metrics and information, a monitoring event is used to create a vertex. The causal relationship between these events (e.g., function calls, communication behavior between components) will be stored as edges and cached on the agent side together with the vertices.

[0131] Among them, the eBPF program can also obtain the causal relationship between different monitoring events, which is realized by context propagation in the present embodiment. From the kernel level, only scattered system calls and network packets are seen, and it is not known which user request they belong to. The present embodiment can accurately associate the vertices and edges occurring at different components and different times to the same user request to construct a complete path (call chain). Context propagation is used to pass metadata (i.e., context) to help identify and integrate the overall view of a specific user request, which can include two parts: intra-component context propagation and inter-component context propagation.

[0132] Intra-component context propagation is responsible for tracking the execution of a request within each component. This embodiment provides an intra-component solution for the common case in production environments. Specifically, it can include the following two strategies:

[0133] (1) Same message: Treat the same type of and consecutive communication system calls as system calls related to the same application layer message, i.e., as part of the same application layer message.

[0134] (2) Same request: Assume that adjacent application layer messages (e.g., receiving a request followed by sending a response, or sending a request followed by receiving a response) belong to the same user request.

[0135] Based on these two strategies, context information is extracted from each received message and injected into the next sent message. The above embodiment can be applied to most microservice applications without any prior expertise.

[0136] As an example, when an eBPF program captures an event of a received message (e.g., recvmsg completion), context information is extracted from the message content or packet header; based on strategy 1, subsequent related system calls (e.g., read calls on the same socket) can be associated with this receiving event. When the component needs to send a response or call downstream (triggering sendmsg), the previously extracted or generated context information can be injected into the message to be sent (usually the application layer protocol header, such as HTTP Header). According to strategy 2, this sending event is associated with the previous receiving event (i.e., the same request), so the proxy can build an edge for the sending event and the previous receiving event.

[0137] The above approach is suitable for microservices with most standard communication patterns without the need for intervention from developers of online microservice applications. In practical applications, the above processing can be configured in the proxy by default, of course, the default strategy can also be changed as needed.

[0138] In the case of cross-service or cross-host, inter-component context propagation can monitor the transmission of user requests between components. This embodiment achieves this goal by using eBPF to inject necessary context information (such as trace ID and / or sending vertex ID, etc.) into the transport layer packet options. This implementation can enhance the accuracy of context information transmission.

[0139] As an example, when an eBPF program traps an event that sends a message (e.g. sendmsg), the proxy knows that it needs to pass the context downstream. The eBPF program directly inserts the key context information in the packet options at the transport layer (e.g. TCP or IP layer), including but not limited to: a unique identifier of the entire request chain, a vertex identifier of the sending vertex (to identify which event of the current component triggered this call); the eBPF program of the downstream component can extract these injected context information from the transport layer options of the incoming packet at the event that receives the message (e.g. recvmsg).

[0140] Therefore, the embodiment does not rely on application layer protocol parsing, and can reliably pass the context even if the application layer protocol is not standard or encrypted (as long as the transport layer is not encrypted); it is transparent to the application, and the application is completely unaware that information has been added to the transport layer packet options.

[0141] Of course, in addition to the above non-intrusive implementation, it can also be implemented in a way. For example, it can also be customized and extended based on the above non-intrusive monitoring method:

[0142] For example, provide user space intrusive APIs; these APIs provide the same functionality as the monitoring skeleton. By making slight adjustments to the code, the embodiment can be seamlessly integrated into existing monitoring frameworks. For example, a set of libraries or APIs are provided to allow developers to explicitly record events, pass contexts, or add custom metrics in microservice application code.

[0143] Secondly, the embodiment can use the context knowledge provided by third-party frameworks to transparently correct the propagation behavior within the component. The context information injected into the message header by the intrusive framework will be parsed by the embodiment and used to replace the default result. For example, when the eBPF program or proxy traps a receiving event, it can simultaneously attempt to: extract the context (injected by the eBPF program of the embodiment) from the transport layer packet options; and parse the third-party framework injected context from the application layer message (e.g. HTTP Header). If there is a valid third-party context, it is used in preference to the context generated by the default strategy of the embodiment.

[0144] Finally, thanks to eBPF programs, developers of online microservice applications can adjust metrics collection (manually turn on / off collection of specific metrics, or add new custom metrics), trigger hooks (dynamically add or remove system call hooks that need to be monitored), context propagation logic (modify the default measurement or injected / extracted content), etc. For example, the user ID can also be included in the context to provide user information in subsequent collection side calculations. Using the dynamically loadable and updateable nature of eBPF, developers can adjust monitoring behavior in real time without restarting the application or proxy.

[0145] In the distributed scenario, there are multiple managers and multiple collectors in the cluster. In actual applications, as described above, the managers and collectors can be automatically expanded, for example, the managers can be expanded according to the assembly speed and assembly capacity of the managers on the path; the collectors can be expanded according to the assembly speed and assembly capacity of the collectors on the tracking chain and the performance snapshot map.

[0146] In some examples, the generating an edge representing a causal relationship between two vertices corresponding to monitoring events and sending to the manager can include: obtaining an identifier of the user request, calculating a first hash value of the identifier of the user request according to a first hash function, and determining a corresponding manager according to the first hash value; sending the edge to the determined manager, so that the edges of the same user request are sent to the same manager.

[0147] In some examples, the sending the abnormal vertex corresponding to the abnormal monitoring event and the performance snapshot to the collector for storage can include: calculating a second hash value of a path identifier of a path corresponding to the performance snapshot according to a second hash function, determining a corresponding collector according to the second hash value; and sending the abnormal vertex and the performance snapshot to the determined collector, so that the performance snapshots of the vertices in the same path are sent to the same collector.

[0148] The embodiment also designs an efficient mechanism to prevent load imbalance between the managers and collector replicas. The embodiment also proposes an implicit coordination mechanism that enables agents to route edges, vertices, and performance snapshots in a deterministic and uniform manner. The embodiment uses three global hash functions to achieve this goal: one for each agent to route edges, one for each agent to route vertices and performance snapshots, and one for manager path ID calculation.

[0149] In the embodiment, each agent is configured with the same first hash function and the second hash function; after obtaining an edge, the agent of the embodiment first hashes the tracking ID of the edge to determine which manager the edge should be sent to. Due to the random allocation of the tracking ID, edges with the same path topology but belonging to different user requests may be routed to different managers.

[0150] As an example, the input of the first hash function is the unique identifier of a user request, and its output is a unique hash value pointing to a certain manager. In this way, all edges of the same user request will be routed to the same manager, which is the prerequisite for the manager to assemble the complete path of the same user request, because only the same manager can see all edges of the same user request. Edges of different user requests but with the same path may be routed to different managers. Because their user request identifiers are different, the hash values are different. This is what load balancing expects, and it is also the key to subsequent association using path IDs.

[0151] In each manager, there is also the same hash function (i.e., the third hash function described above), and the manager calculates a unique path ID based on the assembled path using the third global hash function. As long as the topology is the same, a hash algorithm like MD5 can ensure that different managers produce the same path ID.

[0152] As an example, the input of the third hash function is: the topology of a path, which can be represented as a set of ordered component names (or vertex identifiers) and their connection relationships (edges). For example: [Gateway, OrderService, InventoryService, PaymentService] and their calling order.

[0153] The output of this hash function is also a unique hash value. When the manager replica receives all edges belonging to the same user request, it assembles these edges into a complete path and obtains its topology. Then, it uses the hash function to hash the topology and obtains the path ID of the path. As long as the topology is the same, the calculated path ID is the same, regardless of which manager performs the calculation. It ensures that different managers generate consistent path IDs for the same topology request. For example, all "Gateway->Order->Inventory->Payment" requests, regardless of which manager assembles them, will have the same path ID. The path ID is the key association basis for subsequent data aggregation (generating performance snapshots) and routing (to collectors). A path represents a function of an online microservice application.

[0154] Finally, using the path ID as input, the proxy of the present embodiment uses the second hash function described above to determine the destination of the vertex and the performance snapshot (i.e., the collector).

[0155] As an example, the input of the second hash function is: the path ID (i.e. the path identifier calculated by the manager and returned to the agent). The output of this hash function is: a unique hash value, which can be used to point to a certain collector. In this embodiment, data of the same path ID (i.e. data belonging to the same functional flow) will be routed to the same collector. For example, all performance snapshots of Path ID = P_ABCDE (order flow) will be sent to the same collector, no matter from which microservice component, which manager, which agent. This guarantees that at the collector side, performance snapshots belonging to the same functional flow (same path ID) but occurring in different components can be easily collected and assembled into a complete performance snapshot graph. If data of the same path ID is scattered to different collectors, it will be very difficult to assemble a global performance snapshot graph.

[0156] Since data of different path IDs will be routed to different collectors, load balancing of the collectors is achieved. Data of popular functional flows (e.g. high-frequency path IDs) can be concentrated in one collector, but this is usually acceptable because the collectors mainly process aggregated snapshots (the data volume has been greatly reduced).

[0157] In practical applications, this embodiment can perform fault detection on online microservice applications based on the trace chain; can perform risk detection on online microservice applications based on the performance snapshot graph. The performance snapshot graph can be stored in a persistent storage. This embodiment can also provide a query function for the performance snapshot graph, so that operators can retrieve these performance snapshot graphs on demand through specific queries.

[0158] For example, a query function by index threshold can be provided, and the operator can specify a specific index and a threshold of the index, and all performance snapshot graphs that meet the conditions (such as query conditions within or exceeding the threshold) can be returned.

[0159] For example, a query function by path structure can be provided, and the operator can specify a specific path structure (such as one or more components / or one or more vertices contained in the path), and performance snapshot graphs with the specific path structure (containing the specified components and having one or more edge order connecting them) can be returned.

[0160] For example, a function of extracting data by time range can be provided, and the operator can specify a timestamp (such as a start timestamp and an end timestamp), and all queries can support time filtering to return data of the specified period.

[0161] As shown in Figure 3 Figure 3 ​is a flowchart of a monitoring method of an online microservice application according to an example embodiment of the present application, the embodiment method is applied to a manager in a cluster, the cluster further includes a collector and an agent deployed on the host; can include the following steps:

[0162] In step 302, an edge representing the causal relationship between the monitoring events corresponding to the two vertices is acquired.

[0163] The agent can perform the steps of the foregoing method embodiments.

[0164] In step 304, all edges of the same user request are connected to obtain a path, a unique path identifier of the path is generated and returned to the agent.

[0165] The specific implementation of the embodiment can refer to the description of the foregoing embodiments, which will not be repeated here.

[0166] As Figure 4 shown, Figure 4 is a flowchart of a monitoring method of an online microservice application according to an example embodiment of the present application, the embodiment method is applied to a collector in a cluster, the cluster further includes a manager and an agent deployed on the host; the method includes:

[0167] In step 402, an abnormal vertex and a performance snapshot sent by the agent are received.

[0168] The agent can perform the steps of the foregoing method embodiments.

[0169] In step 404, according to the user request to which each abnormal vertex belongs, a tracking chain connected by the causal relationship between each abnormal vertex of the same user request is generated and stored, and the tracking chain is used as data for fault detection of the online microservice application.

[0170] In step 406, according to each performance snapshot received, a performance snapshot graph connected by the causal relationship of each vertex in the same path is generated and stored, and the performance snapshot graph is used for risk detection of the online microservice application.

[0171] The specific implementation of the embodiment can refer to the description of the foregoing embodiments, which will not be repeated here.

[0172] As can be seen from the above embodiments, the embodiments provide a unified distributed tracing framework for simultaneously monitoring risk and failure features in an online microservice application scenario. The embodiments collect raw monitoring information using a non-intrusive method, and use collection-side computing technology to aggregate the raw monitoring information at an appropriate level of detail for more complex analysis. In addition, the embodiments also design an implicit load balancing mechanism for the online microservice scenario to achieve efficient expansion of the monitoring framework itself. Compared with existing distributed tracing frameworks, the embodiments can reduce data transmission and storage overheads to 3%, and reduce the time for excluding risks using modern data analysis systems by more than two orders of magnitude.

[0173] The embodiments innovatively construct a unified distributed tracing paradigm to achieve bifocal monitoring from a semantic perspective. In this paradigm, the embodiments separately save detailed and fine-grained raw monitoring data for outliers and edge cases. At the same time, data with small differences is aggregated to generate lightweight output. Both detailed results and aggregated results are seamlessly integrated into this unified paradigm.

[0174] The embodiments innovatively design a non-intrusive monitoring framework to achieve standardized data collection for bifocal monitoring. The framework is based on the eBPF (extended Berkeley Packet Filter) mechanism and can easily cover unmodifiable, black-box or closed-source infrastructure or third-party mobile service components. In addition, it can insert context information in the packet options at the transport layer to improve accuracy between different components.

[0175] The embodiments innovatively propose a collection-side computing mechanism to provide bifocal monitoring with minimal storage and transmission overheads. The embodiments perform data processing tasks such as data filtering and data aggregation at the collection agent immediately after collection, which were previously handled by the central backend. By avoiding providing raw monitoring data, the embodiments can generate accurate, lightweight and appropriately detailed output results, thereby greatly reducing ingestion overheads.

[0176] The embodiments also design and provide an implicit load balancing mechanism and a special query format.

[0177] Corresponding to the foregoing embodiments of the monitoring method for online microservice applications, the present application also provides embodiments of a monitoring device for online microservice applications and a computer device to which the monitoring device is applied.

[0178] The embodiment of the online micro-service application monitoring device can be applied on a computer device, such as a server or a terminal device. The device embodiment can be implemented by software, or by hardware or a combination of software and hardware. Taking the software implementation as an example, as a logical device, it is formed by reading the corresponding computer program instructions in the non-volatile memory into the memory for running by the processor. From the hardware level, as shown in Figure 5 The processor, network interface, memory, and non-volatile memory shown in Figure 5 In addition to the processor, network interface, memory, and non-volatile memory shown in

[0179] Accordingly, the embodiment of the present application also provides a computer program product, including a computer program, which, when executed by a processor, implements the steps of the preceding online micro-service application monitoring method embodiment.

[0180] Accordingly, the embodiment of the present application also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the online micro-service application monitoring method embodiment.

[0181] Accordingly, the embodiment of the present application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the online micro-service application monitoring method embodiment.

[0182] For the device embodiment, since it basically corresponds to the method embodiment, the related parts are described in the part of the method embodiment. The device embodiment described above is only schematic, and the modules described as separate components can or can not be physically separated, and the components displayed as modules can or can not be physical modules, that is, they can be located in one place, or distributed on multiple network modules. According to actual needs, some or all of the modules can be selected to achieve the purpose of the present application. Those skilled in the art can understand and implement it without creative labor.

[0183] The above embodiments can be applied to one or more computer devices, which are devices capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions. The hardware of the computer devices includes, but is not limited to, microprocessors, application specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, and the like.

[0184] The computer devices can be any electronic product capable of human-computer interaction with a user, such as personal computers, tablet computers, smart phones, personal digital assistants (PDAs), game consoles, interactive Internet protocol televisions (IPTVs), smart wearable devices, and the like.

[0185] The computer devices can also include network devices and / or user devices. The network devices include, but are not limited to, single network servers, server groups composed of multiple network servers, or clouds composed of a large number of hosts or network servers based on cloud computing.

[0186] The network in which the computer devices are located includes, but is not limited to, the Internet, a wide area network, a metropolitan area network, a local area network, a virtual private network (VPN), and the like.

[0187] The above describes specific embodiments of the present application. Other embodiments are within the scope of the attached claims. In some cases, the actions or steps described in the specification can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the accompanying drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multi-task processing and parallel processing are possible or can be advantageous.

[0188] The division of steps in the above methods is only for the purpose of clear description. When implemented, a step can be combined or some steps can be split and decomposed into multiple steps, as long as the same logical relationship is included, and all are within the protection scope of the present application. Adding insignificant modifications or introducing insignificant designs in the algorithm or process, but not changing the core design of the algorithm and process, are within the protection scope of the present application.

[0189] While this application contains numerous specific implementation details, these should not be construed as limiting the scope of any invention or the scope of the claims, but rather are primarily used to describe features of specific embodiments of a particular invention. Certain features described in the multiple embodiments of this application may also be implemented in combination in a single embodiment. Conversely, various features described in a single embodiment may also be implemented separately in multiple embodiments or in any suitable sub-combination. Furthermore, while features may function in certain combinations as described above and even initially claimed in this way, one or more features from a claimed combination may be removed from that combination in some cases, and a claimed combination may refer to a sub-combination or a variation of a sub-combination.

[0190] The terms "specific example" or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with the embodiments or examples, which are included in at least one embodiment or example of this application. In this application, illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0191] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention filed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not claimed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0192] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

[0193] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A monitoring method for online microservice applications, characterized in that, The online microservice application includes multiple microservice components, which are deployed on a host. The method is applied to agents deployed on the host in a cluster, which also includes a manager and a collector; The method includes: Collect raw monitoring data of monitoring events related to user requests that occur within the microservice component on the host machine, and obtain the causal relationships between different monitoring events; The original monitoring data is identified according to preset abnormal conditions to determine whether the monitoring event is abnormal, and a vertex corresponding to the monitoring event is generated; wherein, the vertex contains the original monitoring data of the monitoring event; An edge representing the causal relationship between monitoring events corresponding to two vertices is generated and sent to the manager, so that the manager connects all edges for the same user request to obtain a path, generates a unique path identifier for the path and returns it to the agent; Obtain the path identifier returned by the manager, aggregate the original monitoring data of the same vertex in the same path identifier, obtain a performance snapshot containing the aggregation result, and then delete the vertex corresponding to the non-abnormal monitoring event. The abnormal vertex corresponding to the abnormal monitoring event and the performance snapshot are sent to the collector.

2. The method according to claim 1, characterized in that, The agent includes: an eBPF program running in the kernel space of the host, the eBPF program being attached to system call hooks related to network communication in the operating system of the host; The process of collecting raw monitoring data related to user requests that occur within the microservice component on the host machine, and obtaining the causal relationships between different monitoring events, includes: The eBPF program responds to the trigger request when the microservice component executes the system call related to network communication, collects the original monitoring data of the monitoring events related to the user request that occur in the microservice component on the host, and obtains the causal relationship between different monitoring events.

3. The method according to claim 1, characterized in that, There are multiple agents; The edge includes: a corresponding user request identifier, a vertex identifier of the starting vertex of the edge, a label indicating that the monitoring event corresponding to the starting vertex is abnormal, a vertex identifier of the ending vertex of the edge, and a label indicating that the monitoring event corresponding to the ending vertex is abnormal. The step of obtaining the path identifier returned by the manager includes: Obtain the path identifier returned by the manager and the vertex identifier of the abnormal vertex of the corresponding abnormal monitoring event obtained by the manager from other agents.

4. The method according to claim 1, characterized in that, There are multiple managers; The process of generating an edge representing the causal relationship between monitoring events corresponding to two vertices and sending it to the manager includes: Obtain the identifier of the user request, calculate the first hash value of the identifier of the user request according to the first hash function, and determine the corresponding manager according to the first hash value; The edges are sent to the identified managers so that edges requested by the same user occur in the same manager; And / or, There are multiple collectors; The step of sending the anomaly vertex corresponding to the abnormal monitoring event and the performance snapshot to the collector for storage includes: The second hash value of the path identifier corresponding to the performance snapshot is calculated according to the second hash function, and the corresponding collector is determined according to the second hash value; The abnormal vertex and the performance snapshot are sent to the determined collector so that the performance snapshots of all vertices on the same path are sent to the same collector. And / or, the manager is configured to: generate a unique path identifier for the path using a third hash function and return it to the agent.

5. A monitoring method for online microservice applications, characterized in that, The online microservice application includes multiple microservice components, which are deployed on a host. The method is applied to a manager in a cluster, which also includes a collector and an agent deployed on the host. The agent is used to perform the steps of the method according to any one of claims 1 to 4; the method includes: Obtain the edge sent by the agent that represents the causal relationship between the monitoring events corresponding to the two vertices; Connect all edges of the same user request to obtain the path, generate a unique path identifier for the path, and return it to the proxy.

6. A monitoring method for online microservice applications, characterized in that, The online microservice application includes multiple microservice components, which are deployed on a host. The method is applied to a collector in a cluster, which also includes a manager and an agent deployed on the host; The agent is used to perform the steps of the method according to any one of claims 1 to 4, and the manager is used to perform the steps of the method according to claim 5; the method includes: Receive abnormal vertices and performance snapshots sent by the agent; Based on the user requests to which each abnormal vertex belongs, a trace chain is generated and stored, which is a causal chain connecting the abnormal vertices of the same user request. The trace chain is used as data for fault detection of the online microservice application. Based on the received performance snapshots, a performance snapshot graph is generated and stored, which is composed of causal connections between vertices in the same path. The performance snapshot graph is used to perform risk detection on the online microservice application.

7. A monitoring system for an online microservice application, characterized in that, The online microservice application includes multiple microservice components, which are deployed on a host. The monitoring system includes: a manager, a collector, and an agent deployed on the host; The agent is used to perform the steps of the method according to any one of claims 1 to 4; The manager is used to perform the steps of the method of claim 5; The collector is used to perform the steps of the method of claim 6.

8. A computer device, characterized in that, The method includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method according to any one of claims 1 to 6.

9. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the steps of the method according to any one of claims 1 to 6.

10. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by a processor, implements the steps of the method according to any one of claims 1 to 6.

Images