End-to-end monitoring method and device and storage medium

Abstract

The invention provides an end-to-end monitoring method, an end-to-end monitoring device and a storage medium, relates to the technical field of information processing, and can realize zero-intrusive full-stack performance monitoring across a user side, a network side and a cloud side. The method comprises the following steps: acquiring configuration information of a service corresponding to a service request; based on the configuration information of the service, determining a monitoring configuration of a user plane device on a communication path of the service, the monitoring configuration being used for instructing the user plane device to collect monitoring information of the service; and sending the monitoring configuration to the user plane equipment.

Description

Technical Field

[0001] The present disclosure relates to the field of information processing technology, and in particular to an end-to-end monitoring method, device, and storage medium. Background Art

[0002] Currently, the main monitoring methods for application services adopt the following technical routes: using Application Performance Monitoring (APM) technology to monitor business functions, framework functions or library functions at the L5-L7 layers; or using Extended Berkeley Packet Filter (EBPF) technology to monitor links, communication paths, system calls, etc. below the L3 layer.

[0003] APM technology uses instrumentation code, which modifies application source code and cannot be embedded in infrastructure, creating observation blind spots. EBPF technology struggles to obtain application performance data through common methods like correlation and aggregation in complex scenarios like cross-threading and asynchronous calls, making it unsuitable for in-depth analysis of application performance.

[0004] Therefore, how to achieve zero-intrusion and full-stack observability in multi-cloud communication and edge computing scenarios has become a problem that must be solved. Summary of the Invention

[0005] The embodiments of the present disclosure provide an end-to-end monitoring method, apparatus, and storage medium, which can implement zero-intrusion full-stack performance monitoring across the user side, network side, and cloud side.

[0006] In one aspect, an end-to-end monitoring method is provided, which is applied to a control plane device and includes:

[0007] Get the configuration information of the service corresponding to the service request;

[0008] determining, based on the configuration information of the service, a monitoring configuration of a user plane device on a communication path of the service, wherein the monitoring configuration is used to instruct the user plane device to collect monitoring information of the service;

[0009] Send the monitoring configuration to the user plane device.

[0010] On the other hand, an end-to-end monitoring method is provided, which is applied to a user plane device, including:

[0011] receiving a monitoring configuration of a service sent by a control plane device, wherein the user plane device is located on a communication path of the service;

[0012] Based on the monitoring configuration, monitoring information of the service is obtained.

[0013] In another aspect, an end-to-end monitoring device is provided, which is applied to a control plane device, comprising:

[0014] The acquisition module is used to obtain the configuration information of the service corresponding to the service request;

[0015] a determining module, configured to determine, based on the configuration information of the service, a monitoring configuration of a user plane device on a communication path of the service, wherein the monitoring configuration is used to instruct the user plane device to collect monitoring information of the service;

[0016] The communication module is also used for the user plane device to send the monitoring configuration.

[0017] On the other hand, an end-to-end monitoring device is provided, which is applied to a user plane device, including:

[0018] a communication module, configured to receive a monitoring configuration of a service sent by a control plane device, the user plane device being located on a communication path of the service;

[0019] An acquisition module is used to acquire monitoring information of the service based on the monitoring configuration.

[0020] On the other hand, a communication device is provided, comprising: a memory and a processor; the memory and the processor are coupled; the memory is used to store a computer program; and the processor implements the end-to-end monitoring method of any of the above embodiments when executing the computer program.

[0021] On the other hand, a computer-readable storage medium is provided, on which computer program instructions are stored. When the computer program instructions are executed by a processor, the end-to-end monitoring method of any of the above embodiments is implemented.

[0022] On the other hand, a computer program product is provided, which includes computer program instructions, and when the computer program instructions are executed by a processor, the end-to-end monitoring method described in any one of the above embodiments is implemented.

[0023] The disclosed embodiments provide an end-to-end monitoring method, in which a control plane device obtains configuration information of a service corresponding to a service request, and then, based on the configuration information of the service, determines and sends corresponding monitoring configurations to user plane devices on the communication path of the service. The monitoring configurations are used to instruct the user plane devices to collect monitoring information of the service. In this way, for different service requests, the monitoring configurations of the user plane devices on the communication path of the service can be flexibly and dynamically configured to meet the service monitoring requirements of different scenarios, and can achieve zero-intrusion full-stack performance monitoring across the user side, network side, and cloud side. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] In order to more clearly illustrate the technical solutions in the present disclosure, the following briefly introduces the drawings required for use in some embodiments of the present disclosure. Obviously, the drawings described below are only drawings of some embodiments of the present disclosure. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0025] Figure 1 A schematic diagram of a packet receiving and sending path provided in some embodiments of the present disclosure Figure 1 ;

[0026] Figure 2 A schematic diagram of a packet sending and receiving path provided in some embodiments of the present disclosure Figure 2 ;

[0027] Figure 3 A schematic diagram of a packet receiving and sending path provided in some embodiments of the present disclosure Figure 3 ;

[0028] Figure 4 A communication scenario diagram provided in some embodiments of the present disclosure Figure 1 ;

[0029] Figure 5 A communication scenario diagram provided in some embodiments of the present disclosure Figure 2 ;

[0030] Figure 6 A communication scenario diagram provided in some embodiments of the present disclosure Figure 3 ;

[0031] Figure 7 A communication scenario diagram provided in some embodiments of the present disclosure Figure 4 ;

[0032] Figure 8 A communication scenario diagram provided in some embodiments of the present disclosure Figure 5 ;

[0033] Figure 9 A communication scenario diagram provided in some embodiments of the present disclosure Figure 6 ;

[0034] Figure 10 The process of an end-to-end monitoring method provided in some embodiments of the present disclosure Figure 1 ;

[0035] Figure 11 A communication scenario diagram provided in some embodiments of the present disclosure Figure 7 ;

[0036] Figure 12 The process of an end-to-end monitoring method provided in some embodiments of the present disclosure Figure 2 ;

[0037] Figure 13 The process of an end-to-end monitoring method provided in some embodiments of the present disclosure Figure 3 ;

[0038] Figure 14 A communication scenario diagram provided in some embodiments of the present disclosure Figure 8 ;

[0039] Figure 15 The process of an end-to-end monitoring method provided in some embodiments of the present disclosure Figure 4 ;

[0040] Figure 16 A communication scenario diagram provided in some embodiments of the present disclosure Figure 9 ;

[0041] Figure 17 A communication scenario diagram provided in some embodiments of the present disclosure Figure 10 ;

[0042] Figure 18 A communication scenario diagram provided in some embodiments of the present disclosure Figure 10 one;

[0043] Figure 19 A communication scenario diagram provided in some embodiments of the present disclosure Figure 10 two;

[0044] Figure 20 A schematic diagram of the structure of an end-to-end monitoring device provided in some embodiments of the present disclosure Figure 1 ;

[0045] Figure 21 A schematic diagram of the structure of an end-to-end monitoring device provided in some embodiments of the present disclosure Figure 2 ;

[0046] Figure 22 A schematic structural diagram of a communication device provided in some embodiments of the present disclosure. DETAILED DESCRIPTION

[0047] The following will clearly and completely describe the technical solutions of this disclosure in conjunction with the accompanying drawings. Obviously, the embodiments described are only part of the embodiments of this disclosure, not all of them. All other embodiments obtained by ordinary technicians in this field based on the embodiments of this disclosure without making any creative efforts shall fall within the scope of protection of this disclosure.

[0048] It should be noted that in this disclosure, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described in this disclosure as "exemplary" or "for example" should not be construed as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0049] In the following, the terms "first" and "second" are used for descriptive purposes only and should not be understood to indicate or imply relative importance or implicitly specify the quantity of the technical features indicated. Therefore, a feature specified as "first" or "second" may explicitly or implicitly include one or more of the features.

[0050] In the description of this disclosure, unless otherwise specified, " / " means "or." For example, A / B can mean A or B. "And / or" in this document simply describes an association relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can mean: A exists alone, A and B exists simultaneously, and B exists alone. Furthermore, "at least one" means one or more, and "a plurality" means two or more.

[0051] In order to facilitate understanding of the technical solutions of the embodiments of the present application, the following is a brief introduction to the technologies involved in the embodiments of the present application.

[0052] 1. APM technology.

[0053] APM technology primarily uses instrumentation to obtain a rich set of observation signals from microservices, including metrics, traces, logs, and function performance analysis. Therefore, APM technology enables systematic, in-depth, and comprehensive measurement of microservices. However, instrumentation also presents a number of challenges for APM, primarily in the following areas:

[0054] (1) Inserting code will modify the application source code and require re-release. For example, using bytecode enhancement technologies such as JavaAgent also requires modifying the application startup parameters and re-releasing it. In addition, when an application injects multiple Java Agents, a series of compatibility issues may arise, such as conflicts between different Agents at runtime, making code maintenance much more difficult.

[0055] (2) Different instrumentation codes may cause maintenance difficulties due to different versions and logical conflicts.

[0056] (3) Some applications (such as infrastructure such as gateways on the communication path) become observation blind spots because they cannot be instrumented, resulting in the inability to detect and locate faults in a timely manner. For example, with the development of cloud native and service mesh technologies, the communication link between two services may span multiple sidecars, virtual bridges, gateways, etc. APM usually only focuses on the business code or framework / library function level, and cannot instrument nodes such as gateways on the communication path to obtain observation data. Therefore, when a fault occurs on the communication path, it is difficult to detect the fault in a timely manner relying solely on APM technology.

[0057] 2. EBPF technology.

[0058] EBPF is a kernel technology that allows developers to run specific functions without modifying the kernel code. Specifically, EBPF allows regular user-space applications to package the logic to be executed in the Linux kernel as bytecode. When certain events (called hooks, which can be system calls or network events, etc.) occur, the Linux kernel dynamically loads and executes the compiled code.

[0059] For example, Figure 1 As shown in Figure 1, the traditional packet transmission and reception path includes the following: a network card receives a data packet through the Ethernet interface (ethθ); the packet passes through a point (also called a hook) in the eXpress Data Path (XDP) where custom code can be inserted, and is then transmitted to the Linux kernel. The Linux kernel allocates memory for the packet using the alloc skb function and then sends it to the kernel protocol stack. The kernel protocol stack performs Generic Receive Offloading (GRO) on the packet, reassembling fragmented packets. The packet enters the ingress hook of the traffic control (TC) and then enters the Linux subsystem (Netfilter). A pre-processing hook (PREROUTING hook) processes iptables rules in the raw table before the packet enters the network protocol stack. The packet passes through the kernel's connection tracking (conntrack) module; the iptables rules in the mangle table used to modify the packet are processed at the PREROUTING hook; and the iptables rules in the NAT table used for network address translation are processed at the PREROUTING hook.

[0060] Next, the forwarding information base (FIB) is searched for information about fast packet forwarding. Four more Netfilter processing points follow: the FORWARD hook, which processes iptables rules in the mangle table before forwarding the packet to the destination host after the routing decision is made; the FORWARD hook, which processes iptables rules in the filter table; the POSTROUTING hook, which processes iptables rules in the mangle table after the packet leaves the local host; and the POSTROUTING hook, which processes iptables rules in the NAT table.

[0061] When a packet reaches the TC's egress hook, it performs an egress check, determining whether the packet is destined for the local device or an external host. Furthermore, before sending the packet, it undergoes Generic Segmentation Offload (GSO) fragmentation.

[0062] like Figure 2 As shown in the figure, compared to the traditional packet sending and receiving path, the EBPF data transmission path is short-circuited, creating a shortcut from TCingress directly to TC egress, eliminating intermediate steps. As can be seen, EBPF technology can implement packet redirection and flow control within the kernel, significantly shortening the packet processing path and latency.

[0063] In addition, if Figure 3 As shown, based on the EBPF technology, it is also possible to realize the transmission of data packets when the destination node is a service node on another host.

[0064] In summary, unlike APM technology, EBPF technology does not require the implantation of instrumentation code. Instead, it extends kernel functionality by running the program in a sandbox, acquiring external data from the application (for example, using various probe functions (such as kprobe, tracepoint, uprobe, etc.) to collect metrics, traces, logs, and other information from kernel system calls and user function calls). This information is then correlated using thread IDs. Due to the mapping relationship between kernel-mode threads and user-mode threads, correlation using thread IDs can be simple (for example, different user calls correspond to different user-mode threads and have different thread IDs) or complex (for example, a single user call needs to be implemented by different threads), and may even require additional information (such as the introduction of service semantics). After correlation is complete, it is necessary to identify the application protocol, further aggregate information from different flows to obtain the application's call log, and further calculate full-stack performance metrics.

[0065] Because EBPF technology lacks instrumentation, it doesn't modify applications, thus avoiding re-releases and code conflicts. This feature allows EBPF to run securely on infrastructure (such as gateways along communication paths), effectively avoiding observation blind spots. However, because EBPF collects raw byte streams, it can't use common methods to extract service semantics. Furthermore, in complex scenarios like cross-threading and asynchronous calls, it's difficult to obtain application performance data through common methods like correlation and aggregation. Therefore, EBPF is not suitable for in-depth analysis of application performance.

[0066] 3. Operations, Administration and Maintenance (OAM) technology.

[0067] To monitor and manage the status and performance of devices in Ethernet networks, various OAM technologies have been designed. These technologies can operate in different scenarios. For example, Bidirectional Forwarding Detection (BFD) detects data link errors between two given points (which may be two network nodes connected by a single link or two network nodes connected by a multi-hop link); Inband Network Telemetry (INT) collects, carries, organizes, and reports network status through data plane services; and Ping tests connectivity and latency between hosts by sending Internet Control Message Protocol (ICMP) echo requests and receiving echo replies.

[0068] However, current network OAM technologies were originally designed to facilitate network operations and maintenance for operators. Therefore, these technologies struggle to perceive services, collect service-related data, and feed it back to the controller for orchestration, scheduling, routing, and other policy adjustments. Furthermore, each cloud provider typically deploys network OAM technology within its central cloud for performance monitoring. However, in multi-cloud scenarios spanning different physical locations (e.g., edge cloud, central cloud), or even across different cloud providers, there is a lack of effective performance monitoring solutions to perceive services and observe network infrastructure performance.

[0069] The above is an introduction to some of the technologies involved in the embodiments of the present invention, which will not be elaborated below.

[0070] Traditional developers typically develop applications as a single, indivisible monolith. However, as application functionality grows in complexity, this development model exponentially increases the difficulty of operating and maintaining the application. To address this, developers are beginning to break applications down into logically independent functional modules and develop each module separately. These modules are called "microservices." In a microservices architecture, the functionality of a monolithic application can be implemented by users accessing the first microservice and then enabling communication between microservices.

[0071] Traditional monolithic applications are typically deployed and run on a single service node provided by a cloud service provider. When a user runs an application, data flows north-south from the user to the service node. With the increasing complexity of application functionality and the ubiquitous deployment of cloud services, the deployment model for microservice modules in a microservices architecture has evolved from deploying all services on a single service node of a single cloud service provider to deploying them across multiple service nodes of a single cloud service provider, or even across multiple service nodes of different cloud service providers. Therefore, when a user runs an application, data flows north-south from the user to the service node, and east-west between service nodes.

[0072] Furthermore, a single end-user request often involves multiple services. Different services may be implemented by different teams and programming languages, and deployed across thousands of service nodes across various data centers and data centers. Therefore, understanding system health and service performance, and promptly identifying and troubleshooting issues, is crucial to maintaining normal application operation.

[0073] For example, Figure 4 As shown in (a) in Figure 2, when microservices are deployed in a service instance of a Pod, microservices can communicate directly with each other; Figure 4As shown in (b) in Figure 2, when microservices are deployed in multiple service nodes of a Pod, the communication path between microservices needs to pass through the proxy device (Proxy) of the service node, such as sidecar. Figure 4 As shown in Figure (c), when microservices are deployed in different service nodes of different cloud service providers (CSPs), the communication paths between microservices may pass through multiple checkpoints, such as proxy devices and cloud gateways, making the communication paths very complex. Given that the input parameters of one microservice may be the results of the operation of other microservices, monitoring the status of each microservice and the communication paths between them is crucial to maintaining normal application operation.

[0074] Currently, there are two main technical approaches for monitoring microservices: using APM technology to monitor business functions, framework functions, or library functions at the L5-L7 layers, or using EBPF technology to monitor links, communication paths, system calls, etc. below the L3 layer.

[0075] APM technology uses instrumentation code, which modifies application source code and cannot be embedded in infrastructure, creating observation blind spots. EBPF technology struggles to obtain application performance data through common methods like correlation and aggregation in complex scenarios like cross-threading and asynchronous calls, making it unsuitable for in-depth analysis of application performance.

[0076] At the same time, with the emergence of new applications such as extended reality (XR) and the metaverse, users are increasingly demanding high-quality viewing experiences within limited computing and network resources. To ensure a high-quality experience despite fluctuations in computing and network resources, achieving zero-intrusion, full-stack observability in future multi-cloud communications and edge computing scenarios is a crucial challenge, and the industry currently lacks a clear solution.

[0077] To address these technical issues, we designed a simple and feasible observability solution based on a comprehensive consideration of the advantages and disadvantages of related technologies (such as APM and EBPF). This solution can understand the observability needs of different applications, flexibly and dynamically set observability solution parameters, and focus on collecting performance metrics in key areas (such as performance bottlenecks or suspected fault areas), thereby achieving efficient and rapid fault diagnosis and performance optimization.

[0078] Specifically, the embodiment of the present disclosure provides an end-to-end monitoring method, the idea of ​​which is that: the control plane device obtains the configuration information of the service corresponding to the service request, and then based on the configuration information of the service, determines and sends the corresponding monitoring configuration to the user plane device on the communication path of the service, and the monitoring configuration is used to instruct the user plane device to collect the monitoring information of the service; in this way, for different service requests, the monitoring configuration of the user plane device on the communication path of the service can be flexibly and dynamically configured to adapt to the service monitoring needs of different scenarios, and can achieve zero-intrusion full-stack performance monitoring across the user side, network side and cloud side.

[0079] The end-to-end monitoring method provided by the embodiments of the present disclosure is described in detail below with reference to the accompanying drawings.

[0080] It should be noted that the services involved in the embodiments of the present disclosure include microservices, or other application services, etc., which are not limited in the embodiments of the present disclosure.

[0081] First, an embodiment of the present disclosure provides an end-to-end monitoring system, which includes: a user plane device and a control plane device.

[0082] In some embodiments, the user plane device includes at least one of the following: a router device deployed on the network side, a proxy device deployed on the cloud side service node, a gateway device deployed on the cloud side, and an access gateway device deployed on the user side.

[0083] For example, the cloud side may be a data center (DC), an edge cloud, etc. For ease of explanation, the following description is made taking the cloud side as a DC as an example.

[0084] In some embodiments, the control plane device includes, but is not limited to, at least one of the following: a controller and an orchestrator.

[0085] In some embodiments, the embodiments of the present disclosure deploy a performance monitoring and orchestration logic functional module in the control plane device, which is used to deploy differentiated monitoring configurations (a mechanism for monitoring service performance) on user plane devices (e.g., user-side devices, network-side devices, and cloud-side devices, etc.) on the communication path based on the configuration information of the service (e.g., service semantics) to collect measurement information reported by the user plane devices, such as traces, logs, metrics, etc.; by integrating and associating scattered measurement information, end-to-end performance indicators can be obtained.

[0086] The deployment mode of the above performance monitoring and orchestration logic function module can be distributed or centralized. Figure 5As shown, the performance monitoring and orchestration logic function modules can be centrally deployed in the orchestrator, and then the orchestrator sends the respective monitoring configurations to the user plane devices on the communication path. Figure 6 As shown, the performance monitoring and orchestration logic function modules can be distributedly deployed in various controllers of the network.

[0087] In some embodiments, an interface exists between the performance monitoring and orchestration logic function module and other logic function modules of the control plane device.

[0088] Exemplarily, there is an interface a between the performance monitoring and orchestration logic function module and the service registration management logic function module, which is used to obtain the service identification and address information of the service node running the service (for example, the Internet Protocol (IP) address). In this way, the performance monitoring and orchestration logic function module can select a differentiated performance monitoring mechanism based on the information obtained.

[0089] Exemplarily, there is an interface b between the performance monitoring and orchestration logic function module and the routing decision logic function module, which is used to obtain routing information of the service, for example, the north-south path between the user and the service node running the service and the communication path between the service nodes running the service. In this way, the performance monitoring and orchestration logic function module can configure the communication infrastructure (for example, gateways, routers, etc.) on the communication path based on the obtained routing information to start the performance monitoring mechanism of the perception service.

[0090] In some embodiments, the end-to-end monitoring system can be applied in scenarios including user-side, network-side, and cloud-side, involving north-south data flow from the user-side to the cloud-side, as well as east-west data flow between different clouds. The application running on the user-side device consists of at least two services, which may have a variety of deployment scenarios, including, for example, the following:

[0091] Scenario 1: Deployed in a DC.

[0092] like Figure 7 As shown, the service nodes running the services are deployed in a DC, and the communication path between the services passes through a proxy device (Proxy). Exemplarily, the proxy device can be a sidecar.

[0093] For example, Figure 7As shown, the data center includes service node A and service node B. The data flow flows in from the traffic inlet (ingress) of service node A, passes through proxy device A to reach service node A; when flowing out, the data flow passes through proxy device A and flows out from the traffic outlet (egress) of service node A; then, the data flow flows in through the traffic inlet of service node B, passes through proxy device B to reach service node B; when flowing out, the data flow passes through proxy device B and flows out from the traffic outlet of service node B.

[0094] Scenario 2: Cross-DC deployment

[0095] like Figure 8 As shown, the service nodes running the services are deployed in multiple DCs, and the communication paths between services pass through the gateway devices and proxy devices of the DCs.

[0096] For example, Figure 8 As shown, data center A includes service node A, and data center B includes service node B; the data flow flows into data center A through gateway device A of data center A, flows in from the traffic inlet of service node A, and reaches service node A through proxy device A; when flowing out, the data flow passes through proxy device A and flows out from the traffic outlet of service node A; then, the data flow passes through gateway device A of data center A to reach gateway device B of data center B, flows into data center B through gateway device B, and then flows in from the traffic inlet of service node B, passes through proxy device B to service node B; when flowing out, the data flow passes through proxy device B and flows out from the traffic outlet of service node B.

[0097] Scenario 3: Edge deployment

[0098] like Figure 9 As shown, the service nodes running the services are deployed in the edge DC, and the communication path between services passes through the gateway device, proxy device and wide area network of the edge DC.

[0099] For example, Figure 9 As shown, service node A is located in edge data center A, and service node B is located in edge data center B; the data flow flows into edge data center A through the gateway device of edge data center A, flows in from the traffic inlet of service node A, and reaches service node A through proxy device A; when flowing out, the data flow passes through proxy device A, flows out from the traffic outlet of service node A, reaches the gateway device of edge data center A, then passes through the router device in the wide area network, reaches the gateway device of edge data center B, flows into edge data center B through the gateway device of edge data center B, then flows in from the traffic inlet of service node B, passes through proxy device B to reach service node B; when flowing out, the data flow passes through proxy device B, and flows out from the traffic outlet of service node B.

[0100] It is understandable that the application scenarios of the embodiments of the present disclosure are not limited. The system architecture and business scenarios described in the embodiments of the present disclosure are intended to more clearly illustrate the technical solutions of the embodiments of the present disclosure and do not constitute a limitation on the technical solutions provided by the embodiments of the present disclosure. Those skilled in the art will appreciate that with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided by the embodiments of the present disclosure are equally applicable to similar technical problems.

[0101] The present disclosure provides an end-to-end monitoring method, such as Figure 10 As shown, the method includes the following steps:

[0102] S201. A control plane device obtains configuration information of a service corresponding to a service request.

[0103] In some embodiments, the configuration information of the service includes at least one of the following: an identifier of the service, address information of a service node running the service, and routing information of the service.

[0104] In some embodiments, the service request is issued by a user equipment (UE). Therefore, after the control plane device obtains configuration information of the service corresponding to the service request based on the service request, the method further includes: the control plane device sends a response message to the service request to the UE, where the response message to the service request includes an identifier of the service.

[0105] For example, Figure 11 As shown, when a user issues a new service request, the service request is sent to the control plane device for processing; in response to the service request, the control plane device calls interface a to obtain the service identifier and the address information of the service node running the service from the service registration management logic function module; the control plane device calls interface b to obtain the routing information of the service from the routing decision logic function module.

[0106] S202: The control plane device determines the monitoring configuration of the user plane device on the communication path of the service based on the configuration information of the service.

[0107] The monitoring configuration is used to instruct the user plane device to collect monitoring information of the service.

[0108] Exemplarily, the monitoring configuration includes at least one of the following: APM monitoring configuration, EPBF mechanism, OAM mechanism, and service identification.

[0109] Exemplarily, the monitoring information includes at least one of the following: trace information, metrics information, and logs information.

[0110] In some embodiments, when the user-side device includes: a router device deployed on the network side, a proxy device deployed on the cloud-side service node, a gateway device deployed on the cloud side, and an access gateway device deployed on the user side, the above step S202 can be implemented as: based on the configuration information of the service, determining the first monitoring configuration of the router device, the second monitoring configuration of the proxy device, and the third monitoring configuration of the gateway device.

[0111] Among them, the first monitoring configuration, the second monitoring configuration and the third monitoring configuration can be the same or different.

[0112] In some embodiments, as Figure 12 As shown, the above step S202 can be implemented as the following steps S2021-S2023.

[0113] S2021. The control plane device determines a monitoring plan for the service based on the service identifier.

[0114] It is understandable that the control plane device can select a suitable monitoring solution for the service based on the service identification. In this way, the control plane device can select an effective monitoring solution for performance monitoring based on the differences between different services, thereby enhancing the observability of the service's communication link.

[0115] S2022: The control plane device determines a user plane device on the communication path based on the address information of the service node running the service and the routing information of the service.

[0116] Exemplarily, the routing information of the service includes a communication path. When the service nodes running the service are located on the same cloud side, the user plane devices on the communication path include: a proxy device deployed on the cloud side service node.

[0117] Exemplarily, the routing information of the service includes a communication path. When the service nodes running the service are located on different cloud sides, the user plane devices on the communication path include: a gateway device deployed on the cloud side and a proxy device deployed on the cloud side service node.

[0118] Exemplarily, the routing information of the service includes a communication path. When the service nodes running the service are located on the edge cloud side, the user-side devices on the communication path include: a gateway device deployed on the cloud side, a router device deployed on the network side, and a proxy device deployed on the cloud side service node.

[0119] S2023. The control plane device configures the monitoring configuration of the user plane device based on the monitoring solution of the service.

[0120] For example, when the user-plane devices include a gateway device deployed on the cloud side, a router device deployed on the network side, and a proxy device deployed on the cloud side service node, step S2023 may be implemented by configuring the monitoring configuration of the gateway device, configuring the monitoring configuration of the router device, and configuring the monitoring configuration of the proxy device based on the service monitoring solution. The monitoring configuration of the gateway device, the monitoring configuration of the router device, and the monitoring configuration of the proxy device may be the same or different.

[0121] Exemplarily, in the case where the user-side device includes: a gateway device deployed on the cloud side, a router device deployed on the network side, and a proxy device deployed on the cloud-side service node, based on the service monitoring solution, the gateway device deployed on the cloud side is configured with context information (context) delivery rules for the service identifier (for example, the delivery rules can specify the sampling frequency, and the content of the context delivery, etc.), so as to trigger the APM mechanism for the service identifier; based on the service monitoring solution, the proxy device deployed on the cloud-side service node is configured with kernel information collection rules for the service identifier (for example, the kernel information collection rules include collection parameter categories, such as input or output (IO) throughput, latency, error rate, etc.), so as to load the EBPF mechanism for the service identifier; based on the service monitoring solution, the router device deployed on the network side is configured with packet header field addition rules for the service identifier, so as to trigger the OAM mechanism (for example, INT) for the service identifier.

[0122] S203: The control plane device sends a monitoring configuration to the user plane device; accordingly, the user plane device receives the monitoring configuration sent by the control plane device.

[0123] It should be noted that the embodiment of the present application does not limit the transmission method of the monitoring configuration.

[0124] S204: The user plane device obtains monitoring information of the service based on the monitoring configuration.

[0125] In some embodiments, as Figure 13 As shown, the above step S204 can be implemented as the following steps S2041-S2043.

[0126] S2041. The user plane device receives a first message.

[0127] Wherein, the above-mentioned first message is generated by UE. For example, Figure 14As shown, after receiving the response message to the service request, the UE obtains the service identifier from the response message and then generates a first message carrying the service identifier. During this process, the service identifier needs to be passed down from the L7 layer to the L4 layer and the L3 layer and carried in the message header; for example, this can be done through the uprobe function in the EBPF technology.

[0128] S2042: The user plane device detects whether the first message carries a service identifier.

[0129] Illustratively, the service identifier may be carried in a message header, and the user plane device may detect whether the message header of the first message carries the service identifier.

[0130] S2043: When the first message carries the service identifier, the user plane device triggers the monitoring configuration of the service based on the service identifier and obtains the monitoring information of the service.

[0131] For example, Figure 14 As shown, it is assumed that the user plane devices include: router devices, gateway devices and proxy devices; it is assumed that the OAM mechanism is configured in the router device, the APM mechanism is configured in the gateway device, and the EBPF mechanism is configured in the proxy device. When the first message passes through the router device in the wide area network, the router device can determine whether it is necessary to trigger the OAM mechanism (such as BFD, INT, etc.) and set relevant parameters based on the service identifier in the message header of the first message. When the first message passes through the gateway device, the gateway device reads the service identifier in the message header, determines whether to start the APM mechanism (such as distributed tracing mechanism) based on the service identifier, and sets relevant parameters (such as sampling frequency, context content, etc.). When the first message passes through the proxy device in the service node, the proxy device triggers the EBPF program based on the service identifier in the message header, determines whether it is necessary to collect information and the category of collected information (such as IO throughput, latency, error rate, etc.), and uses the service identifier to associate and obtain flow-related trace, metrics, logs and other information.

[0132] In some embodiments, when the first service completes its operation, the next-hop service is called. At this point, the service node running the first service obtains the identifier of the second service and sends a message carrying that identifier. For example, the identifier of the second service can be obtained from a domain name resolution service node. Similarly, during this process, the identifier of the second service is passed down from the L7 layer to the L4 and L3 layers and carried in the message header.

[0133] In some embodiments, as Figure 15 As shown, the above method further includes the following steps:

[0134] S205: The user plane device sends monitoring information to the control plane device; correspondingly, the control plane device receives the monitoring information sent by the user plane device.

[0135] S206: The control plane device obtains an end-to-end performance indicator of the service based on the monitoring information of the service sent by the user plane device.

[0136] In some embodiments, the control plane device integrates the monitoring information of the service collected by each user plane device on the communication path to obtain an end-to-end performance indicator of the service.

[0137] Exemplarily, the end-to-end performance indicator may include at least one of the following: integrated metrics, traces, and logs.

[0138] It is understandable that since the information collected by a single device cannot reflect the end-to-end performance, all user-plane devices that trigger the monitoring configuration (such as proxy devices, router devices, gateway devices, etc.) need to report the collected service monitoring information to the control-plane device, which will be integrated by the control-plane device to obtain end-to-end performance indicators.

[0139] For example, Figure 16 As shown, the user plane device (such as a proxy device, a router device, a gateway device, etc.) reports the collected service monitoring information (such as tracking information, log information, and indicator information) to the control plane device for analysis and processing; wherein the reported information will carry the identification of the user plane device, the identification of the service, and the obtained data flow and user information (such as a five-tuple or a network traffic identifier (flow ID)), so that the control plane device can integrate and obtain end-to-end (across end, network, and cloud) data flow information related to the application corresponding to the service request.

[0140] S207. The control plane device performs operation and maintenance management on the service based on the end-to-end performance indicators.

[0141] It is understandable that the data flow information can be directly used by the control plane equipment, for example, to obtain a panoramic view of the entire application call; or to quickly locate the fault or performance bottleneck position for operation and maintenance management.

[0142] In some embodiments, the method further includes: the control plane device sending the end-to-end performance indicator to other control plane devices, so that the other control plane devices optimize the performance of the service based on the end-to-end performance indicator.

[0143] It is understandable that the end-to-end performance indicators can also be fed back to other control plane devices or other logical functional modules (for example, routing decision logical functional modules) through interfaces to optimize service performance.

[0144] For ease of understanding, the end-to-end monitoring method provided by the embodiment of the present disclosure is described below in the form of examples.

[0145] For example, Figure 17 As shown in the figure, in scenario 1, the service node running the service is deployed in a DC. Therefore, the service communication path only passes through the proxy devices in the two service nodes. Assuming that the EBPF mechanism is configured in the proxy device, when a message carrying the service identifier passes through the proxy device, the EBPF mechanism is triggered based on the service identifier in the message header. It determines whether information needs to be collected and the type of information to be collected (for example, I / O throughput, latency, or error rate). Then, based on the service identifier, it collects service monitoring information and associates it to obtain flow-related traces, metrics, and logs.

[0146] For example, Figure 18 As shown, in scenario 2, the service nodes running the service are deployed in two DCs, and the communication path between the services passes through the gateway devices of the two DCs and the proxy devices of the two service nodes. Assume that the EBPF mechanism is configured in the proxy device and the APM mechanism is configured in the gateway device. When the message carrying the service identifier passes through the gateway device, the service identifier in the message header is read to determine whether to start the corresponding APM mechanism (for example, distributed tracing mechanism), and set relevant parameters (for example, sampling frequency, content of context transmission, etc.). When the message carrying the service identifier passes through the proxy device, based on the service identifier in the message header, the EBPF mechanism is triggered, and it is determined whether information needs to be collected and the category of information to be collected (for example, IO throughput, latency or error rate, etc.), and then the monitoring information of the service is collected based on the service identifier, and the flow-related traces, metrics and logs are associated.

[0147] For example, Figure 19As shown in Scenario 3, the service nodes running the services are deployed in edge DCs. The communication path between services needs to cross the WAN, passing through the gateway devices, proxy devices, and router devices in the edge DC. Assume that the EBPF mechanism is configured in the proxy device, the APM mechanism is configured in the gateway device, and the OAM mechanism is configured in the router device. When a packet carrying the service identifier passes through the router device in the WAN, the OAM mechanism can be determined based on the service identifier in the packet header to trigger the OAM mechanism and set relevant parameters. When a packet carrying the service identifier passes through the gateway device, the gateway device reads the service identifier in the packet header and determines whether the APM mechanism (e.g., a distributed tracing mechanism) needs to be triggered based on the service identifier and sets relevant parameters (e.g., sampling frequency, context content, etc.). When a packet carrying the service identifier passes through the proxy device, the EBPF mechanism can be triggered based on the service identifier in the packet header to determine whether information needs to be collected and the type of information to be collected (e.g., I / O throughput, latency, or error rate). The service identifier is used to collect service monitoring information and correlate it to obtain flow-related traces, metrics, and logs.

[0148] The above mainly introduces the solution of the embodiment of the present disclosure from the perspective of method. It can be understood that in order to realize the above functions, the end-to-end monitoring device includes at least one of the hardware structure and software modules corresponding to the execution of each function. It should be easy for those skilled in the art to realize that, in combination with the units and algorithm steps of each example described in the embodiment disclosed herein, the embodiment of the present disclosure can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the embodiment of the present disclosure.

[0149] The embodiment of the present disclosure can divide the end-to-end monitoring device into functional modules according to the above-mentioned method embodiment. For example, each functional module can be divided corresponding to each function, or two or more functions can be integrated into one functional module. The above-mentioned integrated module can be implemented in the form of hardware or software. It should be noted that the division of modules in the embodiment of the present disclosure is schematic and is only a logical function division. There may be other division methods in actual implementation. The following is an example of dividing each functional module corresponding to each function.

[0150] Figure 20This is a schematic diagram of the structure of an end-to-end monitoring device provided by an embodiment of the present disclosure. The end-to-end monitoring device is applied to a control plane device and can execute the end-to-end monitoring method provided by the above method embodiment. Figure 20 As shown, the end-to-end monitoring device 600 includes: an acquisition module 601 , a determination module 602 , and a communication module 603 . In other embodiments, the end-to-end monitoring device 600 further includes: a management module 604 .

[0151] The acquisition module 601 is used to acquire configuration information of the service corresponding to the service request.

[0152] The determination module 602 is configured to determine a monitoring configuration of a user plane device on a communication path of the service based on configuration information of the service, where the monitoring configuration is used to instruct the user plane device to collect monitoring information of the service.

[0153] The communication module 603 is configured to send monitoring configuration to the user plane device.

[0154] In some embodiments, the configuration information of the service includes at least one of the following: an identifier of the service, address information of a service node running the service, and routing information of the service.

[0155] In some embodiments, the determination module 602 is specifically used to determine a monitoring plan for the service based on the identification of the service; determine the user plane device on the communication path based on the address information of the service node running the service and the routing information of the service; and configure the monitoring configuration of the user plane device based on the monitoring plan of the service.

[0156] In some embodiments, the user plane device includes at least one of the following: a router device deployed on the network side, a proxy device deployed on the cloud side service node, a gateway device deployed on the cloud side, and an access gateway device deployed on the user side.

[0157] In some embodiments, the determination module 602 is specifically configured to determine a first monitoring configuration of the router device, a second monitoring configuration of the proxy device, and a third monitoring configuration of the gateway device based on the configuration information of the service.

[0158] In some embodiments, the monitoring configuration includes at least one of the following: APM monitoring configuration, EPBF mechanism, OAM mechanism, and service identification.

[0159] In some embodiments, the monitoring information of the service includes at least one of the following: tracking information, log information, and indicator information.

[0160] In some embodiments, the communication module 603 is further configured to receive service monitoring information sent by a user plane device.

[0161] In some embodiments, the management module 604 is configured to obtain end-to-end performance indicators of the service based on monitoring information of the service sent by the user plane device; and perform operation and maintenance management of the service based on the end-to-end performance indicators.

[0162] In some embodiments, the communication module 603 is further configured to send the end-to-end performance indicator to other control plane devices, so that the other control plane devices optimize the performance of the service based on the end-to-end performance indicator.

[0163] In some embodiments, the communication module 603 is further configured to send a response message of the service request to the user equipment, where the response message of the service request includes an identifier of the service.

[0164] Figure 21 This is a schematic diagram of the structure of another end-to-end monitoring device provided by an embodiment of the present disclosure. The end-to-end monitoring device is applied to a user plane device and can execute the end-to-end monitoring method provided by the above method embodiment. Figure 21 As shown, the end-to-end monitoring device 700 includes: a communication module 701 and an acquisition module 702 .

[0165] The communication module 701 is configured to receive a monitoring configuration of a service sent by a control plane device, where the user plane device is located on a communication path of the service.

[0166] The acquisition module 702 is used to acquire monitoring information of the service based on the monitoring configuration.

[0167] In some embodiments, the communication module 701 is further configured to send monitoring information to the control plane device.

[0168] In some embodiments, the acquisition module 702 is specifically used to receive a first message; detect whether the first message carries a service identifier; if the first message carries a service identifier, trigger the service monitoring configuration based on the service identifier to obtain service monitoring information.

[0169] In the case of implementing the functions of the above-mentioned integrated modules in the form of hardware, the embodiments of the present disclosure provide a possible structure of the communication device involved in the above-mentioned embodiments. Figure 22 As shown, the communication device 800 includes: a processor 802 and a bus 804. Optionally, the communication device may further include a memory 801; and optionally, the communication device 800 may further include a communication interface 803.

[0170] Processor 802 may implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the embodiments of this disclosure. Processor 802 may be a central processing unit, a general-purpose processor, a digital signal processor, an application-specific integrated circuit, a field-programmable gate array, or other programmable logic device, a transistor logic device, a hardware component, or any combination thereof. It may implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the embodiments of this disclosure. Processor 802 may also be a combination that implements computing functions, such as a combination of one or more microprocessors, or a combination of a DSP and a microprocessor.

[0171] The communication interface 803 is used to connect to other devices via a communication network, such as Ethernet, wireless access network, wireless local area network (WLAN), etc.

[0172] The memory 801 may be a read-only memory (ROM) or other type of static storage device that can store static information and instructions, a random access memory (RAM) or other type of dynamic storage device that can store information and instructions, or an electrically erasable programmable read-only memory (EEPROM), a disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto.

[0173] As a possible implementation, the memory 801 can exist independently of the processor 802. The memory 801 can be connected to the processor 802 via a bus 804 to store instructions or program codes. When the processor 802 calls and executes the instructions or program codes stored in the memory 801, the end-to-end monitoring method provided by the embodiment of the present disclosure can be implemented. In another possible implementation, the memory 801 can also be integrated with the processor 802.

[0174] The bus 804 may be an extended industry standard architecture (EISA) bus, etc. The bus 804 may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 22 Only one thick line is used in the diagram, but this does not mean that there is only one bus or one type of bus.

[0175] Some embodiments of the present disclosure provide a computer-readable storage medium (e.g., a non-transitory computer-readable storage medium), which stores computer program instructions. When the computer program instructions are executed on a computer, the computer executes the end-to-end monitoring method as described in any of the above embodiments.

[0176] Exemplarily, the above-mentioned computer-readable storage media may include, but are not limited to: magnetic storage devices (e.g., hard disks, floppy disks, or magnetic tapes, etc.), optical disks (e.g., compact disks (CDs), digital versatile disks (DVDs), etc.), smart cards, and flash memory devices (e.g., erasable programmable read-only memories (EPROMs), cards, sticks, or key drives, etc.). The various computer-readable storage media described in the present disclosure may represent one or more devices and / or other machine-readable storage media for storing information. The term "machine-readable storage medium" may include, but is not limited to, wireless channels and various other media capable of storing, containing, and / or carrying instructions and / or data.

[0177] An embodiment of the present disclosure provides a computer program product comprising instructions. When the computer program product is run on a computer, the computer is enabled to execute the end-to-end monitoring method described in any one of the above embodiments.

[0178] The above is only a specific embodiment of the present disclosure, but the scope of protection of the present disclosure is not limited thereto. Any changes or replacements within the technical scope disclosed in the present disclosure should be included in the scope of protection of the present disclosure. Therefore, the scope of protection of the present disclosure should be based on the scope of protection of the claims.

Claims

1. An end-to-end monitoring method, characterized in that: Applied to a control plane device, the method includes: Get the configuration information of the service corresponding to the service request; determining, based on the configuration information of the service, a monitoring configuration of a user plane device on a communication path of the service, wherein the monitoring configuration is used to instruct the user plane device to collect monitoring information of the service; Send the monitoring configuration to the user plane device.

2. The method according to claim 1, characterized in that The configuration information of the service includes at least one of the following: an identifier of the service, address information of a service node running the service, and routing information of the service.

3. The method according to claim 2, characterized in that The determining, based on the configuration information of the service, a monitoring configuration of a user plane device on a communication path of the service includes: Determining a monitoring plan for the service based on the identifier of the service; determining the user plane device on the communication path based on the address information of the service node running the service and the routing information of the service; Based on the monitoring solution of the service, a monitoring configuration of the user plane device is configured.

4. The method according to claim 1, wherein The user plane device includes at least one of the following: a router device deployed on the network side, a proxy device deployed on the cloud side service node, a gateway device deployed on the cloud side, and an access gateway device deployed on the user side.

5. The method according to claim 4, characterized in that The determining, based on the configuration information of the service, a monitoring configuration of a user plane device on a communication path of the service includes: Based on the configuration information of the service, a first monitoring configuration of the router device, a second monitoring configuration of the proxy device, and a third monitoring configuration of the gateway device are determined.

6. The method according to claim 1, characterized in that The monitoring configuration includes at least one of the following: application performance APM monitoring configuration, Berkeley Packet Filter EPBF mechanism, operation maintenance management OAM mechanism, and the identifier of the service.

7. The method according to claim 1, characterized in that The monitoring information of the service includes at least one of the following: tracking information, log information, and indicator information.

8. The method according to claim 1, characterized in that The method further comprises: Receive monitoring information of the service sent by the user plane device.

9. The method according to claim 8, characterized in that The method further comprises: Obtaining an end-to-end performance indicator of the service based on the monitoring information of the service sent by the user plane device; The service is operated and maintained based on the end-to-end performance indicators.

10. The method according to claim 9, characterized in that The method further comprises: The end-to-end performance indicator is sent to other control plane devices, so that the other control plane devices optimize the performance of the service based on the end-to-end performance indicator.

11. The method according to claim 2, characterized in that The method further comprises: A response message to the service request is sent to the user equipment, where the response message to the service request includes an identifier of the service.

12. An end-to-end monitoring method, characterized in that: Applied to a user plane device, the method includes: receiving a monitoring configuration of a service sent by a control plane device, wherein the user plane device is located on a communication path of the service; Based on the monitoring configuration, monitoring information of the service is obtained.

13. The method according to claim 12, characterized in that The method further comprises: The monitoring information is sent to the control plane device.

14. The method according to claim 12, characterized in that The acquiring monitoring information of the service based on the monitoring configuration includes: receiving a first message; Detecting whether the first message carries the identifier of the service; In a case where the first message carries the identifier of the service, monitoring configuration of the service is triggered based on the identifier of the service, and monitoring information of the service is obtained.

15. A communication device, characterized in that: include: memory and processor; Memory and processor coupling; The memory is used to store instructions executable by the processor; When the processor executes the instructions, the end-to-end monitoring method according to any one of claims 1 to 14 is performed.

16. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer instructions, and when the computer instructions are executed on an electronic device, the electronic device executes the end-to-end monitoring method according to any one of claims 1 to 14.

Images