CN116149782A - Data acquisition method and device, electronic equipment and computer readable storage medium - Google Patents

Abstract

The present disclosure provides a data acquisition method and apparatus, an electronic device, and a computer-readable storage medium, the method comprising: obtaining a container identifier of a target container, wherein the target container is any container in an operating state on electronic equipment; acquiring a process identifier of a target process according to the container identifier, wherein the target process is a running process corresponding to the target container on the electronic equipment; determining a resource file corresponding to the target container according to the process identifier; and collecting resource monitoring data of the target container according to the resource file, wherein the resource monitoring data is used for reflecting the state of the resources in the target container. According to the embodiment of the disclosure, the resource monitoring data of the container can be conveniently and efficiently collected on the premise of low resource occupation.

Description

Data acquisition method and device, electronic equipment and computer readable storage medium

Technical Field

The disclosure relates to the field of computer technology, and in particular, to a data acquisition method and device, electronic equipment, and a computer readable storage medium.

Background

With the wave of cloud proto-containerization, more and more enterprises gradually apply Container (Container) technology to their IT architecture and put into practice in production environments. The data that the container needs to monitor is multiplied compared to conventional devices, thus presenting a greater challenge to the monitoring system.

In contrast to conventional host devices, a container is only one process in its manifestation, and does not have a separate kernel, so the collection manner of resource monitoring data of the container is different from that of the conventional device. In the related art, the resource monitoring data of the container is generally collected by a container arrangement engine, for example, a built-in monitoring component cadvisor in Kubernetes, and the collection manner can collect the monitoring data of resources such as a CPU, a memory and the like in the container relatively efficiently, but the resource monitoring data such as a Tcp/Udp connection number cannot be collected efficiently for network monitoring data, and even if the resource monitoring data can be collected, a problem that the resource occupation is large is also caused, and further, the host machine where the container is located may be down because of the large resource occupation. Therefore, it is necessary to provide a data collection method to solve the problems of inconvenience and resource waste that may exist in the related art when collecting the resource data of the container.

Disclosure of Invention

The disclosure provides a data acquisition method and device, electronic equipment and a computer readable storage medium.

In a first aspect, the present disclosure provides a data collection method applied to a proxy, where the proxy operates on an electronic device deployed with at least one container, the data collection method including:

Obtaining a container identifier of a target container, wherein the target container is any container in an operating state on the electronic equipment;

acquiring a process identifier of a target process according to the container identifier, wherein the target process is a running process corresponding to the target container on the electronic equipment;

determining a resource file corresponding to the target container according to the process identifier;

and collecting resource monitoring data of the target container according to the resource file, wherein the resource monitoring data is used for reflecting the state of resources in the target container.

In a second aspect, the present disclosure provides a data acquisition device for application to a proxy running on an electronic device deployed with at least one container, the data acquisition device comprising:

the device comprises a container identifier obtaining unit, a container identifier obtaining unit and a storage unit, wherein the container identifier obtaining unit is used for obtaining a container identifier of a target container, and the target container is any container in an operation state on the electronic equipment;

a process identifier obtaining unit, configured to obtain a process identifier of a target process according to the container identifier, where the target process is an operation process corresponding to the target container on the electronic device;

The resource file determining unit is used for determining a resource file corresponding to the target container according to the process identifier;

the collection unit is used for collecting the resource monitoring data of the target container according to the resource file, wherein the resource monitoring data are used for reflecting the state of the resources in the target container.

In a third aspect, the present disclosure provides an electronic device comprising: at least one processor; and a memory communicatively coupled to the at least one processor; wherein the memory stores one or more computer programs executable by the at least one processor, one or more of the computer programs being executable by the at least one processor to enable the at least one processor to perform the data acquisition method described above.

In a fourth aspect, the present disclosure provides a computer readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the data acquisition method described above.

According to the embodiment provided by the disclosure, the proxy end is arranged on the electronic equipment deployed with at least one container, and the proxy end obtains the container identifier of any running target container and obtains the process identifier of the running process corresponding to the target container on the electronic equipment according to the container identifier, so that the resource file corresponding to the target container can be determined according to the process identifier, and after the resource file is determined, the proxy end does not need to interact with the inside of the container, but can directly acquire the resource monitoring data corresponding to the target container according to the resource file.

Compared with the problems of inconvenience and large resource waste possibly existing in the related art when the resource data of the container are acquired based on the existing monitoring component, such as the cadvisor component, the method provided by the embodiment of the disclosure can not rely on the component to acquire the resource data of the container, but can locate the resource file corresponding to the target container on the electronic device by acquiring the process identifier of the target process corresponding to the target container through the proxy running on the electronic device, so as to acquire the resource monitoring data of the target container by analyzing the resource file.

It should be understood that the description in this section is not intended to identify key or critical features of the embodiments of the disclosure, nor is it intended to be used to limit the scope of the disclosure. Other features of the present disclosure will become apparent from the following specification.

Drawings

The accompanying drawings are included to provide a further understanding of the disclosure, and are incorporated in and constitute a part of this specification, illustrate embodiments of the disclosure and together with the description serve to explain the disclosure, without limitation to the disclosure. The above and other features and advantages will become more readily apparent to those skilled in the art by describing in detail exemplary embodiments with reference to the attached drawings, in which:

FIG. 1 is a schematic diagram of a data acquisition process;

FIG. 2 is a schematic diagram of an implementation environment of a data acquisition method provided by an embodiment of the present disclosure;

fig. 3 is a flowchart of a data acquisition method according to an embodiment of the present disclosure;

FIG. 4 is a flow chart for obtaining a container identifier provided by an embodiment of the present disclosure;

fig. 5 is a block diagram of a data acquisition device according to an embodiment of the present disclosure;

fig. 6 is a block diagram of an electronic device according to an embodiment of the present disclosure.

Detailed Description

For a better understanding of the technical solutions of the present disclosure, exemplary embodiments of the present disclosure will be described below with reference to the accompanying drawings, in which various details of the embodiments of the present disclosure are included to facilitate understanding, and they should be considered as merely exemplary. Accordingly, one of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the present disclosure. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.

Embodiments of the disclosure and features of embodiments may be combined with each other without conflict.

As used herein, the term "and/or" includes any and all combinations of one or more of the associated listed items.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. The terms "connected" or "connected," and the like, are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect.

Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and the present disclosure, and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

In the related art, in order to collect resource monitoring data of a container, the resource monitoring data of the container is usually collected based on a container arrangement engine, for example, a built-in monitoring component cadvisor in Kubernetes, however, when collecting resource monitoring data of the container based on the cadvisor, for some data, for example, the collection of monitoring data related to a network such as Tcp/Udp connection number, the cadvisor component defaults to turn off the function because of the problem of low collection efficiency and large resource occupation when collecting, and if the collection of such data needs to be started, the code of the kubeelet module where the cadvisor component is located needs to be recompiled, which is not only time-consuming and labor-consuming, but also is unfavorable for subsequent maintenance and upgrading.

Of course, in order to realize comprehensive monitoring of resource data in a container based on the cadvisor component, and also in order to facilitate subsequent maintenance and upgrade, a cadvisor component which is compiled independently and has a network monitoring data acquisition function started can be deployed independently, however, in this way, the problem of repeated deployment exists, and although the comprehensive monitoring of the resource data in the container can be realized, the problems of low acquisition efficiency and large resource occupation still cannot be solved.

Please refer to fig. 1, which is a schematic diagram of a data acquisition process. In order to solve the above-described technical problems, the inventors found that it is also possible to separately collect resource monitoring data of a container by writing a collection script by itself, that is, as shown in fig. 1, it is possible to dispose a data collection script inside each container in an electronic device, for example, a server, for example, a form of disposing a script 1 in a container 1, disposing a script 2 in a container 2, to collect resource monitoring data of the container 1, the container 2 based on the script 1, the script 2, respectively, and to transmit the resource monitoring data, for example, resource monitoring data 1 of the container 1, resource monitoring data 2 of the container 2, to a monitoring system, for example, a promethas system for use; the scripts deployed in each container can be collected through instructions corresponding to each resource, for example, for network monitoring data, the scripts can be collected through netstat instructions or ss instructions; netstat instructions are typically used to display various network related information such as network connections, routing tables, interface status, invalid connections, multicast members, etc.; the ss instruction is generally used to obtain socket statistics, and the instruction displays similar content as netstat instruction, but can display more detailed information about TCP and connection status, and is more efficient than netstat.

Compared with the method in the related art, the method for collecting the resource monitoring data of the containers based on the script deployed in each container has relatively low occupation of resources, but when the number of containers on the same electronic device is large, the execution efficiency is reduced, so that the resource monitoring data of each container may not be uploaded to the monitoring system in time. In addition, this approach is an intrusive solution, i.e., the need to drive the collection script into the container interior to run with the application within the container, which does not follow the concept of cloud native microservice single container single service.

Please refer to fig. 2, which is a schematic diagram illustrating an implementation environment of a data collection method according to an embodiment of the disclosure. As shown in fig. 2, the implementation environment may include an electronic device 100 with a proxy end 101 deployed in the electronic device 100 and also with at least one container, for example, a container 102 as shown in fig. 2.

The electronic device 100 may be a physical server, for example, a blade server, a rack-mounted server, or the like, or may be a virtual server, for example, a server cluster deployed in the cloud, which is not limited herein.

The proxy 101 may be a data collection application directly deployed on the electronic device 100, or may also be a container running on the electronic device 100, where the data collection application runs in the container; the proxy is used to implement the data collection method of any embodiment of the present disclosure to collect resource monitoring data of all containers, e.g., container 102, running on the electronic device 100.

Container 102 may be a container created based on any virtualized container technology, e.g., a container created for an open source based application container engine Docker; the Docker is an open-source application container engine, which can enable an developer to package applications and rely on packages to a portable container, then release the packages to any popular machine of Linux or Windows operating system, and also realize virtualization, wherein the containers completely use a sandbox mechanism without any interface; a complete Docker is generally composed of the following parts: the method comprises the steps of a Docker Client, a Docker Daemon Daemon, a Docker Image mirror and a Docker Container, wherein the Docker Daemon Daemon is a Docker Daemon, the Docker Client can communicate with the Docker Daemon through a command line to complete the Docker related operation, and the main functions of the Docker Daemon Daemon comprise mirror management, mirror construction, REST API, identity verification, security, core network and arrangement.

In the embodiments of the present disclosure, the proxy end 101 may be used to participate in implementing the data acquisition method according to any embodiment of the present disclosure. For example, can be used to: acquiring a container identifier of a target container, wherein the target container is any container in an operating state on electronic equipment, for example, may be the container 102; acquiring a process identifier of a target process according to the container identifier, wherein the target process is a running process corresponding to the target container on the electronic equipment; determining a resource file corresponding to the target container according to the process identifier; and collecting resource monitoring data of the target container according to the resource file, wherein the resource monitoring data is used for reflecting the state of the resources in the target container.

It will be appreciated that the implementation environment shown in fig. 2 is merely illustrative and is in no way intended to limit the disclosure, its application or uses. For example, although fig. 2 shows only one electronic device 100, a proxy end 101 running on the electronic device 100, and one container 102, it is not meant to limit the number of each, and more containers may be included in the electronic device 100; alternatively, the implementation environment may include a plurality of electronic devices 100, where each electronic device 100 may include a proxy 101 and a plurality of containers 102.

In order to collect resource data of a container conveniently, efficiently and without occupying too much resources, an embodiment of the present disclosure provides a data collection method, please refer to fig. 3, which is a flowchart of the data collection method provided by the embodiment of the present disclosure. The method may be applied to a proxy that runs on an electronic device that is deployed with at least one container, for example, the proxy may be the proxy 101 shown in fig. 2, the electronic device may be the electronic device 100 shown in fig. 2, and the container may be the container 102 shown in fig. 2.

As shown in fig. 3, the data acquisition method provided in the embodiment of the present disclosure may include the following steps S301 to S304, which are described in detail below.

Step S301, obtaining a container identifier of a target container, where the target container is any container in an operation state on the electronic device.

The target container may be a virtual container created based on any container technology, such as Docker, hypervisor, etc., and one container may have at least one application running therein.

The container identifier is a character string for uniquely identifying the target container, and may be, for example, a container name.

In the embodiments of the present disclosure, the target container is a Docker container created based on Docker technology, unless otherwise specified. In addition, the electronic device may be a device running any operating system, which may be a Linux operating system, or may also be a Windows operating system, for example, may be a Windows Server operating system; in the following description, the electronic device will be described as a device running the Linux operating system, unless otherwise specified, because the container is usually run in the Linux operating system during daily operation.

The container technology is a sand box technology, namely, the container technology can be used for 'loading' the application like a container, so that the application and the application are not mutually interfered because of the boundary, and the application loaded into the sand box can be conveniently moved; the core function of the container technology is to create a 'boundary' for the dynamic representation of the constraint and modification Process (Process); in implementation, the container technology is to encapsulate and isolate processes in an operating system based on a namespace (namespace), so that a container created based on the container technology is essentially a special process, and a container in a running state, such as a Docker container, is essentially a service process that enables multiple namespaces.

As can be seen from the above brief description of the implementation principle of the container technology, each running container is essentially a service Process (Process) on the host machine, i.e. the running electronic device, and according to the principle of the operating system, such as Linux operating system, the resource usage of each Process, for example, the network usage, is written into the system/proc/{ pid }/net/sockstat file by the operating system in real time, where pid is a Process identifier, and sockstat represents a resource file corresponding to the network usage of the Process, i.e. a network communication file. Therefore, the resource use state of the container running in the electronic equipment can be actually obtained by acquiring the process identifier of the process corresponding to the container on the operating system, positioning the process identifier to the resource file corresponding to the container by taking the process identifier as the query key, and then obtaining the resource monitoring data reflecting the state of the resource in the container by analyzing the resource file.

That is, in the embodiment of the present disclosure, a script for collecting resource monitoring data of a container may not be deployed in the container, that is, the script does not need to invade into the container, but may conveniently and efficiently collect resource monitoring data of all containers on a host through one proxy running on an electronic device where the container is located, that is, the host, and meanwhile, may also conform to the concept of single service of a cloud native micro-service single container, so as to facilitate upgrade and maintenance of data collection application in the proxy.

In the embodiment of the disclosure, the container identifier may be sent to the proxy end by the user based on the terminal device, so that the proxy end collects the resource monitoring data of the target container corresponding to the container identifier, or the container identifier may be obtained by the proxy end through other manners, which is not limited in particular herein.

Step S302, a process identifier of a target process is obtained according to the container identifier, wherein the target process is a running process corresponding to the target container on the electronic device.

In the embodiment of the disclosure, the process identifier may be obtained by the following steps: and obtaining the process identifier by using a preset process query instruction according to the container identifier.

The preset process inquiry instruction can be a docker container top container identification instruction or a container name instruction of dock issue-f '{ { state.pid }'. For example, in the case that the container identifier is "container01", the proxy may obtain the process identifier corresponding to the container, i.e. the pid, by running the process query instruction docker container top container ".

It should be noted that, in the above embodiment of obtaining the process identifier of the target process provided in the embodiments of the present disclosure, the process identifier may of course be obtained by other process query instructions in actual implementation, which is not limited herein.

Step S303, determining a resource file corresponding to the target container according to the process identification.

In the embodiment of the present disclosure, the resource file may be a file corresponding to at least one of resources such as a central processor, a memory, a disk, and a network; correspondingly, in the embodiment of the present disclosure, the resource monitoring data to be collected corresponding to the target container may include: the cpu uses relevant monitoring data, i.e. cpu monitoring data, and the monitoring data related to the memory use, i.e. memory monitoring is data, the monitoring data related to the disk read-write, i.e. disk I/O monitoring data, and may also contain monitoring data related to the network use situation, i.e. network monitoring data, such as Tcp/Udp connection number.

After the process identifier of the running process corresponding to the target container on the electronic device is obtained in step S302, the resource file corresponding to the target container may be determined according to the process identifier.

For example, in the case where the process identifier is "101", in the case where the acquisition resource is a CPU resource, the resource file may be "/proc/101/stat", i.e., a stat file under/proc/101; for another example, in the case where the resource to be collected is a memory resource, the resource file may be "/proc/101/status", i.e., a status file under/proc/101.

Step S304, collecting resource monitoring data of the target container according to the resource file, wherein the resource monitoring data is used for reflecting the state of the resources in the target container.

After the resource file corresponding to the target container is obtained in step S303, the resource monitoring data of the target container may be acquired according to the resource file.

Compared with the problems that the existing monitoring component, such as a cadvisor component, is inconvenient and waste of resources is large when collecting the resource data of the container in the related art, the data collection method provided by the embodiment of the disclosure can not rely on the component to collect the resource data of the container, but can locate the corresponding resource file of the target container on the electronic device by acquiring the process identifier of the target process corresponding to the target container through the proxy running on the electronic device, so as to obtain the resource monitoring data of the target container by analyzing the resource file.

Referring to fig. 4, a flowchart of obtaining a container identifier is provided in an embodiment of the present disclosure. As shown in fig. 4, in some embodiments, the obtaining the container identifier of the target container in step S301 includes: step S401, obtaining communication address information of a target daemon, wherein the target daemon is a process for daemon at least one container; step S402, according to the communication address information, a query request is sent to a target daemon through a preset interface, wherein the query request is used for querying a container in an operation state on the electronic equipment; step S403, receiving a container list returned by the target daemon in response to the query request, selecting any container from the container list as a target container, and acquiring the container identification of the target container.

The target Daemon may be, for example, a Docker Daemon of dockers described above.

The communication address information may be information for indicating an access address of the Docker Daemon, and may be in the form of an IP address+port number (Port), or may also be in the form of url+port number, or may also be a storage address of the Docker Daemon, which is not particularly limited herein, considering that the Docker Daemon communicates based on a Docker file when communicating between local Docker clients on its host.

The preset interface may be a target Daemon, for example, an application program interface provided by Docker Daemon for querying the container identifier, that is, an interface in Docker API for querying the container identifier.

The query request can be obtained by splicing the communication address information and the preset interface, namely, the query request can be in the form of http:// communication address/contacts/json; or, considering that the agent and the target Daemon are located on the same electronic device in the embodiment of the present disclosure, it may also be directly based on the socket file of the Docker Daemon to send a query request to the Docker Daemon, for example, the storage address of the Docker. Sock file corresponding to the Docker Daemon may be set as an environment variable of the operating system; then, a Docker client is created by an instruction like "cli, err: =client.newenvcient ()", and then the query request is sent to the Docker Daemon and the container list is obtained by an instruction like "containers: =cli.containers list (context.background (), types.containers list options)".

After sending the query request to the target daemon, the target daemon may return the container list of the containers currently in the running state in response to the query request, and then may arbitrarily select a container identifier from the container list as the container identifier of the target container.

It can be seen that, according to the method provided by the embodiment of the present disclosure, the user does not need to specify the container identifier of the target container to be acquired for the proxy, but the proxy can automatically obtain the container identifier of the target container to be acquired by communicating with the target daemon after running.

In some embodiments, the resource file may comprise a network communication file; the step S304 of obtaining the resource monitoring data of the target container according to the resource file includes: and obtaining network monitoring data according to the network communication file, wherein the network monitoring data is data corresponding to the network connection in the resource monitoring data, and the network monitoring data is used for reflecting the state of the network connection in the target container.

That is, in order to solve the problems of inconvenience and large resource waste that may exist when the cadvisor component collects the network monitoring data of the container, such as Tcp/Udp connection number, in the related art, in the embodiment of the present disclosure, the resource file corresponding to the target container may be a network communication file, where the network communication file may be obtained by locating according to the process identifier corresponding to the target container after obtaining the process identifier corresponding to the target container, for example, the network communication file may be a "/proc/pid/sockstat", that is, a sockstat file under a/proc/pid/directory.

The Socket file is also called a Socket file; sockets are abstractions of endpoints that communicate bi-directionally between application processes on different devices in a network.

Under the condition that the target container is a Docker container or other virtual containers running in the Linux system, the corresponding network monitoring data can be conveniently and rapidly obtained by analyzing the network communication file corresponding to the running process, namely the content in the sockstat file.

That is, in this embodiment, the obtaining the network monitoring data according to the network communication file may include: and analyzing the protocol socket state data in the network communication file to obtain network monitoring data.

The content of the sockstat file may be in the form of "sockets: used 135TCP:inuse 47orphan 0tw 1273alloc52mem 46UDP:inuse 1mem 0RAW:inuse 0FRAG:inuse 0memory 0", for example.

The socket is used for representing the total amount of all used protocol sockets; an inuse for indicating the number of TCP sockets being used (listening); TCP: orphan: the number of TCP connections used to represent no master, i.e., not belonging to any process (number of TCP sockets to be destroyed, not useful); TCP: tw: for indicating the number of TCP connections waiting to be closed; TCP: alloc (allocated): for indicating the number of TCP sockets allocated, i.e. established, applied to sk_buff; TCP: mem: for representing socket buffer usage; UDP: and (4) inuse: for indicating the number of UDP sockets being used.

That is, in the network communication file corresponding to the target container, the state data related to the network connection condition is described in the form of a key value pair of < protocol socket state data item, numerical value >, and thus, in the embodiment of the present disclosure, the state data can be conveniently and quickly obtained by parsing the form of the protocol socket state data in the network communication file.

The network monitoring data may include various indexes such as establishment (Establish), inse (in use), timeWait (waiting), orphan (unoccupied), total (Total), UDP, etc., and the value of each index may be obtained by analyzing the content in the network communication file.

Therefore, the data acquisition method provided by the embodiment of the disclosure can be obtained efficiently only by analyzing the data in the corresponding network communication file when acquiring the network monitoring data of the target container, and meanwhile, more system resources are not required to be consumed. For example, through testing, network monitoring data of all containers are collected on an electronic device with hardware configured as 64C384G, i.e. 64 cpu cores, 385Gb memory resources and running 300 containers, only 300 milliseconds are consumed for all collection, instantaneity is very high, and memory consumption is only 40Mb.

In some embodiments, after obtaining the resource monitoring data, the method further comprises: the resource monitoring data is provided to a monitoring system, wherein the monitoring system is configured to monitor a resource status of the target container based on the resource monitoring data.

In the disclosed embodiment, the monitoring system may be, for example, a Prometaus system.

That is, after the resource monitoring data is obtained through the above method, in order to facilitate the user to check and facilitate better operation and maintenance of the target container based on the resource monitoring data, the agent end may provide the resource monitoring data to the monitoring system after obtaining the resource monitoring data of the target container, the monitoring system may generate a monitoring panel based on the resource monitoring data and display the monitoring panel to the user to check, and may also send preset prompt information according to a preset alarm rule when detecting that an abnormality exists in a state of a certain resource of the target container according to the resource monitoring data, where the preset prompt information is used to prompt the user to perform operation and maintenance management on the target container. For example, the monitoring system may issue an alarm notification when an abnormality in the number of network connections of the target container is detected according to the resource monitoring data, so as to prompt the user to perform operation and maintenance management on the network communication in the target container.

It should be noted that, in practical implementation, the method provided by the embodiment of the present disclosure may be used in combination with a data collection method in the related art, so as to further improve the data collection speed, for example, considering that, in the related art, based on the problem that the resource monitoring data is low in efficiency and is wasted in resource when the cadvisor component collects the resource monitoring data, the method provided by the embodiment of the present disclosure may be used to collect the resource monitoring data separately, so that the overall efficiency and the collection speed of data collection may be improved when the data collection is performed.

It will be appreciated that the above-mentioned method embodiments of the present disclosure may be combined with each other to form a combined embodiment without departing from the principle logic, and are limited to the description of the present disclosure. It will be appreciated by those skilled in the art that in the above-described methods of the embodiments, the particular order of execution of the steps should be determined by their function and possible inherent logic.

In addition, the disclosure further provides a data acquisition device, an electronic device, and a computer readable storage medium, where the foregoing may be used to implement any one of the data acquisition methods provided in the disclosure, and the corresponding technical schemes and descriptions and corresponding descriptions referring to the method parts are not repeated.

Fig. 5 is a block diagram of a data acquisition device according to an embodiment of the present disclosure.

Referring to fig. 5, an embodiment of the present disclosure provides a data acquisition apparatus applied to a proxy terminal operating in an electronic device in which at least one container is deployed, the data acquisition apparatus 500 including: a container identification acquisition unit 501, a process identification acquisition unit 502, a resource file determination unit 503, and an acquisition unit 504.

The container identifier obtaining unit 501 is configured to obtain a container identifier of a target container, where the target container is any container in an operating state on an electronic device.

The process identifier obtaining unit 502 is configured to obtain, according to the container identifier, a process identifier of a target process, where the target process is an operation process corresponding to the target container on the electronic device.

The resource file determining unit 503 is configured to determine, according to the process identifier, a resource file corresponding to the target container.

The collection unit 504 is configured to collect, according to the resource file, resource monitoring data of the target container, where the resource monitoring data is used to reflect a state of a resource in the target container.

In some embodiments, the resource file comprises a network communication file; the collection unit 504, when obtaining the resource monitoring data of the target container according to the resource file, may be configured to: and obtaining network monitoring data according to the network communication file, wherein the network monitoring data is data corresponding to the network connection in the resource monitoring data, and the network monitoring data is used for reflecting the state of the network connection in the target container.

In some embodiments, the acquisition unit 504, when obtaining network monitoring data from the network communication file, may be configured to: and analyzing the protocol socket state data in the network communication file to obtain network monitoring data.

In some embodiments, the process identifier obtaining unit 502 may be configured to, when obtaining a process identifier of a target process according to a container identifier: and obtaining the process identifier by using a preset process query instruction according to the container identifier.

In some embodiments, the container identifier obtaining unit 501 may be configured to, when obtaining the container identifier of the target container: acquiring communication address information of a target daemon, wherein the target daemon is a process for daemon at least one container; according to the communication address information, sending a query request to a target daemon through a preset interface, wherein the query request is used for querying a container in an operating state on the electronic equipment; and receiving a container list returned by the target daemon in response to the query request, selecting any container from the container list as a target container, and acquiring the container identification of the target container.

Fig. 6 is a block diagram of an electronic device according to an embodiment of the present disclosure.

Referring to fig. 6, an embodiment of the present disclosure provides an electronic device 600 including: at least one processor 601; at least one memory 602, and one or more I/O interfaces 603, connected between the processor 601 and the memory 602; the memory 602 stores one or more computer programs executable by the at least one processor 601, and the one or more computer programs are executed by the at least one processor 601 to enable the at least one processor 601 to perform the data acquisition method described above.

The disclosed embodiments also provide a computer readable storage medium having a computer program stored thereon, wherein the computer program when executed by a processor implements the data acquisition method described above. The computer readable storage medium may be a volatile or nonvolatile computer readable storage medium.

Embodiments of the present disclosure also provide a computer program product comprising computer readable code, or a non-transitory computer readable storage medium carrying computer readable code, which when run in a processor of an electronic device, performs the above-described data acquisition method.

Those of ordinary skill in the art will appreciate that all or some of the steps, systems, functional modules/units in the apparatus, and methods disclosed above may be implemented as software, firmware, hardware, and suitable combinations thereof. In a hardware implementation, the division between the functional modules/units mentioned in the above description does not necessarily correspond to the division of physical components; for example, one physical component may have multiple functions, or one function or step may be performed cooperatively by several physical components. Some or all of the physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application specific integrated circuit. Such software may be distributed on computer-readable storage media, which may include computer storage media (or non-transitory media) and communication media (or transitory media).

The term computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable program instructions, data structures, program modules or other data, as known to those skilled in the art. Computer storage media includes, but is not limited to, random Access Memory (RAM), read Only Memory (ROM), erasable Programmable Read Only Memory (EPROM), static Random Access Memory (SRAM), flash memory or other memory technology, portable compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical disc storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by a computer. Furthermore, as is well known to those of ordinary skill in the art, communication media typically embodies computer readable program instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and may include any information delivery media.

The computer readable program instructions described herein may be downloaded from a computer readable storage medium to a respective computing/processing device or to an external computer or external storage device over a network, such as the internet, a local area network, a wide area network, and/or a wireless network. The network may include copper transmission cables, fiber optic transmissions, wireless transmissions, routers, firewalls, switches, gateway computers and/or edge servers. The network interface card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium in the respective computing/processing device.

Computer program instructions for performing the operations of the present disclosure can be assembly instructions, instruction Set Architecture (ISA) instructions, machine-related instructions, microcode, firmware instructions, state setting data, or source or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, c++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The computer readable program instructions may be executed entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computer (for example, through the Internet using an Internet service provider). In some embodiments, aspects of the present disclosure are implemented by personalizing electronic circuitry, such as programmable logic circuitry, field Programmable Gate Arrays (FPGAs), or Programmable Logic Arrays (PLAs), with state information of computer readable program instructions, which can execute the computer readable program instructions.

The computer program product described herein may be embodied in hardware, software, or a combination thereof. In an alternative embodiment, the computer program product is embodied as a computer storage medium, and in another alternative embodiment, the computer program product is embodied as a software product, such as a software development kit (Software Development Kit, SDK), or the like.

Various aspects of the present disclosure are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the disclosure. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer-readable program instructions.

These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable medium having the instructions stored therein includes an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.

The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer, other programmable apparatus or other devices implement the functions/acts specified in the flowchart and/or block diagram block or blocks.

The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

Example embodiments have been disclosed herein, and although specific terms are employed, they are used and should be interpreted in a generic and descriptive sense only and not for purpose of limitation. In some instances, it will be apparent to one skilled in the art that features, characteristics, and/or elements described in connection with a particular embodiment may be used alone or in combination with other embodiments unless explicitly stated otherwise. It will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of the disclosure as set forth in the appended claims.

Claims (10)

1. A data collection method, applied to a proxy, the proxy running on an electronic device in which at least one container is deployed, the method comprising:

obtaining a container identifier of a target container, wherein the target container is any container in an operating state on the electronic equipment;

acquiring a process identifier of a target process according to the container identifier, wherein the target process is a running process corresponding to the target container on the electronic equipment;

Determining a resource file corresponding to the target container according to the process identifier;

and collecting resource monitoring data of the target container according to the resource file, wherein the resource monitoring data is used for reflecting the state of resources in the target container.

2. The method of claim 1, wherein the resource file comprises a network communication file;

the obtaining the resource monitoring data of the target container according to the resource file includes:

and obtaining network monitoring data according to the network communication file, wherein the network monitoring data is data corresponding to network connection in the resource monitoring data, and the network monitoring data is used for reflecting the state of the network connection in the target container.

3. The method of claim 2, wherein obtaining network monitoring data from the network communication file comprises:

and analyzing the protocol socket state data in the network communication file to obtain the network monitoring data.

4. The method according to claim 1, wherein the obtaining the process identifier of the target process according to the container identifier includes:

And obtaining the process identifier by using a preset process query instruction according to the container identifier.

5. The method of claim 1, wherein the obtaining a container identification of the target container comprises:

acquiring communication address information of a target daemon, wherein the target daemon is a process for daemon the at least one container;

according to the communication address information, sending a query request to the target daemon through a preset interface, wherein the query request is used for querying a container in an operation state on the electronic equipment;

and receiving a container list returned by the target daemon in response to the query request, selecting any container from the container list as a target container, and acquiring a container identification of the target container.

6. The method of claim 1, wherein after obtaining the resource monitoring data, the method further comprises:

the resource monitoring data is provided to a monitoring system, wherein the monitoring system is configured to monitor a resource status of the target container based on the resource monitoring data.

7. The method of claim 2, wherein the resource files further comprise files corresponding to at least one of a central processor, a memory, and a disk resource, respectively.

8. A data acquisition device for application to a proxy, the proxy being operable on an electronic device having at least one container disposed therein, the device comprising:

the device comprises a container identifier obtaining unit, a container identifier obtaining unit and a storage unit, wherein the container identifier obtaining unit is used for obtaining a container identifier of a target container, and the target container is any container in an operation state on the electronic equipment;

a process identifier obtaining unit, configured to obtain a process identifier of a target process according to the container identifier, where the target process is an operation process corresponding to the target container on the electronic device;

the resource file determining unit is used for determining a resource file corresponding to the target container according to the process identifier;

the collection unit is used for collecting the resource monitoring data of the target container according to the resource file, wherein the resource monitoring data are used for reflecting the state of the resources in the target container.

9. An electronic device, comprising:

at least one processor; and

a memory communicatively coupled to the at least one processor; wherein, the liquid crystal display device comprises a liquid crystal display device,

the memory stores one or more computer programs executable by the at least one processor to enable the at least one processor to perform the data acquisition method of any one of claims 1-7.

10. A computer-readable storage medium, on which a computer program is stored, characterized in that the computer program, when being executed by a processor, implements the data acquisition method according to any one of claims 1-7.

Images