Container cluster monitoring acquisition method and device, computer equipment and readable storage medium

Abstract

The invention relates to a container cluster monitoring collection method and device, computer equipment and a readable storage medium. The method comprises the following steps: acquiring a to-be-monitored object of a container cluster; the to-be-monitored object comprises a container group Pod which completes monitoring label injection in a Pod creation process; determining a target Pod in the to-be-monitored object based on the monitoring tag; and generating a target object based on the target Pod, and collecting a monitoring index of the target object to obtain a monitoring collection result. According to the method and the device, the label is automatically injected into the Pod of the application or the component needing to be monitored, the application or the component does not need to be intervened in advance, so that a monitoring acquisition mode is more flexible, and non-invasiveness of application deployment is realized.

Description

Technical Field

[0001] The present application relates to the field of cloud computing technology, and in particular to a monitoring and collection method, apparatus, computer equipment, and readable storage medium for a container cluster. Background Art

[0002] As a container orchestration tool, Kubernetes is increasingly being used as the underlying computing framework of cloud platforms, with a large number of applications and components deployed in Kubernetes in the form of containers. However, traditional monitoring and collection methods for applications or components are not flexible enough, which can easily lead to frequent modifications to configuration files. Summary of the invention

[0003] Based on this, it is necessary to provide a monitoring and collection method, device, computer equipment and readable storage medium for a container cluster that can improve flexibility in response to the above technical problems.

[0004] In a first aspect, the present application provides a monitoring and collection method for a container cluster, including:

[0005] Get the objects to be monitored in the container cluster; the objects to be monitored include the container group Pods that have completed the injection of monitoring labels during the Pod creation process;

[0006] Based on the monitoring label, determine the target Pod among the objects to be monitored;

[0007] Generate a target object based on the target Pod, collect monitoring indicators of the target object, and obtain monitoring collection results.

[0008] In one of the embodiments, the monitoring indicators include JVM monitoring indicators and database monitoring indicators; the target objects include applications or components in the container cluster.

[0009] In one embodiment, obtaining the object to be monitored of the container cluster includes:

[0010] Use StatefulSet to deploy monitoring tools to the container cluster. The monitoring target of the monitoring tool is the container group Pod.

[0011] Obtain the object to be monitored through the monitoring tool.

[0012] In one of the embodiments, the monitoring tool includes a Prometheus tool; the service discovery mode of the Prometheus tool is configured as an automatic discovery mode based on K8s.

[0013] In one embodiment, determining a target Pod in an object to be monitored based on a monitoring tag includes:

[0014] Use the monitoring tool to filter the monitored objects according to the monitoring labels to obtain the target Pod.

[0015] In one embodiment, the method further comprises:

[0016] In response to receiving a Pod creation request, triggering a target callback function; the Pod creation request includes Pod metadata;

[0017] Execute the target callback function to intercept the Pod creation request, and insert the monitoring label into the Pod metadata if the monitoring label does not exist in the Pod metadata to obtain the target Pod metadata;

[0018] Create a container group Pod based on the target Pod metadata.

[0019] In one of the embodiments, the target callback function includes a webhook-based callback function.

[0020] In a second aspect, the present application also provides a monitoring and collection device for a container cluster, including:

[0021] The monitoring object acquisition module is used to obtain the objects to be monitored in the container cluster; the objects to be monitored include the container group Pods that have completed the monitoring label injection during the Pod creation process;

[0022] The target determination module is used to determine the target Pod among the monitored objects based on the monitoring labels;

[0023] The collection module is used to generate a target object based on the target Pod, collect monitoring indicators of the target object, and obtain monitoring collection results.

[0024] In a third aspect, the present application further provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, each step in the monitoring and collection method of the above-mentioned container cluster is implemented.

[0025] In a fourth aspect, the present application further provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, each step in the monitoring and collection method of the above-mentioned container cluster is implemented.

[0026] The monitoring and collection method, device, computer equipment and readable storage medium of the above-mentioned container cluster, when the object to be monitored of the container cluster is obtained, determines the target Pod in the object to be monitored based on the monitoring label, and then generates the target object based on the target Pod, collects the monitoring indicators of the target object, and obtains the monitoring and collection results, wherein the object to be monitored includes the container group Pod that completes the injection of monitoring labels during the Pod creation process, that is, the present application automatically injects labels into the Pod of the application or component that needs to be monitored, without the need to intervene in the application or component in advance, making the monitoring and collection method more flexible and realizing non-invasive application deployment. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the drawings required for use in the embodiments of the present application or related technical descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0028] Figure 1 The following is a flow chart of a monitoring and collection method for a container cluster in one embodiment;

[0029] Figure 2 A schematic diagram of a process for obtaining an object to be monitored in one embodiment;

[0030] Figure 3 A schematic diagram of a process for creating a container group Pod in one embodiment;

[0031] Figure 4 A schematic diagram of a process for creating a container group Pod in another embodiment;

[0032] Figure 5 A schematic diagram of a specific process of a monitoring and collection method for a container cluster in one embodiment;

[0033] Figure 6 A schematic diagram of the flow of interaction between services in an embodiment;

[0034] Figure 7 It is a structural block diagram of a monitoring and collection device of a container cluster in one embodiment;

[0035] Figure 8 is an internal structure diagram of a computer device in one embodiment;

[0036] Fig. 9 FIG. 4 is a diagram showing the internal structure of a computer device in another embodiment. DETAILED DESCRIPTION

[0037] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0038] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application.

[0039] It is understood that in this application, terms such as "first", "second", etc. are only used to distinguish similar objects, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of indicated technical features. It is understood that "at least one" means one or more, and "a plurality" means two or more.

[0040] When used herein, the singular forms "a", "an", and "said / the" may also include plural forms, unless the context clearly indicates otherwise. It should also be understood that the terms "include / comprise" or "have" and the like specify the presence of stated features, wholes, steps, operations, components, parts, or combinations thereof, but do not exclude the possibility of the presence or addition of one or more other features, wholes, steps, operations, components, parts, or combinations thereof. At the same time, the term "and / or" used in this specification includes any and all combinations of the relevant listed items.

[0041] In the scenario of a cloud platform with Kubernetes (K8s) as the underlying computing framework, the traditional Prometheus (an open source service monitoring system and time series database) collection mode based on static service configuration is not flexible enough. Every time a new application that needs to be monitored is deployed, a static configuration needs to be added, which will cause frequent modifications to the Prometheus configuration file.

[0042] Currently, Prometheus monitors and collects data from all Pods in Kubernetes. However, collecting data from all Pods will put too much pressure on Prometheus and cause a waste of resources. The traditional solution is to modify the yaml file before deploying the application, manually add a pre-agreed label to the yaml file, such as Prometheus-io-scrape=true, and then filter according to the label on the Prometheus side to filter out the Pods that need to be paid attention to from all Pods, and then monitor and collect data. However, the above traditional solution has at least the following problems: It is necessary to intervene in the application in advance, that is, before deploying different applications each time, it is necessary to manually modify the yaml file to add a label. When there are many applications that need to be monitored in a Kubernetes cluster, the workload of this early intervention is very large, resulting in a waste of manpower and time.

[0043] For example, traditional solutions achieve automatic classification and deployment of monitoring collectors by establishing an association between resources and collectors. However, the establishment of the relationship between resources and collectors depends on adding specific tags in the resource deployment script, which requires early intervention in the deployed resources and is highly invasive. If a large number of resources need to be deployed, then adding tags to the resource deployment script will waste a lot of manpower and time.

[0044] To address the above issues, this application proposes a monitoring method based on Kubernetes. By deploying Prometheus in a cloud-native way, configuring a service discovery mode based on k8s, and deploying a webhook service to automatically inject labels into applications or components that need to be monitored, an automatic discovery-based monitoring and collection solution is implemented without the need for prior intervention.

[0045] It should be noted that the beneficial effects brought about by the embodiments of the present application or the technical problems solved are not limited to this one, but may also include other implicit or related problems. For details, please refer to the description of the following embodiments.

[0046] The technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems are described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0047] The monitoring method provided in the embodiment of the present application can be applied to the monitoring field in cloud computing. Specifically, it can be applied to the scenario of collecting application or component monitoring indicators in Kubernetes; illustratively, it can also be applied to various cloud platforms using Kubernetes as the computing framework.

[0048] In an exemplary embodiment, Figure 1 As shown, a monitoring and collection method for a container cluster is provided. This embodiment uses the method applied to a terminal as an example. It can be understood that the method can also be applied to a server, and can also be applied to a system including a terminal and a server, and is implemented through the interaction between the terminal and the server. The following steps 102 to 106 are included. Among them:

[0049] Step 102, obtaining the objects to be monitored of the container cluster; the objects to be monitored include the container group Pods that have completed the injection of monitoring labels during the Pod creation process.

[0050] Among them, the container cluster can be a Kubernetes container cluster; the embodiment of the present application can obtain the objects to be monitored in the Kubernetes container cluster. For example, taking the application deployed in Kubernetes in the form of a container as an example, the objects to be monitored can include application Pods that need to be monitored, and can also include application Pods that do not need to be monitored. Optionally, the objects to be monitored can refer to all Pods in Kubernetes.

[0051] Specifically, for the objects to be monitored, the embodiments of the present application propose that the objects to be monitored include container group Pods that complete the injection of monitoring labels during the Pod creation process. It can be understood that the container group Pods that complete the injection of monitoring labels can refer to the Pods of the applications (or components) that need to be monitored, and the monitoring labels can refer to labels (such as preset labels, agreed labels). Exemplarily, the present application automatically injects monitoring labels into the Pods of the applications (or components) that need to be monitored by completing the injection of monitoring labels for the container group Pods during the Pod creation process, thereby eliminating the need to manually modify the yaml file of the application (or component) to add the label before the application (or component) is deployed, thereby achieving non-invasive application deployment.

[0052] Step 104: Determine the target Pod in the monitored object based on the monitoring label.

[0053] Specifically, the target Pod in the monitored object can be determined based on the monitoring label; illustratively, the target Pod can be a container group Pod carrying a monitoring label, such as a field in the Pod metadata that has a label. Optionally, the target Pod can be determined by checking the field or filtering based on the monitoring label.

[0054] It can be understood that the above-mentioned implementation method of determining the target Pod can also adopt other forms, and is not limited to the forms mentioned in the above embodiment, as long as it can achieve the function of determining the target Pod from the object to be monitored.

[0055] Step 106: Generate a target object based on the target Pod, collect monitoring indicators of the target object, and obtain monitoring collection results.

[0056] Specifically, the target object may refer to the collection target target. When the target Pod is determined, the corresponding target object may be generated based on the target Pod, and then its monitoring indicators may be collected to obtain the monitoring collection result. It can be understood that the monitoring collection result may include the monitoring indicators of the collection target target obtained through collection.

[0057] The monitoring and collection method for the above container cluster automatically injects monitoring tags into the Pods of the applications that need to be monitored, without the need to intervene in the applications (or components) in advance, thus achieving non-intrusive resource deployment, making the monitoring and collection method more flexible and reducing the risk of port exposure.

[0058] In an exemplary embodiment, the monitoring indicators may include JVM (Java Virtual Machine) monitoring indicators and database monitoring indicators; the target object may include an application or component in a container cluster.

[0059] Specifically, the monitoring indicators in the embodiments of the present application may include but are not limited to the monitoring indicators of the JVM, the monitoring indicators of various databases, etc. Further, when the target Pod is determined, a container for running the application (or component) can be generated on the target Pod; optionally, each Pod generates at least one container, and each container runs an application (or component). Among them, the application can be referred to as an application.

[0060] It can be understood that the above-mentioned implementation method of generating the target object based on the target Pod can also adopt other forms, and is not limited to the forms mentioned in the above embodiment, as long as it can achieve the function of completing the generation of the target object.

[0061] In an exemplary embodiment, Figure 2 As shown, step 102 includes steps 202 to 204. Among them:

[0062] Step 202: Use StatefulSet to deploy the monitoring tool to the container cluster; wherein the monitoring target of the monitoring tool is the container group Pod.

[0063] Specifically, before performing monitoring collection, you can use StatefulSet to deploy the monitoring tool to the container cluster, and then you can set the monitoring target of the monitoring tool to the container group Pod by modifying the configuration file.

[0064] Among them, using StatefulSet to deploy monitoring tools can be understood as deploying monitoring tools in the form of StatefulSet to achieve cloud-native deployment. The embodiment of the present application deploys monitoring tools in a cloud-native manner to achieve a service discovery mode for container group Pods, which is more flexible than the traditional static discovery mode and reduces the risk of port exposure.

[0065] Step 204: Acquire the object to be monitored through a monitoring tool.

[0066] Specifically, after the monitoring tool is deployed, the monitored object can be obtained through the monitoring tool. Taking the container cluster as a Kubernetes container cluster, the monitoring tool can discover all Pods in Kubernetes and perform monitoring collection, thereby realizing automatic discovery of monitoring collection objects.

[0067] In practical applications, the monitoring tool may adopt the Prometheus tool. In one embodiment, the monitoring tool includes the Prometheus tool; the service discovery mode of the Prometheus tool is configured as an automatic discovery mode based on K8s.

[0068] Specifically, the embodiment of the present application can deploy the Prometheus tool (referred to as Prometheus), modify the configuration file of Prometheus, set the service discovery mode to the automatic discovery mode based on Kubernetes kubernetes_sd_configs, and set the role to Pod. At the same time, a ServiceAccount with listpod permission can be specified for Prometheus, and then Prometheus can be deployed in the form of statefulsets, so that Prometheus can discover and collect monitoring indicators of all pods in the cluster.

[0069] Among them, the list pod permission can refer to the permission to obtain all pod information. Prometheus must have the list pod permission and set role=pod to take effect, otherwise it will report an error of insufficient permissions. It can be understood that taking the container cluster as a Kubernetes container cluster as an example, ServiceAccount can be a resource object in Kubernetes, which represents the identity of a process running in the cluster.

[0070] In the above, Prometheus is deployed in the cluster in a cloud-native way, and the service discovery mode based on k8s is configured, that is, the collection mode of Prometheus is set to kubernetes_sd_configs, and the role is set to Pod. Through the above configuration, Prometheus can automatically discover all Pods in Kubernetes and perform monitoring and collection, improving the flexibility of monitoring and collection. Among them, the cloud-native way is used to quickly deploy Prometheus, and the collection is configured as a service discovery mode based on Kubernetes, which is more flexible than the traditional static discovery mode and reduces the risk of port exposure.

[0071] In one embodiment, determining a target Pod in an object to be monitored based on a monitoring tag includes:

[0072] Use the monitoring tool to filter the monitored objects according to the monitoring labels to obtain the target Pod.

[0073] Specifically, regarding the method of determining the target Pod, the monitoring tool may be used to filter the monitored objects based on the monitoring labels to obtain the target Pod.

[0074] Taking the container cluster as a Kubernetes container cluster and the monitoring tool as the Prometheus tool as an example, the embodiment of the present application can filter out the Pods that do not need to be collected, and can add the relabel_configs (relabel) configuration on the Prometheus side to match the monitoring label (for example, label: prometheus-io-scrape). If the label is found in the Pod and the value is true, the Pod is retained; otherwise, it is discarded. In this way, Prometheus can focus on the Pods (i.e., the target Pods) of the applications (or components) that need to be monitored, filter out the Pods that do not need to be collected, and avoid waste of resources.

[0075] In an exemplary embodiment, Figure 3 As shown, the method may further include steps 302 to 306. Wherein:

[0076] Step 302, in response to receiving a Pod creation request, triggering a target callback function; the Pod creation request includes Pod metadata;

[0077] Specifically, when a Pod creation request is received, a target callback function may be triggered to execute the target callback function; optionally, the Pod creation request may refer to a request to create an application Pod.

[0078] The Pod creation request may carry Pod metadata. Exemplarily, the Pod metadata may refer to the metadata of the Pod, and the embodiment of the present application may check the metadata of the Pod.

[0079] Step 304, execute the target callback function to intercept the Pod creation request, and if the monitoring label does not exist in the Pod metadata, insert the monitoring label into the Pod metadata to obtain the target Pod metadata;

[0080] Specifically, the target callback function can be executed to intercept the Pod creation request, and then the Pod metadata can be checked to insert the monitoring label into the Pod metadata. Taking the monitoring label as label as an example, the checking process may include but is not limited to: traversing the metadata / labels field of the Pod, if the label: prometheus-io-scrape=true (i.e., the monitoring label) is found, no operation is performed; if it does not exist, the label is added to the metadata / labels field. Then, the label can be automatically injected into the applications (or components) that need to be monitored, so there is no need to manually add labels before the application (or component) is deployed.

[0081] When the monitoring label is inserted into the Pod metadata, the target Pod metadata can be obtained.

[0082] It can be understood that the above-mentioned implementation method of intercepting the Pod creation request based on the target callback function can also adopt other forms, and is not limited to the forms mentioned in the above embodiments, as long as it can achieve the function of intercepting the Pod creation request and injecting the monitoring label.

[0083] Step 306: Create a container group Pod based on the target Pod metadata.

[0084] Specifically, a container group Pod can be created according to the target Pod metadata, that is, a Pod is created.

[0085] In the above, by introducing the target callback function, the monitoring label is automatically injected into the Pod of the application (or component) to be monitored, without the need to intervene in the application (or component) in advance, thus achieving non-intrusive deployment of the application (or component).

[0086] In one embodiment, the target callback function includes a webhook-based callback function.

[0087] Specifically, the webhook service can be used to implement related functions of the target callback function, such as automatic label injection by the webhook. Optionally, the embodiment of the present application deploys the webhook service in the form of a Pod. It can be understood that deployment in the form of a Pod is a method of cloud-native deployment, and the present application does not limit this.

[0088] For example, the container cluster is a Kubernetes container cluster, the monitoring label is a preset label, and the target callback function uses a webhook-based callback function (webhook service) as an example. Figure 4 As shown, the webhook service process may include that when the apiserver receives a request to create an application pod, the webhook can intercept the request (i.e., intercept the request to create a Pod), and then check the metadata of the Pod. The checking process is: traverse the metadata / labels field of the Pod (check the metadata / labels field), and determine whether there is a preset label. If the label is found to exist: prometheus-io-scrape=true (preset label), do not do anything and create the Pod; if it does not exist, add the preset label to the metadata / labels field and create the Pod; the embodiment of the present application can automatically inject labels for applications (or components) that need to be monitored, without the need to manually add labels before the application (or component) is deployed.

[0089] As described above, the embodiment of the present application utilizes the webhook mechanism of Kubernetes to automatically inject labels into the Pods of the applications that need to be monitored, without the need to intervene in the applications (or components) in advance, thereby achieving non-invasive resource deployment.

[0090] To further illustrate the solution of this application, a specific example is given below. The container cluster is a Kubernetes container cluster (K8s), the monitoring label is label, the target callback function uses the webhook service, and the monitoring tool uses Prometheus as an example. Figure 5As shown in the figure, the overall process of the monitoring and collection method based on K8s can include: deploying Prometheus in the form of statefulsets, and setting the collection mode to kubernetes_ sd_ configs, role = pod; deploying the webhook service in the form of Pod, and automatically injecting labels for the applications that need to be monitored; Prometheus filters the Pods that do not need to be collected according to the labels, generates corresponding targets for the remaining Pods, and collects their monitoring indicators. Among them, Prometheus can generate corresponding collection targets for the remaining Pods after filtering in the above steps, collect their monitoring indicators, and the default indicator pull address can be: http: / / ${podIp}:${podPort} / metrics.

[0091] Specifically, the interaction process between services can be as follows: Figure 6 As shown:

[0092] Step (1) prepare a K8s cluster and deploy Prometheus in statefulset mode. The collection configuration of Prometheus is as follows:

[0093] job_name: "kubernetes-pods"

[0094] honor_labels:true

[0095] kubernetes_sd_configs:

[0096] - role: pod

[0097] Step (2) deploys the webhook in the form of a Pod, intercepts the apisever's request to create the application Pod, checks the metadata / labels field of the Pod, and adds the agreed label: prometheus-io-scrape=true. Part of the code is as follows:

[0098] String patchStr = "[{ |"op ": \"add ",\"path\":" / metadata / labels\","+

[0099] "\"value\": {\"prometheus-io-scrape\":\"true\"}}]"

[0100] Step (3), Prometheus adds the relabel_config configuration to filter out pods that do not need to be monitored according to the label in step (2). Part of the code is as follows:

[0101] relabel_configs:

[0102] -source labels:[ _ _meta_kubernetes_pod_label_prometheus_io_scrape]

[0103] action: keep

[0104] regex: true

[0105] In step (4), Prometheus generates corresponding collection targets for the remaining Pods filtered in step (3) and collects their monitoring indicators.

[0106] As mentioned above, the embodiment of the present application realizes Prometheus's automatic discovery of information about applications running in k8s by configuring Prometheus with a service discovery mode based on k8s, which is more flexible than the traditional static discovery mode of Prometheus, which requires manual addition of application information. In addition, the embodiment of the present application uses the webhook service to automatically inject labels into the pod of the application to be monitored, without the need to manually modify its yaml file to add labels before the application is deployed, thus realizing non-invasive application deployment.

[0107] This application uses a cloud-native approach to quickly deploy Prometheus, and configures the collection to a Kubernetes-based service discovery mode, which is more flexible than the traditional static discovery mode and reduces the risk of port exposure. The webhook service is introduced to automatically inject labels into the Pods of the applications (or components) that need to be monitored, without the need to intervene in the applications (or components) in advance. Among them, by deploying Prometheus in a cloud-native way and configuring a K8s-based service discovery mode, not only the automatic discovery of monitoring and collection objects is achieved, but also the introduction of the webhook service automatically injects labels into the applications that need to be monitored, achieving non-invasive resource deployment.

[0108] It should be understood that, although the various steps in the flowcharts involved in the above-mentioned embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above-mentioned embodiments can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0109] Based on the same inventive concept, the embodiment of the present application also provides a monitoring and collection device for a container cluster for implementing the monitoring and collection method for a container cluster involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations in the embodiments of the monitoring and collection device for one or more container clusters provided below can refer to the limitations of the monitoring and collection method for container clusters above, and will not be repeated here.

[0110] In an exemplary embodiment, Figure 7 As shown, a monitoring and collection device for a container cluster is provided, including:

[0111] The monitoring object acquisition module 901 is used to acquire the objects to be monitored of the container cluster; the objects to be monitored include the container group Pods that have completed the monitoring label injection during the Pod creation process;

[0112] A target determination module 902 is used to determine a target Pod among the objects to be monitored based on the monitoring tags;

[0113] The collection module 903 is used to generate a target object based on the target Pod, collect monitoring indicators of the target object, and obtain monitoring collection results.

[0114] In one of the embodiments, the monitoring indicators include JVM monitoring indicators and database monitoring indicators; the target objects include applications or components in the container cluster.

[0115] In one embodiment, the monitoring object acquisition module 901 includes:

[0116] The tool deployment module is used to deploy monitoring tools to the container cluster using StatefulSet. The monitoring target of the monitoring tool is the container group Pod.

[0117] The monitoring module is used to obtain the object to be monitored through the monitoring tool.

[0118] In one of the embodiments, the monitoring tool includes a Prometheus tool; the service discovery mode of the Prometheus tool is configured as an automatic discovery mode based on K8s.

[0119] In one embodiment, the target determination module 902 is used to filter the monitored objects according to the monitoring tags through the monitoring tool to obtain the target Pod.

[0120] In one embodiment, the device further comprises:

[0121] A function trigger module, configured to trigger a target callback function in response to receiving a Pod creation request; the Pod creation request includes Pod metadata;

[0122] The interception and insertion module is used to execute the target callback function to intercept the Pod creation request, and to insert the monitoring label into the Pod metadata to obtain the target Pod metadata if the monitoring label does not exist in the Pod metadata;

[0123] The creation module is used to create a container group Pod based on the target Pod metadata.

[0124] In one of the embodiments, the target callback function includes a webhook-based callback function.

[0125] Each module in the monitoring and collection device of the container cluster can be implemented in whole or in part by software, hardware, or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in a computer device in the form of software, so that the processor can call and execute operations corresponding to each module.

[0126] In an exemplary embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as shown in FIG. Figure 8As shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, referred to as I / O) and a communication interface. Among them, the processor, the memory and the input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store data such as target callback functions. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a monitoring and collection method for a container cluster is implemented.

[0127] In an exemplary embodiment, a computer device is provided. The computer device may be a terminal, and its internal structure diagram may be as shown in FIG. Fig. 9 As shown. The computer device includes a processor, a memory, an input / output interface, a communication interface, a display unit and an input device. The processor, the memory and the input / output interface are connected through a system bus, and the communication interface, the display unit and the input device are connected to the system bus through the input / output interface. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The input / output interface of the computer device is used to exchange information between the processor and the external device. The communication interface of the computer device is used to communicate with an external terminal in a wired or wireless manner, and the wireless manner can be implemented through WIFI, a mobile cellular network, near field communication (Near Field Communication, NFC) or other technologies. When the computer program is executed by the processor, a monitoring and collection method for a container cluster is implemented. The display unit of the computer device is used to form a visually visible picture, which can be a display screen, a projection device or a virtual reality imaging device. The display screen can be a liquid crystal display screen or an electronic ink display screen, and the input device of the computer device can be a touch layer covering the display screen, or a button, trackball or touchpad set on the computer device shell, or an external keyboard, touchpad or mouse.

[0128] Those skilled in the art will understand that Figure 8 or Fig. 9The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0129] In one embodiment, a computer device is further provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the steps in the above method embodiments when executing the computer program.

[0130] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.

[0131] In one embodiment, a computer program product is provided, including a computer program, which implements the steps in the above method embodiments when executed by a processor.

[0132] A person of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, an artificial intelligence (AI) processor, etc., but are not limited to this.

[0133] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0134] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A monitoring and collection method for a container cluster. It is characterized in that The method comprises: Obtain the object to be monitored of the container cluster; the object to be monitored includes the container group Pod that completes the injection of monitoring labels during the Pod creation process; Based on the monitoring label, determine the target Pod in the object to be monitored; A target object is generated based on the target Pod, monitoring indicators of the target object are collected, and monitoring collection results are obtained.

2. The method according to claim 1, It is characterized in that The monitoring indicators include JVM monitoring indicators and database monitoring indicators; the target objects include applications or components in the container cluster.

3. The method according to claim 1, It is characterized in that The obtaining of the object to be monitored of the container cluster includes: Deploy a monitoring tool to the container cluster using StatefulSet; wherein the monitoring target of the monitoring tool is the container group Pod; The object to be monitored is obtained through the monitoring tool.

4. The method according to claim 3, It is characterized in that The monitoring tool includes a Prometheus tool; the service discovery mode of the Prometheus tool is configured as an automatic discovery mode based on K8s.

5. The method according to claim 3, It is characterized in that The determining, based on the monitoring label, a target Pod in the object to be monitored includes: The monitoring tool is used to filter the objects to be monitored according to the monitoring tags to obtain the target Pod.

6. The method according to any one of claims 1 to 5, It is characterized in that The method further comprises: In response to receiving a Pod creation request, triggering a target callback function; the Pod creation request includes Pod metadata; Executing the target callback function to intercept the Pod creation request, and inserting the monitoring label into the Pod metadata if the monitoring label does not exist in the Pod metadata, to obtain the target Pod metadata; Based on the target Pod metadata, create the container group Pod.

7. The method according to claim 6, It is characterized in that The target callback function includes a callback function based on webhook.

8. A monitoring and collection device for a container cluster, It is characterized in that The device comprises: A monitoring object acquisition module is used to acquire the monitored object of the container cluster; the monitored object includes the container group Pod that completes the monitoring label injection during the Pod creation process; A target determination module, used to determine a target Pod in the object to be monitored based on the monitoring tag; The collection module is used to generate a target object based on the target Pod, collect monitoring indicators of the target object, and obtain monitoring collection results.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program. It is characterized in that When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium having a computer program stored thereon, It is characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images