Microservice memory leak monitoring method, system and apparatus, and storage medium

Abstract

Disclosed in the present invention are a microservice memory leak monitoring method, system and apparatus, and a storage medium. The method comprises: starting a memory leak monitoring program of a microservice, and loading a first tracepoint probe and a second tracepoint probe, the first tracepoint probe and the second tracepoint probe being set by means of an eBPF program; processing the first tracepoint probe and the second tracepoint probe by means of a map mechanism, so as to obtain an event list, the event list being used for storing process IDs, and memory allocation and memory release events; according to a first process ID of a microservice to be monitored, retrieving from the event list growth data of released memory corresponding to the first process ID; and acquiring memory growth data of said microservice, and, according to a difference value between the memory growth data and the growth data of released memory, determining whether there is a memory leak in said microservice. The embodiments of the present application helps to improve the resource utilization rate of clusters and improve the safety performance of systems, and can be widely applied to the technical field of cloud computing.

Description

Microservice memory leak monitoring method, system, device and storage medium Technical Field

[0001] The present invention relates to the field of cloud computing technology, and in particular to a method, system, device and storage medium for monitoring memory leaks of microservices. Background Art

[0002] Thousands of microservices can run in a Kubernetes environment, making microservice performance monitoring crucial. Kubernetes can limit microservice memory usage based on usage, improving cluster security. However, as microservice memory usage becomes more complex and ambiguous, operations personnel can face challenges. For example, when a microservice experiences a memory leak, it manifests as the microservice's memory usage reaching its upper limit. Monitoring graphs can make it difficult for operations personnel to determine whether the cause is an increase in business memory usage or a memory leak. The conventional approach in related technologies is to increase the upper limit on microservice memory usage. This increases cluster resource usage, leading operations personnel to overlook the security implications of microservice memory leaks. Once a memory leak occurs, it directly impacts service stability.

[0003] Summary of the Invention

[0004] The purpose of the present invention is to solve one of the technical problems existing in the prior art to at least a certain extent.

[0005] To this end, the object of the present invention is to provide a stable and efficient microservice memory leak monitoring method, system, device and storage medium.

[0006] In order to achieve the above technical objectives, the technical solutions adopted by the embodiments of the present invention include:

[0007] In one aspect, an embodiment of the present invention provides a method for monitoring memory leaks in a microservice, comprising the following steps:

[0008] The memory leak monitoring method of a microservice according to an embodiment of the present invention includes: starting a memory leak monitoring program of a microservice, loading a first tracking point probe and a second tracking point probe; the first tracking point probe and the second tracking point probe are used to jointly detect process-level memory allocation and memory release events; the first tracking point probe and the second tracking point probe are set through an eBPF program; the first tracking point probe and the second tracking point probe are processed through a map mechanism to obtain an event list; the event list is used to store process numbers, memory allocation and memory release events; according to the first process number of the microservice to be tested, the released memory growth data corresponding to the first process number is retrieved from the event list; the memory growth data of the microservice to be tested is obtained, and according to the difference between the memory growth data and the released memory growth data, it is determined whether the microservice to be tested has a memory leak. The embodiment of the present application records process-level memory release events through the first tracking point probe and the second tracking point probe to improve the accuracy of the data; leak monitoring of microservices is performed through the released memory growth data, and memory leak events of microservices are discovered in a timely manner, thereby improving security performance and improving resource utilization. Therefore, the embodiment of the present application is conducive to improving the resource utilization rate of the cluster and improving the security performance of the system.

[0009] In addition, the memory leak monitoring method for microservices according to the above embodiment of the present invention may also have the following additional technical features:

[0010] Furthermore, the memory leak monitoring method for microservices in an embodiment of the present invention further includes:

[0011] If the microservice to be tested has a memory leak, predict the memory usage of the microservice to be tested after a first preset time period using a linear regression algorithm;

[0012] If the amount of memory is greater than a first threshold, a serious alarm message is issued;

[0013] Alternatively, if the memory amount is less than or equal to the first threshold, a general alarm message is issued; the alarm urgency of the severe alarm message is greater than the alarm urgency of the general alarm message.

[0014] Furthermore, in one embodiment of the present invention, the method further includes:

[0015] Get the accumulated duration;

[0016] If the accumulated duration is equal to the second preset duration, the process returns to the step of retrieving the memory growth data corresponding to the first process number of the microservice to be tested from the event list, and clears the accumulated duration; the accumulated duration is used to represent the time since the last retrieval of the memory growth data.

[0017] Furthermore, in one embodiment of the present invention, the method further comprises the following steps:

[0018] Building a memory leak architecture for microservices; the architecture includes a kernel layer and an object layer;

[0019] The kernel layer is used to set the first tracking point probe and the second tracking point probe according to the eBPF program to establish an event list;

[0020] The object layer is used to retrieve, from the event list, the released memory growth data corresponding to the first process number of the microservice to be tested through the client-go library; and perform memory leak monitoring on the microservice to be tested based on the released memory growth data.

[0021] Furthermore, in one embodiment of the present invention, the method further includes:

[0022] Get the user-defined output port and expose it through the prometheus library;

[0023] The serious alarm information or the general alarm information is reported to the server through the output port.

[0024] Furthermore, in one embodiment of the present invention, the method further includes:

[0025] The kernel layer is further used to compile the BPF bytecode corresponding to the memory leak monitoring program and run the memory leak monitoring program in the kernel.

[0026] Furthermore, in one embodiment of the present invention, the method further includes:

[0027] Get the memory usage of the microservice under test;

[0028] If the memory usage is greater than the memory usage threshold, a memory leak monitoring program of the microservice is triggered.

[0029] On the other hand, an embodiment of the present invention provides a memory leak monitoring system for microservices, including:

[0030] The first module is used to start the memory leak monitoring program of the microservice and load the first tracking point probe and the second tracking point probe; the first tracking point probe and the second tracking point probe are used to jointly detect process-level memory allocation and memory release events; the first tracking point probe and the second tracking point probe are set through the eBPF program;

[0031] The second module is used to process the first tracking point probe and the second tracking point probe through a map mechanism to obtain an event list; the event list is used to store process IDs, memory allocation and memory release events;

[0032] The third module is used to retrieve the released memory growth data corresponding to the first process number of the microservice to be tested from the event list according to the first process number of the microservice to be tested;

[0033] The fourth module is used to obtain memory growth data of the microservice to be tested, and determine whether there is a memory leak in the microservice to be tested based on the difference between the memory growth data and the released memory growth data.

[0034] On the other hand, an embodiment of the present invention provides a memory leak monitoring device for a microservice, comprising:

[0035] at least one processor;

[0036] at least one memory for storing at least one program;

[0037] When the at least one program is executed by the at least one processor, the at least one processor implements the above-mentioned microservice memory leak monitoring method.

[0038] On the other hand, an embodiment of the present invention provides a storage medium storing a program executable by a processor. When the program is executed by the processor, it is used to implement the above-mentioned microservice memory leak monitoring method.

[0039] The memory leak monitoring method for microservices provided by an embodiment of the present invention includes the following steps: starting a memory leak monitoring program for a microservice, loading a first tracking point probe and a second tracking point probe; the first tracking point probe and the second tracking point probe are used to jointly detect process-level memory allocation and memory release events; the first tracking point probe and the second tracking point probe are set through an eBPF program; the first tracking point probe and the second tracking point probe are processed through a map mechanism to obtain an event list; the event list is used to store process numbers, memory allocation and memory release events; according to the first process number of the microservice to be tested, the released memory growth data corresponding to the first process number is retrieved from the event list; the memory growth data of the microservice to be tested is obtained, and based on the difference between the memory growth data and the released memory growth data, it is determined whether the microservice to be tested has a memory leak. The embodiment of the present application records process-level memory release events through the first tracking point probe and the second tracking point probe, thereby improving the accuracy of the data; leak monitoring of microservices is performed through the released memory growth data, and memory leak events of microservices are discovered in a timely manner, thereby improving security performance and improving resource utilization. Therefore, the embodiment of the present application is conducive to improving the resource utilization of the cluster and improving the security performance of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following introduction is made to the drawings of the embodiments of the present invention or the related technical solutions in the prior art. It should be understood that the drawings introduced below are only for the convenience of clearly describing some embodiments of the technical solutions of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without any creative work.

[0041] FIG1 is a flow chart of an embodiment of a method for monitoring memory leaks in microservices provided by the present invention;

[0042] FIG2 is a flow chart of another embodiment of a method for monitoring memory leaks in microservices provided by the present invention;

[0043] FIG3 is a flow chart of an embodiment of a memory leak warning processing process provided by the present invention;

[0044] FIG4 is a flow chart of an embodiment of a process for periodically processing a memory leak provided by the present invention;

[0045] FIG5 is a schematic diagram of the structure of an embodiment of a memory leakage architecture of a microservice provided by the present invention;

[0046] FIG6 is a flow chart of an embodiment of a process for reporting memory leak warning information provided by the present invention;

[0047] FIG7 is a flow chart of an embodiment of triggering memory leak monitoring provided by the present invention;

[0048] FIG8 is a schematic structural diagram of an embodiment of a memory leak monitoring system for microservices provided by the present invention;

[0049] FIG9 is a schematic structural diagram of an embodiment of a memory leak monitoring device for microservices provided by the present invention;

[0050] FIG10 is a schematic structural diagram of another embodiment of a memory leak monitoring device for microservices provided by the present invention. DETAILED DESCRIPTION

[0051] The embodiments of the present invention are described in detail below, examples of which are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention and are not to be construed as limiting the present invention. The step numbers in the following embodiments are provided for ease of explanation only and do not limit the order of the steps. The order of execution of the steps in the embodiments can be adaptively adjusted according to the understanding of those skilled in the art.

[0052] First, the terms involved in the embodiments of this application are explained:

[0053] EBPF (extended BPF) is an extension of BPF (Berkeley Packet Filter) technology, which can implement kernel tracing, application performance tuning / monitoring, flow control, etc. EBPF introduces a map mechanism. The BPF program puts the data obtained by kernel tracing into the map space. The map space is shared by user space and kernel space. User space programs can obtain kernel tracing data from the map.

[0054] gobpf library: For the Kubernetes cloud environment, gobpf provides a set of Go language APIs for interacting with eBPF, including loading and running eBPF programs, reading and writing memory, and other operations. The eBPF program implemented using the gobpf library obtains kernel memory allocation and release data tables.

[0055] client-go: It is a Go client library provided by Kubernetes (i.e. k8s) for interacting with the Kubernetes API. It uses client-go to obtain memory data and poll to check whether the process ID (i.e. pid) of the k8s microservice exists in the data table of memory leaks.

[0056] Currently, there are several solutions for memory monitoring in Kubernetes environments: 1. Monitoring node memory using the node-exporter component; 2. Monitoring microservice memory using cAdvisor and the Metrics Server component. These memory monitoring solutions utilize mature monitoring components, but neither approach can detect memory leaks at the process level, or at the microservice (pod) level. Furthermore, neither approach can provide preemptive memory leak detection or prioritized alerts.

[0057] It is understandable that thousands of microservices can be run in the K8s environment, and the performance monitoring of microservices becomes particularly important. K8s can limit the memory usage of microservices, improving the overall cluster security, but the memory performance usage of microservices becomes more complex and vague. When a microservice has a memory leak, it is manifested as the memory usage of the microservice reaches the upper limit. It is difficult for operation and maintenance personnel to distinguish from the monitoring graph whether it is caused by increased business memory usage or memory leaks. The general way to deal with it is to increase the memory usage upper limit of the microservice, which will cause a situation where the resource usage of the cluster becomes higher, and the operation and maintenance personnel ignore the security issues of memory leaks in the microservice. At the same time, it is impossible to provide advance warnings for memory leaks. Once a memory leak occurs, it directly affects the stability of the service. In this regard, the present application proposes a memory leak monitoring method for microservices, which can realize advance monitoring and graded warnings of memory leaks at the microservice level, inform the operation and maintenance personnel in advance before the memory leak occurs, improve the resource utilization efficiency of the cluster, and alleviate the security issues of microservices.

[0058] The following describes in detail a method and system for monitoring memory leaks of microservices according to an embodiment of the present invention with reference to the accompanying drawings. First, a method for monitoring memory leaks of microservices according to an embodiment of the present invention will be described with reference to the accompanying drawings.

[0059] 1 , a memory leak monitoring method for a microservice is provided in an embodiment of the present invention. The memory leak monitoring method for a microservice in the embodiment of the present invention can be applied to a terminal, a server, or software running in a terminal or a server. The terminal can be a tablet computer, a laptop computer, a desktop computer, etc., but is not limited thereto. The server can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The memory leak monitoring method for a microservice in the embodiment of the present invention mainly includes the following steps:

[0060] S100: Start the memory leak monitoring program of the microservice and load the first tracking point probe and the second tracking point probe; the first tracking point probe and the second tracking point probe are used to jointly detect process-level memory allocation and memory release events; the first tracking point probe and the second tracking point probe are set through the eBPF program;

[0061] S200: Process the first tracking point probe and the second tracking point probe through a map mechanism to obtain an event list; the event list is used to store process IDs, memory allocation and memory release events;

[0062] S300: According to the first process number of the microservice to be tested, the released memory growth data corresponding to the first process number is retrieved from the event list;

[0063] S400: Obtain memory growth data of the microservice to be tested, and determine whether the microservice to be tested has a memory leak based on the difference between the memory growth data and the released memory growth data.

[0064] In some possible implementations, referring to Figure 2, embodiments of the present application can be configured to enable a memory leak monitoring program for a microservice when Kubernetes detects that the memory usage of a microservice reaches a set threshold. It is understood that the probability of a memory leak is higher when the resource usage of a microservice is high. Therefore, embodiments of the present application can set an appropriate threshold based on actual needs. For example, the memory leak monitoring program can be triggered when the memory usage of a microservice exceeds 70%. After enabling the memory leak monitoring program for a microservice, embodiments of the present application set two tracepoint probes through the eBPF program to detect process-level memory allocation and memory release events, facilitating subsequent memory leak monitoring of the microservice based on memory release events. For example, the github.com / iovisor / gobpf package can be used to load and run the eBPF program. The eBPF program defines two tracepoint probes: bpf.AttachTracepoint(pageAllocProbe, "mm_page_alloc") and bpf.AttachTracepoint(pageFreeProbe, "mm_page_free"), for monitoring memory allocation and release events. Specifically, the embodiment of the present application loads the eBPF program by using a function, and uses m.LoadTracepoint() to load two trace points respectively.

[0065] This embodiment of the present application processes the first and second tracepoint probes through a mapping mechanism to obtain an event list for subsequent microservice data monitoring. Specifically, this embodiment of the present application processes the two tracepoint probes bpf.AttachTracepoint(pageAllocProbe, "mm_page_alloc") and bpf.AttachTracepoint(pageFreeProbe, "mm_page_free") through a mapping mechanism to store the process ID, memory allocation, and memory release events.

[0066] It can be understood that, through the above processing, an event list (i.e., map data) is established at the bottom layer for data storage. Then, the embodiment of the present application returns to the user space, obtains the first process number (i.e., process id) of the local machine microservice through client-go, retrieves the map data through the microservice process id, thereby obtaining the memory growth data released in the microservice, and then obtains the memory growth data of the entire microservice from prometheus. By comparing the two, if there is an error in the data growth of the two, it is determined whether there is a memory leak.

[0067] The embodiment of the present application uses eBPF technology to more efficiently obtain process-level memory allocation and release data, making memory data more real and reliable, reducing false alarms of memory leaks, and making monitoring data more trustworthy. The embodiment of the present application utilizes mature k8s secondary development technology, interacts with k8s through client-go, and customizes exporter to report microservice memory monitoring data to prometheus. It is applicable to the k8s environment and runs stably. The embodiment of the present application performs a secondary check of the unreleased kernel and the overall memory, and monitors memory leaks at the microservice level in advance to achieve hierarchical alarms.

[0068] In some possible embodiments, the embodiments of the present application perform pre-emptive intervention on memory leaks of k8s microservices (pod services), using eBPF technology and the go language library gobpf, client-go, and prometheus. When the memory usage of a microservice exceeds 70%, monitoring is triggered, and a kernel tracking function is created when the microservice process applies for and releases memory. The unreleased memory address and memory size are recorded in hours, and the memory usage of the process is monitored. At the same time, the overall memory size change of the microservice is obtained in hours. When the error between the unreleased memory growth and the microservice memory growth is less than 30%, it is determined to be a memory leak, thereby discovering the memory leak. The memory growth value for the next day is calculated by a linear regression calculation method. A general warning alarm is triggered if it is lower than 80%, and a serious alarm is triggered if it exceeds 80%. The monitoring data is reported to prometheus, ultimately achieving pre-emptive monitoring of memory leaks of microservices on the k8s cluster.

[0069] Therefore, the memory leak monitoring method of the microservice of the embodiment of the present invention includes: starting the memory leak monitoring program of the microservice, loading the first tracking point probe and the second tracking point probe; the first tracking point probe and the second tracking point probe are used to jointly detect process-level memory allocation and memory release events; the first tracking point probe and the second tracking point probe are set through the eBPF program; the first tracking point probe and the second tracking point probe are processed through the map mechanism to obtain an event list; the event list is used to store process numbers, memory allocation and memory release events; according to the first process number of the microservice to be tested, the released memory growth data corresponding to the first process number is retrieved from the event list; the memory growth data of the microservice to be tested is obtained, and according to the difference between the memory growth data and the released memory growth data, it is determined whether the microservice to be tested has a memory leak. The embodiment of the present application records process-level memory release events through the first tracking point probe and the second tracking point probe to improve the accuracy of the data; the microservice is leaked by monitoring the released memory growth data, and the memory leak events of the microservice are discovered in time, thereby improving the security performance and improving the resource utilization rate. Therefore, the embodiment of the present application is conducive to improving the resource utilization rate of the cluster and improving the security performance of the system.

[0070] Optionally, as shown in FIG3 , in one embodiment of the present invention, the memory leak monitoring method of the microservice further includes:

[0071] S500: If the microservice under test has a memory leak, predict the memory usage of the microservice under test after a first preset time period using a linear regression algorithm;

[0072] S600: If the memory amount is greater than the first threshold, a serious alarm message is issued;

[0073] S700: Alternatively, if the amount of memory is less than or equal to the first threshold, a general alarm message is issued; the alarm urgency of the severe alarm message is greater than the alarm urgency of the general alarm message.

[0074] The embodiments of the present application will further process the microservices that are determined to have memory leaks. Specifically, through a linear regression algorithm, the memory amount of the microservice to be tested is predicted after the first preset time period; if the memory amount is greater than the first threshold, a serious alarm message is issued; or, if the memory amount is less than or equal to the first threshold, a general alarm message is issued. Of course, the setting of the first threshold can be changed according to actual product requirements, customer requirements, etc., and the embodiments of the present application do not limit the specific value of the first threshold. Similarly, the embodiments of the present application do not limit the specific value of the first preset time period. For example, in some embodiments, the embodiments of the present application use a linear regression algorithm to perform linear regression on the memory value of the microservice 24 hours later. If the memory value will be higher than 80% in the next day, a serious alarm is triggered and emergency processing is required. If it is less than 80%, a general alarm is triggered and the operation and maintenance personnel are notified to handle it within 24 hours.

[0075] As shown in Table 1, the embodiment of the present application can measure the amount of memory change within each time period and perform a linear regression prediction on the memory amount based on time, predicting the memory growth value after the first preset time period. Based on this memory growth value, it is determined whether an alarm is required. The embodiment of the present application uses a linear regression algorithm to predict memory growth values, which can achieve early prediction and alarm, providing operation and maintenance personnel with pre-processing time to prepare and improve the safety performance of the system.

[0076] Table 1

[0077] It can be known that the embodiment of the present application verifies the unrecovered memory growth obtained by ebpf with the microservice memory growth, sets an error value, and determines that a memory leak is present if the value is lower than the error value; uses a linear regression algorithm, which is suitable for two-dimensional data. It has high operating efficiency and good accuracy for data sets with positively correlated growth, can predict the memory value one day later, and perform graded alarms; k8s provides a custom exporter implementation method, which implements a custom exporter through the prometheus library, and can report kernel abnormal memory monitoring data to trigger an alarm.

[0078] Optionally, referring to FIG4 , in one embodiment of the present invention, the memory leak monitoring method of the microservice further includes:

[0079] S310: Obtaining cumulative duration;

[0080] S320: If the accumulated duration is equal to the second preset duration, the process returns to the step of retrieving the memory growth data corresponding to the first process number of the microservice under test from the event list, and clears the accumulated duration. The memory growth data is the memory growth data of the microservice under test within the second preset duration. The accumulated duration is used to represent the time since the last retrieval of the memory growth data.

[0081] In some possible implementations, the embodiment of the present application implements periodic memory leak monitoring of the microservice to be tested based on the cumulative duration by setting a second preset duration. It is understandable that the released memory growth data is the released memory growth data of the microservice to be tested in the current cumulative round. The second preset duration can be set according to actual needs, and the embodiment of the present application does not limit the specific value of the second preset duration. The embodiment of the present application changes the memory leak monitoring period of the microservice by setting the second preset duration, thereby improving the versatility of leakage monitoring.

[0082] Optionally, referring to FIG5 , in one embodiment of the present invention, the memory leak monitoring method of the microservice further includes:

[0083] Build a memory leak architecture for microservices; the architecture includes a kernel 510 and an object layer 520;

[0084] The kernel layer is used to set the first tracking point probe and the second tracking point probe according to the eBPF program and establish an event list;

[0085] The object layer is used to retrieve the released memory growth data corresponding to the first process number of the microservice to be tested from the event list through the client-go library; and perform memory leak monitoring on the microservice to be tested based on the released memory growth data.

[0086] In some possible implementations, the above-mentioned memory leak monitoring method is implemented through the memory leak architecture of microservices. Specifically, the embodiment of the present application verifies the unrecovered memory growth obtained by eBPF with the microservice memory growth, sets an error value, and determines that a memory leak occurs if the error value is lower than the error value; uses a linear regression algorithm, which is suitable for two-dimensional data. For data sets with positively correlated growth, it has high operating efficiency and good accuracy, can predict the memory value one day later, and perform graded alarms; k8s provides a custom exporter implementation method, which is implemented through the prometheus library to report kernel abnormal memory monitoring data to trigger alarms.

[0087] Optionally, referring to FIG6 , in one embodiment of the present invention, the memory leak monitoring method of the microservice further includes:

[0088] S510: Get the user-defined output port and expose the output port through the prometheus library;

[0089] S520: Report the serious alarm information or the general alarm information to the server through the output port.

[0090] In some embodiments, the present application embodiment can expose a custom output port (i.e., the exporter port) through the prometheus library, report the obtained microservice leakage judgment and alarm classification to the prometheus-server server, trigger pre-monitoring alarms, and notify operations and maintenance personnel. The present application embodiment is implemented through a custom exporter, which supplements the exporter's ability to monitor microservice memory leaks.

[0091] Optionally, in one embodiment of the present invention, the memory leak monitoring method of the microservice further includes:

[0092] The kernel layer is also used to compile the BPF bytecode corresponding to the memory leak monitoring program and run the memory leak monitoring program in the kernel.

[0093] In some possible implementations, the present application embodiment enters kernel space, and the eBPF program compiles BPF bytecode using the clang / llvm compiler and runs in the kernel. The present application embodiment uses eBPF technology to more efficiently obtain process-level memory allocation and release data, making memory data more accurate and reliable, reducing false memory leak alerts, and providing more reliable monitoring data.

[0094] Optionally, referring to FIG7 , in one embodiment of the present invention, the memory leak monitoring method of the microservice further includes:

[0095] S110: Get the memory usage of the microservice under test;

[0096] S120: If the memory usage is greater than the memory usage threshold, trigger the memory leak monitoring program of the microservice.

[0097] In some possible implementations, the embodiments of the present application detect the memory usage of the microservice to be tested. When the usage is greater than the memory usage threshold, the memory leak monitoring program of the microservice is triggered. The microservice is monitored for leaks using the above-mentioned memory leak monitoring method to improve the security performance of the system.

[0098] In some possible embodiments, this application implements a custom exporter for monitoring microservice memory leaks, which is then deployed to a Kubernetes cluster via a daemonset, ensuring that each node has an exporter. Prometheus is then configured to discover the custom exporter's port and retrieve the reported monitoring data. This embodiment configures monitoring data alert rules and memory leak thresholds; it sends alerts to microservices identified as leaking and their corresponding alert levels. This embodiment also allows for the drawing of Grafana monitoring charts to visualize microservice memory allocation and release.

[0099] A memory leak monitoring method for a microservice according to an embodiment of the present invention includes: starting a memory leak monitoring program for the microservice and loading a first tracing point probe and a second tracing point probe; the first tracing point probe and the second tracing point probe are used to jointly detect process-level memory allocation and memory release events; the first tracing point probe and the second tracing point probe are set via an eBPF program; the first tracing point probe and the second tracing point probe are processed via a map mechanism to obtain an event list; the event list is used to store process numbers, memory allocation, and memory release events; based on the first process number of the microservice to be tested, released memory growth data corresponding to the first process number is retrieved from the event list; the memory growth data of the microservice to be tested is obtained, and based on the difference between the memory growth data and the released memory growth data, whether the microservice to be tested has a memory leak is determined. Specifically, the embodiment of the present application uses gobpf to implement the ebpf program to monitor the memory allocation and release of microservices; uses client-go to implement the interaction between the microservice process id and the ebpf program map data; obtains the unreleased memory growth and the overall microservice memory growth through ebpf for secondary verification to improve the accuracy of the alarm; predicts the memory leakage value through linear regression and hierarchical alarm processing logic; and implements the reporting of microservice memory monitoring data through a custom exporter. The embodiment of the present application records process-level memory release events through the first tracking point probe and the second tracking point probe to improve the accuracy of the data; monitors the microservice for leaks by releasing memory growth data, promptly discovers memory leakage events of microservices, improves security performance, and improves resource utilization. Therefore, the embodiment of the present application is conducive to improving the resource utilization rate of the cluster and improving the security performance of the system.

[0100] Next, a memory leak monitoring system for microservices proposed according to an embodiment of the present invention will be described with reference to FIG8 .

[0101] FIG8 is a schematic diagram of the structure of a microservice memory leak monitoring system according to an embodiment of the present invention. The system specifically includes:

[0102] The first module 810 is used to start the memory leak monitoring program of the microservice and load the first tracking point probe and the second tracking point probe; the first tracking point probe and the second tracking point probe are used to jointly detect process-level memory allocation and memory release events; the first tracking point probe and the second tracking point probe are set through the eBPF program;

[0103] The second module 820 is used to process the first tracking point probe and the second tracking point probe through a map mechanism to obtain an event list; the event list is used to store process IDs, memory allocation and memory release events;

[0104] The third module 830 is configured to retrieve, from the event list, the released memory growth data corresponding to the first process number of the microservice to be tested;

[0105] The fourth module 840 is configured to obtain memory growth data of the microservice to be tested, and determine whether the microservice to be tested has a memory leak based on a difference between the memory growth data and the released memory growth data.

[0106] Optionally, in one embodiment of the present invention, the system further includes a fifth module, configured to predict the memory usage of the microservice to be tested after a first preset time period by using a linear regression algorithm if a memory leak exists in the microservice to be tested;

[0107] If the amount of memory is greater than the first threshold, a serious alarm message is issued;

[0108] Alternatively, if the amount of memory is less than or equal to the first threshold, a general alarm message is issued; the alarm urgency of the severe alarm message is greater than the alarm urgency of the general alarm message.

[0109] Optionally, in one embodiment of the present invention, the system further includes a sixth module for obtaining cumulative duration;

[0110] If the accumulated duration is equal to the second preset duration, return to the third module; clear the accumulated duration; release memory growth data is the released memory growth data of the microservice under test within the second preset duration; the accumulated duration is used to represent the time since the last retrieval of the released memory growth data.

[0111] Optionally, in one embodiment of the present invention, the system further includes a seventh module for constructing a memory leak architecture for microservices; the architecture includes a kernel layer and an object layer;

[0112] The kernel layer is used to set the first tracking point probe and the second tracking point probe according to the eBPF program and establish an event list;

[0113] The object layer is used to retrieve the released memory growth data corresponding to the first process number of the microservice to be tested from the event list through the client-go library; and perform memory leak monitoring on the microservice to be tested based on the released memory growth data.

[0114] Optionally, in one embodiment of the present invention, the fifth module of the system is further used to obtain a user-defined output port and expose the output port through the prometheus library;

[0115] Report serious alarm information or general alarm information to the server through the output port.

[0116] Optionally, in one embodiment of the present invention, the kernel layer in the seventh module is further used to compile BPF bytecode corresponding to the memory leak monitoring program and run the memory leak monitoring program in the kernel.

[0117] Optionally, in one embodiment of the present invention, the system further includes an eighth module, configured to obtain the memory usage of the microservice to be tested;

[0118] If the memory usage exceeds the memory usage threshold, the memory leak monitoring program of the microservice is triggered.

[0119] It can be seen that the contents of the above method embodiments are all applicable to the present system embodiments. The functions specifically implemented by the present system embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0120] An embodiment of the present invention provides a memory leak monitoring device for a microservice, comprising:

[0121] at least one processor;

[0122] at least one memory for storing at least one program;

[0123] When the at least one program is executed by the at least one processor, the at least one processor implements the memory leak monitoring method for microservices.

[0124] Similarly, the contents of the above method embodiments are applicable to the present device embodiments. The functions specifically implemented by the present device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0125] The memory leak monitoring device for a microservice provided in an embodiment of the present application for executing the memory leak monitoring method for the above-mentioned microservice may be a terminal. Referring to FIG9 , FIG9 is a partial structural block diagram of the terminal provided in an embodiment of the present application, and the terminal includes components such as a radio frequency (RF) circuit 1010, a memory 1020, an input unit 1030, a display unit 1040, a sensor 1050, an audio circuit 1060, a wireless fidelity (WiFi) module 1070, a processor 1080, and a power supply 1090. It will be understood by those skilled in the art that the terminal structure shown in FIG9 does not limit the mobile phone and may include more or fewer components than shown, or combine certain components, or arrange the components differently.

[0126] The RF circuit can be used to receive and send signals during information transmission or calls. In particular, it receives downlink information from the base station and sends it to the processor for processing; in addition, it sends the designed uplink data to the base station.

[0127] The memory can be used to store software programs and modules. The processor executes various functional applications and data processing of the mobile phone by running the software programs and modules stored in the memory.

[0128] The input unit can be used to receive input digital or character information and generate key signal input related to the settings and function control of the mobile phone. Specifically, the input unit can include a touch panel 1031 and other input devices 1032.

[0129] The display unit 1040 may include a display panel 1041 .

[0130] The audio circuit 1060 , the speaker 1061 , and the microphone 1062 may provide an audio interface.

[0131] In this embodiment, the processor included in the terminal can execute the memory leak monitoring method for microservices in the previous embodiment.

[0132] The memory leak monitoring device for a microservice provided in an embodiment of the present application for executing the memory leak monitoring method for the above-mentioned microservice can also be a server. Referring to Figure 10, Figure 10 is a partial structural block diagram of a server provided in an embodiment of the present application. The server 1100 may have relatively large differences due to different configurations or performances, and may include one or more central processing units (CPUs for short), 1122 (for example, one or more processors) and memory 1132, one or more storage media 1130 (for example, one or more mass storage devices) for storing application programs 1142 or data 1144. Among them, the memory 1132 and the storage medium 1130 can be temporary storage or permanent storage. The program stored in the storage medium 1130 may include one or more modules (not shown in the figure), each module may include a series of instruction operations on the server 1100. Furthermore, the central processing unit 1122 can be configured to communicate with the storage medium 1130 to execute a series of instruction operations in the storage medium 1130 on the server 1100.

[0133] The server may also include one or more power supplies 1126, one or more wired or wireless network interfaces 1150, one or more input and output interfaces 1158, and / or one or more operating systems 1141, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0134] The processor in the server can be used to execute the memory leak detection method of the above microservice.

[0135] Similarly, the contents of the above method embodiments are applicable to the present device embodiments. The functions specifically implemented by the present device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0136] An embodiment of the present invention further provides a computer-readable storage medium storing a program executable by a processor. When the program is executed by the processor, it is used to execute the above-mentioned microservice memory leak monitoring method.

[0137] Similarly, the contents of the above method embodiments are applicable to the present storage medium embodiment. The functions specifically implemented by the present storage medium embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0138] In some optional embodiments, the function / operation mentioned in the block diagram may not occur in the order mentioned in the operation diagram. For example, depending on the function / operation involved, the two boxes shown in succession can actually be executed substantially simultaneously or the boxes can sometimes be executed in reverse order. In addition, the embodiment presented and described in the flow chart of the present invention is provided in an exemplary manner for the purpose of providing a more comprehensive understanding of the technology. The disclosed method is not limited to the operation and logic flow presented herein. Optional embodiments are contemplated in which the order of the various operations is changed and the sub-operations described as a part of a larger operation are performed independently.

[0139] Furthermore, while the present invention has been described in the context of functional modules, it should be understood that, unless otherwise indicated, one or more of the functions and / or features may be integrated into a single physical device and / or software module, or one or more functions and / or features may be implemented in separate physical devices or software modules. It should also be understood that a detailed discussion of the actual implementation of each module is unnecessary for understanding the present invention. Rather, given the properties, functions, and internal relationships of the various functional modules in the devices disclosed herein, the actual implementation of such modules will be understood within the ordinary skill of an engineer. Therefore, a person skilled in the art, using ordinary skill, will be able to implement the present invention set forth in the claims without undue experimentation. It should also be understood that the specific concepts disclosed are merely illustrative and are not intended to limit the scope of the present invention, which is determined by the full scope of the appended claims and their equivalents.

[0140] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several programs for enabling a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0141] The logic and / or steps represented in a flowchart or otherwise described herein, for example, may be considered as an ordered list of executable programs for implementing the logical functions, and may be embodied in any computer-readable medium for use by, or in conjunction with, a program execution system, apparatus, or device (e.g., a computer-based system, a system including a processor, or other system that can retrieve and execute a program from a program execution system, apparatus, or device). For purposes of this specification, a "computer-readable medium" may be any device that can contain, store, communicate, propagate, or transport a program for use by, or in conjunction with, a program execution system, apparatus, or device.

[0142] More specific examples (a non-exhaustive list) of computer-readable media include the following: an electrical connection with one or more wires (electronic devices), a portable computer disk cartridge (magnetic devices), a random access memory (RAM), a read-only memory (ROM), an erasable and programmable read-only memory (EPROM or flash memory), a fiber optic device, and a portable compact disc read-only memory (CDROM). In addition, the computer-readable medium may even be paper or other suitable medium on which the program is printed, since the program may be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, deciphering, or processing in another suitable manner as necessary, and then stored in a computer memory.

[0143] It should be understood that various parts of the present invention can be implemented using hardware, software, firmware, or a combination thereof. In the above-described embodiments, multiple steps or methods can be implemented using software or firmware stored in a memory and executed by a suitable program execution system. For example, if implemented using hardware, as in another embodiment, any one of the following technologies known in the art or a combination thereof can be used: a discrete logic circuit having a logic gate circuit for implementing a logic function on a data signal, an application-specific integrated circuit having a suitable combination of logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.

[0144] Throughout the foregoing description of this specification, reference to terms such as "one embodiment / example," "another embodiment / example," or "certain embodiments / examples" indicates that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the present invention. In this specification, schematic representations of these 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 any one or more embodiments or examples.

[0145] While embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions, and variations may be made to the embodiments without departing from the principles and spirit of the invention, and that the scope of the invention is defined by the claims and their equivalents.

[0146] The above is a specific description of the preferred implementation of the present invention, but the present invention is not limited to the embodiments. Those skilled in the art can make various equivalent modifications or substitutions without violating the spirit of the present invention. These equivalent modifications or substitutions are all included in the scope defined by the claims of the present invention.

Claims

1. A memory leak monitoring method for microservices, characterized in that: The following steps are involved: Start the memory leak monitoring program of the microservice and load the first and second tracking point probes; The first tracking point probe and the second tracking point probe are used to jointly detect process level memory allocation and memory release events; The first tracking point probe and the second tracking point probe are set by an eBPF program; Processing the first tracking point probe and the second tracking point probe through a map mechanism to obtain an event list; The event list is used to store process numbers, memory allocation and memory release events; According to the first process number of the microservice to be tested, retrieve the released memory growth data corresponding to the first process number from the event list; Memory growth data of the microservice to be tested is obtained, and according to a difference between the memory growth data and the released memory growth data, it is determined whether the microservice to be tested has a memory leak.

2. The memory leak monitoring method for microservices according to claim 1, characterized in that: The method further comprises: If the microservice to be tested has a memory leak, predict the memory capacity of the microservice to be tested after a first preset time period by using a linear regression algorithm; If the amount of memory is greater than a first threshold, a serious warning message is issued; Alternatively, if the amount of memory is less than or equal to the first threshold, a general alarm message is issued; the alarm urgency of the severe alarm message is greater than the alarm urgency of the general alarm message.

3. The memory leak monitoring method for microservices according to claim 1, characterized in that: The method further comprises: Get the accumulated duration; If the accumulated duration is equal to the second preset duration, the step of retrieving the memory growth data corresponding to the first process number of the microservice to be tested from the event list is returned, and the accumulated duration is cleared; the accumulated duration is used to represent the time since the last retrieval of the memory growth data.

4. The memory leak monitoring method for microservices according to claim 1, characterized in that: The method further comprises the following steps: Building a memory leak architecture for microservices; the architecture includes a kernel layer and an object layer; The kernel layer is used to set the first tracking point probe and the second tracking point probe according to the eBPF program to establish an event list; The object layer is used to retrieve the released memory growth data corresponding to the first process number of the microservice to be tested from the event list through the client-go library according to the first process number of the microservice to be tested; and perform memory leak monitoring on the microservice to be tested according to the released memory growth data.

5. The memory leak monitoring method for microservices according to claim 2, characterized in that: The method further comprises: Get the user-defined output port and expose the output port through the prometheus library; The serious alarm information or the general alarm information is reported to the server through the output port.

6. The memory leak monitoring method for microservices according to claim 4 is characterized in that: The kernel layer is also used to compile the BPF bytecode corresponding to the memory leak monitoring program and run the memory leak monitoring program in the kernel.

7. The microservice memory leak monitoring method according to claim 1, characterized in that: The method further comprises: Get the memory usage of the microservice under test; If the memory usage is greater than the memory usage threshold, a memory leak monitoring program of the microservice is triggered.

8. A memory leak monitoring system for microservices, characterized in that: include: The first module is used to start the memory leak monitoring program of the microservice and load the first tracking point probe and the second tracking point probe; The first tracking point probe and the second tracking point probe are used to jointly detect process level memory allocation and memory release events; The first tracking point probe and the second tracking point probe are set by an eBPF program; The second module is used to process the first tracking point probe and the second tracking point probe through a map mechanism to obtain an event list; The event list is used to store process numbers, memory allocation and memory release events; The third module is used to retrieve the released memory growth data corresponding to the first process number of the microservice to be tested from the event list according to the first process number of the first process number; The fourth module is used to obtain the memory growth data of the microservice to be tested, and determine whether the microservice to be tested has a memory leak according to the difference between the memory growth data and the released memory growth data.

9. A memory leak monitoring device for microservices, characterized in that: include: at least one processor; at least one memory for storing at least one program; When the at least one program is executed by the at least one processor, the at least one processor implements the memory leak monitoring method for microservices according to any one of claims 1 to 7.

10. A computer-readable storage medium storing a program executable by a processor, characterized in that: The processor-executable program is used to implement the memory leak monitoring method for a microservice as described in any one of claims 1 to 7 when executed by the processor.

Images