CN115883407A

CN115883407A - Data acquisition method, system, equipment and storage medium

Info

Publication number: CN115883407A
Application number: CN202211494402.2A
Authority: CN
Inventors: 李传宏; 陈晓帆; 沈耿彪
Original assignee: Sangfor Technologies Co Ltd
Current assignee: Sangfor Technologies Co Ltd
Priority date: 2022-11-25
Filing date: 2022-11-25
Publication date: 2023-03-31

Abstract

The application discloses a data acquisition method, a system, equipment and a storage medium, wherein the method comprises the following steps: responding to a data acquisition instruction of a network to be monitored, and reading acquisition configuration information stored in the mapping of the control type of the extended Berkeley packet filter eBPF based on the identification information of the network to be monitored; acquiring configuration information of a network to be monitored, wherein the acquiring configuration information comprises acquiring index information of the network to be monitored; and acquiring first target data corresponding to the acquisition index information in the network to be monitored.

Description

Data acquisition method, system, equipment and storage medium

Technical Field

The embodiment of the application relates to the technical field of computers, in particular to a data acquisition method, a data acquisition system, data acquisition equipment and a storage medium.

Background

In the cloud native environment, with the wide use of virtualization technology and container technology, the scale of the cloud native network is continuously increased, and the network boundary becomes fuzzy; the dynamic property of the medium resources of the cloud native network is strong, monitored objects are expanded to virtual machines, containers and the like through a host with a limited number, the number of collected indexes in the cloud native network is increased explosively, and the traditional network monitoring scheme cannot be directly migrated into the cloud native network.

Disclosure of Invention

In order to realize the acquisition of network data in a cloud native network and realize the monitoring of the cloud native network based on the acquired network data, the embodiment of the application provides a data acquisition method, a system, equipment and a storage medium.

In one aspect, an embodiment of the present application provides a data acquisition method, where the method includes:

reading acquisition configuration information stored in the mapping of the control type of the extended Berkeley packet filter eBPF based on the identification information of the network to be monitored in response to a data acquisition instruction of the network to be monitored; acquiring configuration information of a network to be monitored, wherein the acquiring configuration information comprises acquiring index information of the network to be monitored;

and acquiring first target data corresponding to the acquisition index information in the network to be monitored.

In another aspect, an embodiment of the present application provides a data acquisition system, where the data acquisition system includes:

the reading module is used for responding to a data acquisition instruction of a network to be monitored and reading acquisition configuration information stored in the mapping of the control type of the extended Berkeley data packet filter eBPF based on the identification information of the network to be monitored; acquiring configuration information of a network to be monitored, wherein the acquiring configuration information comprises acquiring index information of the network to be monitored;

and the acquisition module is used for acquiring first target data corresponding to the acquisition index information in the network to be monitored.

On the other hand, an embodiment of the present application provides a data acquisition device, where the data acquisition device includes: the data acquisition method comprises a memory and a processor, wherein the memory stores computer-executable instructions, and the processor can realize the data acquisition method in the embodiment of the first aspect when the processor runs the computer-executable instructions on the memory.

In another aspect, an embodiment of the present application provides a computer storage medium, where the storage medium stores executable instructions, and the executable instructions, when executed by a processor, implement the data acquisition method described in the foregoing first aspect.

According to the technical scheme of the embodiment of the application, the acquisition configuration information stored in the mapping of the control type of the extended Berkeley packet filter eBPF is read based on the identification information of the network to be monitored by responding to the data acquisition instruction of the network to be monitored; acquiring configuration information of a network to be monitored, wherein the acquiring configuration information comprises acquiring index information of the network to be monitored; and acquiring first target data corresponding to the acquisition index information in the network to be monitored. According to the embodiment of the application, the acquisition configuration information is stored by utilizing the control type mapping of the eBPF, and the network data in the network to be monitored can be dynamically acquired according to the acquisition index information in the acquisition configuration information on the premise of not restarting an acquisition program.

Drawings

Fig. 1 is a first schematic flowchart of a data acquisition method according to an embodiment of the present disclosure;

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

fig. 3 is a schematic flow chart diagram of a data acquisition method according to an embodiment of the present application;

fig. 4 is a schematic diagram of a process of storing and outputting collected data according to an embodiment of the present application;

fig. 5 is a schematic diagram of a data acquisition framework provided in an embodiment of the present application;

FIG. 6 is a workflow of modules in a data collection framework provided by an embodiment of the present application;

FIG. 7 is a schematic diagram of a workflow provided by an embodiment of the present application;

fig. 8 is a first schematic flowchart of a collecting module according to an embodiment of the present disclosure;

fig. 9 is a schematic flowchart of a second operation of the collection module according to an embodiment of the present disclosure;

fig. 10 is a third schematic flowchart of a working process of the collection module according to the embodiment of the present application;

fig. 11 is a schematic flowchart of a work flow of a collection module according to an embodiment of the present disclosure;

fig. 12 is a schematic view of a working flow of an acquisition module according to an embodiment of the present application;

fig. 13 is a schematic workflow diagram of an output module according to an embodiment of the present application;

fig. 14 is a schematic structural component diagram of a data acquisition system according to an embodiment of the present application;

fig. 15 is a schematic structural component diagram of a data acquisition device according to an embodiment of the present application.

Detailed Description

In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all the embodiments. The components of the embodiments of the present application, as generally described and illustrated in the figures herein, could be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of the embodiments of the present application, as presented in the figures, is not intended to limit the scope of the claimed application, but is merely representative of selected embodiments of the application. All other embodiments, which can be derived by a person skilled in the art from the embodiments of the present application without making any creative effort, shall fall within the protection scope of the present application.

It should be noted that: like reference numbers and letters refer to like items in the following figures, and thus, once an item is defined in one figure, it need not be defined and explained in subsequent figures.

The term "at least one" herein means any one of a plurality or any combination of at least two of a plurality, for example, including at least one of a, B, C, and may mean including any one or more elements selected from the group consisting of a, B, and C.

Currently, network monitoring schemes for cloud native environments can be generally classified into the following two categories: invasive and non-invasive monitoring schemes:

intrusive monitoring schemes, requiring changes to the source code or binary files of the user program, such as Pythia (a modular deep learning framework for visual and language multimodal research) focus on how to automatically select when and where to inject code in a distributed application; ser is an online cloud performance debugging system, which includes a lightweight Remote Procedure Call (RPC) level tracking system, an Apache thread (a development framework specifically used to develop cross-platform service development) based time sequence interface, and is used to collect end-to-end trace of request execution and trace incomplete requests of each micro-service. Seer uses these traces to train a deep neural network to identify impending Quality of Service (QoS) violations, and to identify microservices that lead to performance degradation; a delay time fault location system based on spectrum analysis in micro service environment is introduced, which inserts a tracking Interface into each micro service code, and acquires request information to match service mode information through a process of tracking Application Program Interface (API) to micro service Application. The intrusive monitoring scheme is closely related to the application type, the used programming language, the used protocol and the like, so that the method is poor in universality, high in difficulty and high in cost.

A non-invasive scheme, microScope (a performance diagnostic tool in a microservice environment), which monitors the change of a service dependency graph by capturing the network connection information of a microservice system; microRCA (a root cause diagnosis system of performance problems irrelevant to applications in micro-service environment) continuously collects indexes of application programs and system levels through a service grid, detects abnormal conditions of SLO (service level object) indexes, and builds an attribute graph containing services and hosts once the abnormal conditions are detected so as to model abnormal propagation between the services. MicroRCA associates anomalous symptoms of a communication service with related resource utilization to infer potential anomalous services and rank potential root causes. By correlating service anomalies with resource utilization, microRCA can identify anomalous non-compute intensive services with insignificant service anomaly symptoms and mitigate the effects of false positives on root cause location. MicroDiag (a fine-grained automatic root cause localization system) has the main idea of reasoning the root cause based on the dependency graph among the components and the causal relationship among different abnormal propagation mode construction indexes. The method comprises the following steps that MicroDiag monitors container resource information through monitoring information of an operating system level of a server node, through Cadvisor (a tool for analyzing resource occupation and performance characteristics of a Docker container in operation), and through a service grid, communication (including response delay information) among micro services is monitored; the method includes the steps that data (a website for monitoring the operation condition of the website) and Sysdig (a system monitoring attack) achieve monitoring data acquisition based on eBPF, but do not support acquisition of indexes as required, and when monitoring configuration changes, a monitoring program needs to be restarted; viperProbe (a micro-service acquisition architecture based on an extended Packet Filter (eBPF), which identifies key indexes to be acquired through offline analysis and supports real-time dynamic update, so that the acquisition of the key indexes is realized, but only some numerical index information is acquired, and other types of information are ignored; kmon (a micro service monitoring system based on eBPF) collects the eBPF technology to realize the collection of indexes, and can dynamically sense the configuration and the change of micro service information. As can be seen from the above analysis, most non-invasive monitoring schemes either rely on the service grid to achieve acquisition of the acquisition index, or achieve acquisition of the acquisition index based on the eBPF. However, this approach is not practical due to performance issues with the service grid; however, for the acquisition scheme based on the eBPF, how to solve the problems of increased resource overhead caused by increased acquisition indexes, multiple acquisition indexes, more "elegant" perception of the microservice and dynamic update of the configuration is also needed to be solved.

Compared with an intrusive monitoring scheme, the non-intrusive monitoring scheme has high applicability and low complexity and is more suitable for monitoring the cloud native network. For a non-intrusive monitoring scheme, index acquisition is realized based on a service grid, and the practicability of the method is not high due to performance problems brought by the service grid.

In order to monitor a cloud native network, the data acquisition method provided by the embodiment of the application can be applied to data acquisition in various types of networks including but not limited to the cloud native network.

In the following, in order to better understand the technical solution of the embodiment of the present application, the data acquisition method provided in the embodiment of the present application is described as follows.

Fig. 1 is a first schematic flow chart of a data acquisition method provided in an embodiment of the present application, and as shown in fig. 1, the data acquisition method includes:

s101: and responding to a data acquisition instruction of the network to be monitored, and reading acquisition configuration information stored in the mapping of the control type of the extended Berkeley packet filter eBPF based on the identification information of the network to be monitored.

In the embodiment of the application, the acquisition configuration information includes acquisition index information of the network to be monitored.

In this embodiment, the network to be monitored includes a plurality of network data to be monitored, for example, data of a host (such as memory usage rate, system load, disk space, and the like), a virtual machine (such as memory usage rate, disk input/output data, and the like), and a container (such as memory usage rate, network input/output index) in the network to be monitored; for another example, the transmission index data (such as time delay and packet loss rate) for data transmission between the devices in the network to be monitored, the data (such as access times) related to the operation of the devices in the network to be monitored, and the like.

The network to be monitored in the embodiment of the present application includes, but is not limited to, a cloud-native network.

In one embodiment, the data acquisition instructions for the network to be monitored may be generated periodically; for example, the data acquisition instruction may be generated once per hour, and the data acquisition device reads the acquisition configuration information in the eBPF control Map once per hour based on the data acquisition instruction, and acquires the network data of the network to be monitored. The triggering mode of the data acquisition instruction is not specifically limited, and can be set by a user according to requirements.

The eBPF may run a sandbox program within the operating system kernel (e.g., linux), which is used to efficiently extend the functionality of the kernel without changing the operating system kernel source code or loading kernel modules.

The eBPF Map, i.e., eBPF Map, is a general term for all different types of data storage areas available in the eBPF, is a key-value pair stored in the kernel, and can be accessed by any eBPF program for program communication in kernel mode and user mode. The eBPF map is a generic data structure that allows data to be passed back and forth within the kernel or between the kernel and the user space.

In the embodiment of the application, the collected configuration information is stored by using the mapping of the control type of the eBPF, which is called eBPF control Map for short.

The eBPF mapping includes various kinds, such as a HASH table mapping BPF _ MAP _ TYPE _ HASH, a data mapping BPF _ MAP _ TYPE _ ARRAY, and the like. In one implementation, a HASH table mapping BPF _ MAP _ TYPE _ HASH is adopted as a mapping of a control TYPE of the eBPF according to the embodiment of the present application, and is used to store acquisition configuration information of a network to be monitored.

In some embodiments, the eBPF control Map may further store other information related to the network to be monitored, besides the acquisition configuration information of the network to be monitored, and may also store acquisition configuration information of other networks, besides the network to be monitored, in order to accurately acquire the acquisition configuration information of the network to be monitored from the control Map of the eBPF, the acquisition configuration information may identify the identification information of the network to be monitored for the acquisition configuration information when being stored into the control Map of the eBPF, so that the acquisition program may read the identification information of the network to be monitored in the eBPF control Map based on the identification information of the network to be monitored.

In some embodiments, each network to be monitored may correspond to one eBPF control Map, where the eBPF control Map corresponds to identification information of one network to be monitored, and the eBPF control Map is used to store acquisition configuration information of the network to be monitored.

S102: and acquiring first target data corresponding to the acquisition index information in the network to be monitored.

In the embodiment of the application, in order to monitor various network data in a network to be monitored, the various network data in the network to be monitored need to be collected, so that analysis is performed based on the collected various network data. In order to realize the acquisition of various network data in the network to be monitored, acquisition configuration information of the network to be monitored can be configured in advance, and the network data in the network to be monitored is acquired to obtain first target data corresponding to the acquisition index information in the network to be monitored.

In the embodiment of the application, the data acquisition equipment acquires the network data in the network to be monitored, specifically, the acquisition program in the data acquisition equipment acquires the network data in the network to be monitored; wherein the data acquisition device may be one of the devices comprised in the network to be monitored.

In the embodiment of the application, the acquisition program is used for reading the acquisition configuration information stored in the eBPF control Map, and then the acquisition program acquires the network data of the network to be monitored based on the acquisition index information contained in the acquisition configuration information to obtain the first target data. In one embodiment, the acquisition procedure is an eBPF acquisition procedure.

In one embodiment, the step S102 includes: acquiring first target data corresponding to the acquisition index information in the network to be monitored; or collecting network data in the network to be monitored, and filtering the network data based on the collected index information to obtain first target data corresponding to the collected index information.

After the acquisition program reads the acquisition configuration information in the eBPF control Map, directly acquiring network data corresponding to the acquisition index information in the network to be monitored according to the acquisition index information contained in the acquisition configuration information to obtain first target data. Or, the acquisition program may directly acquire the network data corresponding to the default acquisition index in the network to be monitored according to the preset default acquisition index, and then filter the acquired network data corresponding to the default acquisition index based on the acquisition index information included in the acquisition configuration information in the read eBPF control Map to obtain the first target data.

According to the technical scheme of the embodiment of the application, the eBPF control Map is used for storing the acquisition configuration information, the acquisition configuration information stored in the eBPF control Map is read by an acquisition program under the condition that the network data of the network to be monitored need to be acquired, and then the network data in the network to be monitored are acquired based on the acquisition index information in the read acquisition configuration information. According to the embodiment of the application, the mode that the Map is controlled by the eBPF to store the acquisition configuration information is utilized, and the acquisition of the network data in the network to be monitored can be dynamically carried out according to the acquisition configuration information on the premise of not restarting an acquisition program.

Fig. 2 is a schematic flow chart diagram of a data acquisition method provided in an embodiment of the present application, and as shown in fig. 2, the data acquisition method includes:

s201: and acquiring user configuration information, and analyzing the user configuration information to acquire acquisition index information of the network to be monitored and index information of a target platform.

In the embodiment of the application, a user sets user configuration information according to requirements, wherein the user configuration information comprises index information needing to be monitored in a network to be monitored, namely acquisition index information. In addition, in some cases, the user needs to acquire index information related to some network platforms, for example, index information related to kubernets (k 8 s). Kubernets is a lightweight and extensible open source platform for managing containerized applications and services.

In one embodiment, the acquisition indicator information includes at least one of: adding acquisition indexes, updating acquisition parameters and deleting acquisition indexes; the acquisition parameters include at least one of: collection frequency, collection period, collection times, data collection length and collection time.

Because various states in the network to be monitored may change, for example, the number of hosts or clients accessed in the network to be monitored may change, and accordingly, the collected index information in the network to be monitored may also change. For example, in the case of adding a new host to a network to be monitored, acquisition indexes related to the newly added host need to be correspondingly added; for another example, if the acquisition frequency of data related to a certain device in the network to be monitored may need to be adjusted, the acquisition cycle parameter corresponding to the acquisition index of the device may also be changed correspondingly; or, in the case that a certain device in the network to be monitored leaves a set network area or fails, the data related to the device does not need to be collected any more, and the collection index related to the device needs to be deleted.

In an embodiment, the collection configuration information further includes platform data of a target platform, and the platform data corresponding to the index information of the target platform may be acquired from a target component by using an interface provided by a client library of the target platform. And after the platform data of the target platform is obtained, storing the platform data of the target platform into the mapping of the control type of the eBPF.

For example, if the information obtained by analyzing the user configuration information further includes index information of the target platform, such as index information related to kubernets (k 8 s), such as Pod (smallest resource management component in kubernets) information and node information in the k8s platform, the information related to the related index information of k8s is pulled to an API server (one of key components of kubernets) through an interface provided by client-go (a client calling a kubernets cluster resource object application program interface), and the information related to the related index information of k8s is stored in the eBPF control Map.

For example, when the network data to be collected by the network to be monitored is traffic information such as a container and Pod, the collected traffic information of the container and Pod needs to be associated with the platform data of k8 s.

S202: and updating the mapping of the control type of the eBPF based on the acquisition index information of the network to be monitored.

In the embodiment of the application, after the user configuration information is analyzed, if the acquisition index information obtained through analysis includes the acquisition index information of the network to be monitored, the historical acquisition index information in the control Map of the eBPF can be directly updated based on the acquisition index information obtained through analysis.

In one embodiment, the step S202 includes:

under the condition that the acquisition index information comprises the newly added acquisition index, storing the newly added acquisition index into the mapping of the control type of the eBPF;

updating the acquisition parameters of the acquisition indexes corresponding to the updated acquisition parameters in the mapping of the control type of the eBPF under the condition that the updated acquisition parameters are included in the acquisition index information;

deleting the deleted acquisition indicator in the mapping of the control type of the eBPF under the condition that the acquisition indicator information comprises the deleted acquisition indicator.

Under the condition that the acquisition indexes are changed, whether acquisition indexes need to be added, parameters of the acquisition indexes need to be updated or the acquisition indexes need to be deleted, operations such as adding, updating and deleting of the corresponding acquisition indexes can be carried out in the control Map of the eBPF.

Under the condition that the acquisition parameters of the acquisition indexes need to be updated, the acquisition parameters of the acquisition indexes can be directly changed in the eBPF control Map; when the acquisition index needs to be deleted, the acquisition index needing to be deleted can be directly deleted in the eBPF control Map.

S203: and reading the acquisition index information stored in the mapping of the control type of the eBPF based on the identification information of the network to be monitored.

S204: and acquiring first target data corresponding to the acquisition index information in the network to be monitored.

In the embodiment of the application, after the acquisition index is updated in the eBPF control Map, the acquisition program can acquire data in a network based on the updated acquisition index; for example, when the acquisition period of a certain acquisition index in the eBPF control Map changes, the acquisition program acquires data corresponding to the corresponding acquisition index according to the new acquisition period. Under the condition that a certain acquisition index is deleted from the eBPF control Map, the acquisition program does not acquire the network data corresponding to the deleted acquisition index in the network to be monitored any more.

According to the technical scheme, a user sets acquisition index information in a network to be monitored according to requirements, the eBPF control Map is used for storing the acquisition index information in the network to be monitored, if the user requirements comprise updated acquisition index information, the updated acquisition index information is updated to the eBPF control Map, then an acquisition program is used for reading the updated acquisition index information stored in the eBPF control Map, and acquisition of network data corresponding to the updated acquisition index information in the network to be monitored is achieved. According to the technical scheme of the embodiment of the application, the network data related to the updated acquisition index information in the network to be monitored can be acquired dynamically according to the requirements of the user on the premise of not restarting the acquisition program.

Fig. 3 is a schematic flow chart diagram of a data acquisition method provided in the embodiment of the present application, and as shown in fig. 3, the data acquisition method includes:

s301: responding to a data acquisition instruction of a network to be monitored, and reading acquisition configuration information stored in the mapping of the control type of the extended Berkeley packet filter eBPF based on the identification information of the network to be monitored; the acquisition configuration information comprises newly added acquisition indexes.

S302: and determining an eBPF acquisition program mounting point of the target type corresponding to the newly added acquisition index and a target eBPF acquisition program.

In the embodiment of the application, a collection program is used for collecting network data in a network to be monitored; the acquisition procedure may be an eBPF acquisition procedure.

The eBPF program includes a variety of program TYPEs such as a network packet filter BPF _ PROG _ TYPE _ SOCKET _ FI LTER, a network flow control operation BPF _ PROG _ TYPE _ SCHED _ ACT, a determination whether a DEVICE operation should be allowed BPF _ PROG _ CGROUP _ DEVICE, and the like. The type of eBPF acquisition procedure used typically varies for different acquisition metrics.

When the acquisition index is updated and is a newly added acquisition index, an acquisition program mounting point corresponding to the newly added acquisition index and an eBPF acquisition program corresponding to the newly added acquisition index need to be determined.

In one embodiment, the eBPF acquisition program mount point for determining the target type corresponding to the newly added acquisition indicator may be determined as follows:

determining whether the collectable indexes in the tracking point list can cover the newly added collecting indexes;

determining eBPF acquisition program mounting points of the tracking point types corresponding to the newly added acquisition indexes under the condition that the acquirable indexes in the tracking point list can cover the newly added acquisition indexes;

and under the condition that the acquirable indexes in the tracking point list can not cover the newly-added acquisition indexes, determining eBPF acquisition program mounting points of the kernel probe types corresponding to the newly-added acquisition indexes.

When a certain acquisition index is newly added, whether the acquirable index in the tracking point Tracepoint list can cover the newly added acquisition index needs to be checked, if so, a corresponding Tracepoint type eBPF program mounting point in the Tracepoint list is selected, the newly added acquisition index is written into an eBPF control Map, and then a specified eBPF acquisition program is loaded to the selected Tracepoint type eBPF program mounting point; and if the collectable indexes in the tracking point Tracepoint list can not cover the newly added collection indexes, selecting eBPF collection program mounting points of the kprobe type, writing the newly added collection indexes into the eBPF control Map, and loading the appointed eBPF collection program to the selected eBPF collection program mounting points of the kprobe type.

Kprobe, kernel probe, supports the insertion of the eBPF program before executing any instructions. Tracepoint, a trace point, a static marker of kernel code, may be used to attach code to a running kernel. The Tracepoint-type eBPF program mount points are more stable than kprobes and do not change along with the change of kernel versions of the operating system, so that Tracepoint-type eBPF program mount points are preferentially selected, but the number of the mount points is relatively small; for the kprobe type mounting point, the operating system provides very rich mounting points, so that the kprobe type mounting point can be selected under the condition that the Tracepoint type eBPF program mounting point cannot realize the acquisition of the newly added acquisition index.

S303: and loading the target eBPF acquisition program at the eBPF acquisition program mounting point of the target type, and acquiring first target data corresponding to the newly added acquisition index in the network to be monitored by using the target eBPF acquisition program.

According to the technical scheme of the embodiment of the application, the type of the mounting point of the acquisition program and the type of the acquisition program can be selected independently based on the characteristics of the newly added acquisition index, and then the acquisition of the relevant data of the newly added acquisition index is realized by utilizing the selected type of the acquisition program at the mounting point of the selected acquisition program.

In the embodiment of the application, after the first target data corresponding to the acquisition index information included in the acquisition configuration information is acquired, the first target data or the data obtained by processing the first target data can be further stored and output, so that a user can monitor and analyze the operation condition of the network to be monitored based on the output data.

Fig. 4 is a schematic view of a process of storing and outputting collected data according to an embodiment of the present application, and as shown in fig. 4, a manner of storing and outputting the collected data is as follows:

s401: storing the first target data in a mapping of data types to eBPF.

In the embodiment of the application, the collected data is stored by using mapping of data types of eBPF, which is referred to as eBPF data Map for short.

In one implementation, a HASH table mapping BPF _ MAP _ TYPE _ HASH is adopted as a mapping of a data TYPE of the eBPF according to the embodiment of the present application, so as to implement a role of storing collected data.

In one embodiment, after acquiring the acquisition data corresponding to the acquisition index information in the acquisition configuration information, i.e., the first target data, in the network by using the eBPF acquisition program, the acquired acquisition data corresponding to the acquisition index information may be directly stored in the eBPF data Map.

In one embodiment, the persistence instructions may be generated periodically; for example, for the data stored in the eBPF data Map, the collected data in the eBPF data Map is subjected to a persistence operation every 1 hour with a period of 1 hour, and the collected data in the eBPF data Map is output to the database. The triggering mode for generating the persistence instruction in the embodiment of the present application is not specifically limited, and may be set by a user according to a requirement.

S402: storing the first target data stored in the map of data types of the eBPF into a database in response to a persistence instruction.

In one embodiment, the step S402 includes:

associating the first target data stored in the data type mapping of the eBPF with the platform data to obtain second target data under the condition that the acquisition configuration information comprises the platform data;

and storing the second target data into a database.

For example, if the acquisition configuration information includes platform data of k8s, it indicates that further association between the acquired data acquired by the eBPF acquisition program and the platform data of k8s is required, and by matching the platform data in the eBPF control Map and Internet Protocol address (IP) information in the acquired data, the acquired data and the platform data of k8s are associated, and the associated data is stored in the database.

In the embodiment of the application, after the acquired data is associated with the k8s platform data, the obtained associated data is firstly stored in the data Map of the eBPF, and then the associated data stored in the data Map of the eBPF is output to the database; or after the acquired data is associated with the platform data of k8s, the associated data obtained by direct speaking can be stored in the database.

In the embodiment of the application, after the collected data corresponding to the collected index information is stored in the eBPF data Map, or the information obtained by correlating the collected data with the platform data of k8s is stored in the eBPF data Map, the data in the eBPF data Map is further output to the database, so that a user can conveniently analyze the operation condition based on the output data network.

In one embodiment, before outputting the data in the eBPF data Map to the database, the data in the eBPF data Map may be further processed, such as format conversion, conversion of the collected hexadecimal port into decimal, conversion of the IP address into a specific format, and the like, and then the processed data is output to the database.

In the embodiment of the application, the data stored in the eBPF data Map is stored in the database, so that the aim of performing persistent storage on the data in the eBPF data Map can be fulfilled.

According to the technical scheme, the eBPF data Map is used for storing the acquired data corresponding to the acquisition index information in the network to be monitored, so that the network data in the network to be monitored can be acquired and stored as required, the data which the user wants to acquire are finally acquired and stored, and the user can conveniently monitor and analyze the acquired data in the network to be monitored subsequently.

The embodiment of the application provides a data acquisition framework, which can be applied to a cloud native network and solves the problems of strong resource dynamic property, more acquisition indexes and high index acquisition overhead of the cloud native network. The embodiment of the application supports the acquisition of indexes according to requirements, the self-adaptive selection of eBPF program types, the self-selection of mounting points, the dynamic sensing configuration change and the multi-source (virtual machine, container and physical machine) data acquisition when the data in the network to be monitored is acquired, and has the characteristics of flexibility, expandability and low overhead.

Fig. 5 is a schematic diagram of a data acquisition framework provided in an embodiment of the present application, where method steps of the embodiments in fig. 1 to fig. 4 in the present application may be implemented based on the data acquisition framework described in fig. 5. The data acquisition framework described in fig. 5 is described below.

The data collection framework shown in fig. 5 is specifically a flexible and extensible data collection framework implemented by eBPF, and as shown in fig. 5, the data collection framework is composed of the following modules: the system comprises a collection module 501, an acquisition module 502, a management module 503 and an output module 504.

The collection module 501: the management module 503 is responsible for receiving the user configuration information of the management module 503 and obtaining the acquisition configuration information according to the user configuration information; automatically selecting the eBPF acquisition program type according to the acquisition configuration information; the eBPF acquisition module is responsible for interacting with the acquisition module 502, loading an eBPF acquisition program in the acquisition module 502 to a kernel, and communicating with the acquisition module 502 through an eBPF Map (including an eBPF control Map and an eBPF data Map); the eBPF of the aggregation conversion acquisition module 502 acquires data corresponding to the acquisition index acquired by the acquisition program and integrates the data with the corresponding flow information.

The data corresponding to the acquisition index acquired by the eBPF acquisition program of the aggregation conversion acquisition module 502 refers to processing such as performing format conversion on the acquired data corresponding to the acquisition index, converting the acquired hexadecimal port into decimal, converting the IP address into a specific format, and the like; the integration with the corresponding flow information means that the acquired data corresponding to the acquired acquisition index is associated with platform data of the target platform, such as platform data of k8 s.

The acquisition module 502: and the monitoring system is responsible for the collection work of data in the network to be monitored.

The management module 503: the system is responsible for collecting user configuration information such as collection indexes, collection periods and the like; the system is responsible for acquiring index information related to Kubernets (k 8 s), such as Pod information, node information and the like; and is responsible for communicating with the collection module 501, and sending the user configuration information and the k8s information to the collection module 501 for updating the monitoring policy.

The output module 504: and is responsible for collecting data from the collection module 501 or receiving data sent by the collection module 501, and storing the data in a database for subsequent display.

In the embodiment of the present application, the eBPF Map is divided into an eBPF control Map and an eBPF data Map. The eBPF control Map is used for transmitting acquisition configuration information from the acquisition module 501 to the acquisition module 502; the eBPF data Map is used to store data corresponding to the acquisition configuration information acquired by the acquisition module 502.

Through the data acquisition framework shown in fig. 5, the eBPF control Map is used to store the acquisition configuration information, the acquisition configuration information stored in the eBPF control Map is further read by the eBPF acquisition program, so as to acquire the data related to the acquisition index in the network to be monitored, and the acquisition of the data related to the acquisition index in the network to be monitored can be dynamically performed according to the acquisition configuration information without restarting the acquisition program. Under the condition that the acquisition configuration information is updated, the acquisition configuration information stored in the eBPF control Map is read by utilizing the eBPF program, the acquisition of the relevant data of the acquisition index in the network to be monitored is realized based on the updated acquisition configuration information, and the monitoring configuration update can be dynamically sensed on the premise of not restarting the acquisition program.

Fig. 6 is a workflow of each module in the data collection framework according to an embodiment of the present application, where the workflow includes:

s601: user configuration information is sent to a management module;

s602: the management module analyzes the user configuration information and sends the user configuration information to the collection module;

s603: the collection module autonomously selects an eBPF collection program type according to collection requirements;

s604: the collection module writes the collected configuration information into the eBPF control Map, and loads a specified eBPF collection program to a corresponding hook point;

s605: the acquisition module reads the information of the eBPF control Map, filters the acquired data and reports the data to the eBPF data Map;

s606: the collection module reads data in the eBPF data Map, and reports the data to the output module after processing;

s607: the output module writes the data into the database.

In the embodiment of the application, a user issues monitoring configuration according to own requirements; the management module analyzes the user configuration and sends the configuration information to the collection module; the collection module autonomously selects an eBPF program type according to the collection requirement, simultaneously writes the collection configuration information into an eBPF control Map of the collection program, and loads a specified eBPF program to a corresponding hook point; the acquisition program reads the information in the control Map, filters the acquired data and reports the filtered data to the data Map; the collection module reads data from the eBPF data Map, and reports the data to the output module after processing; and the output module finally writes the data into a database for subsequent analysis and display.

The steps performed by the modules in the data acquisition framework described in fig. 5 with reference to fig. 7 to 12 are as follows:

fig. 7 is a schematic view of a workflow of a management module according to an embodiment of the present application, and as shown in fig. 7, the workflow of the management module is as follows:

s701: acquiring user configuration information issued by a user;

s702: analyzing the user configuration information;

s703: judging whether k8s information needs to be pulled or not; if yes, executing step S704, if no, executing step S705;

s704: acquiring k8s information through a client-go interface;

s705: and sending the analyzed user configuration information to a collection module.

In the embodiment of the present application, the management module is responsible for acquiring user configuration information issued by an analysis user, where the user configuration information includes: adding acquisition indexes (or adding a certain host), updating acquisition frequency (period), deleting acquisition indexes and the like. After the management module analyzes the user configuration information, if the user in the analyzed user configuration information needs the platform data of k8s, the platform data of k8s is pulled to the API server through an interface provided by the client-go; and finally, the management module issues the analyzed configuration information to the collection module.

Fig. 8 to 11 are schematic diagrams of the working flows of the collection module, where the collection module is responsible for receiving the analyzed collection configuration information sent by the management module, and adopts different processing flows according to different types of the collection configuration information.

Fig. 8 is a schematic view of a workflow of a collection module according to an embodiment of the present application, and fig. 8 is a workflow of the collection module in a case that the acquired configuration information includes new configuration information. As shown in fig. 8, the working flow of the collection module is as follows:

s801: receiving acquisition configuration information issued by a management module;

s802: judging that newly added configuration information exists in the acquired configuration information;

s803: judging whether a tracepoint type mounting point can be adopted or not; if yes, go to step 804, if no, go to step 805;

s804: selecting eBPF program hanging points of corresponding tracepoint types;

s805: selecting an eBPF program hanging point of a corresponding kprobe type;

s806: and writing the acquisition configuration information into the eBPF control Map, and loading the specified eBPF program to the corresponding hook point.

In the embodiment of the application, when the collecting module determines that the collecting configuration information includes a newly added certain collecting index, the collecting module checks whether the collectable index in the tracepoint list can cover the newly added collecting index according to the information of the newly added collecting index, if yes, selects the eBPF program hanging point of the corresponding tracepoint type, writes the collecting configuration information into the eBPF control Map, and loads the appointed eBPF collecting program to the selected eBPF program hanging point of the tracepoint type; and if the collectable indexes in the tracepoint list cannot cover the newly added current collecting indexes, selecting a program mounting point of a corresponding kprobe type, writing the collecting configuration information into the eBPF control Map, and loading the appointed eBPF collecting program to the selected program mounting point of the kprobe type.

Fig. 9 is a schematic view of a workflow of a collection module according to an embodiment of the present application, and fig. 9 is a workflow of the collection module in a case that the collected configuration information includes configuration information in which a parameter is updated. As shown in fig. 9, the workflow of the collection module is as follows:

s901: receiving acquisition configuration information issued by a management module;

s902: judging that configuration information with updated parameters exists in the acquired configuration information;

s903: and writing the updated acquisition configuration information into the eBPF control Map.

In this embodiment of the application, when the collection module determines that the collection configuration information includes a parameter for updating a certain collection index, for example, the collection frequency or the collection period of the certain collection index is updated, the collection module directly updates the parameter of the collection index in the corresponding collection configuration information of the eBPF control Map.

Fig. 10 is a third schematic view of a workflow of a collection module according to an embodiment of the present application, and fig. 10 is a workflow of the collection module in a case where the collected configuration information includes the deleted configuration information. As shown in fig. 10, the working flow of the collection module is as follows:

s1001: receiving acquisition configuration information issued by a management module;

s1002: judging that the deleted configuration information exists in the acquired configuration information;

s1003, carrying out: and writing the configuration information needing to be deleted into the eBPF control Map.

In the embodiment of the application, when the collection module determines that the collection configuration information includes a collection index deleted, the collection module directly deletes the corresponding collection index in the collection configuration information in the eBPF control Map.

Fig. 11 is a schematic view of a work flow of a collection module provided in the embodiment of the present application, as shown in fig. 11, the collection module is responsible for processing data collected by the eBPF collection module in addition to performing management of collection configuration information in fig. 8 to 10, and a specific processing flow includes:

s1101: reading data in the eBPF data Map;

s1102: judging whether the data in the eBPF data Map needs to be associated with k8s information or not; if the association is needed, executing S1103, otherwise, executing S1104;

s1103: correlating the k8s information through the IP information;

s1104: and reporting the data to an output module.

In the embodiment of the application, if the acquisition configuration information received by the collection module from the management module contains k8s platform data, it indicates that further association needs to be performed on the data acquired by the acquisition program, the acquisition data is associated with the k8s information by matching the acquisition configuration information with the IP information in the acquisition data, the associated information is stored in the eBPF data Map, and the subsequent associated data is reported to the output module.

Fig. 12 is a schematic flowchart of a working process of an acquisition module according to an embodiment of the present application. As shown in fig. 12, the working flow of the acquisition module is as follows:

s1201: reading acquisition configuration information in the eBPF control Map;

s1202: acquiring data according to the acquisition configuration information; or filtering the acquired data according to the acquisition configuration information in the eBPF control Map;

s1203: and reporting the collected data to the eBPF data Map.

In the embodiment of the application, the acquisition module reads acquisition configuration information in the control Map by using an acquisition program, filters flow data which does not need to be reported in the acquired data, and reports the filtered data to the eBPF data Map for the subsequent processing of the acquisition module.

Fig. 13 is a schematic flowchart of a work flow of an output module according to an embodiment of the present application. As shown in fig. 13, the work flow of the output module is as follows:

s1301: reading data in the eBPF data Map;

s1302: and storing the data in the eBPF data Map into a database.

In the embodiment of the application, the output module is responsible for reading the data in the eBPF data Map of the collection module and writing the data into the database; or, the data collection module is responsible for writing the data reported by the collection module into a database for subsequent analysis and display.

In the embodiment of the application, by providing the data acquisition frame shown in fig. 5, the data acquisition frame is specifically an eBPF-based data acquisition frame, and by using cooperative work among modules in the data acquisition frame, acquisition indexes in a network to be monitored can be acquired as required, a mount point of an acquisition program can be selected autonomously when data acquisition is performed, and Map can be controlled by the eBPF to realize dynamic sensing when acquisition configuration information is changed. The data acquisition of various indexes of a virtual machine, a container and a physical machine in a network to be monitored is realized. The data acquisition method realized by using the data acquisition framework has the characteristics of flexibility, expandability and low cost, and can solve the problems of strong resource dynamics, multiple acquisition indexes and high data acquisition cost in the network to be monitored.

Fig. 14 is a schematic structural component diagram of a data acquisition system provided in an embodiment of the present application, and as shown in fig. 14, the data acquisition system 1400 includes:

a reading module 1401, configured to, in response to a data acquisition instruction for a network to be monitored, read acquisition configuration information stored in a mapping of a control type of an extended burley packet filter eBPF based on identification information of the network to be monitored; acquiring configuration information of a network to be monitored, wherein the acquiring configuration information comprises acquiring index information of the network to be monitored;

an obtaining module 1402, configured to obtain first target data corresponding to the collected index information in the network to be monitored.

In some embodiments, in a case that the acquisition indicator information includes a newly added acquisition indicator, the data acquisition system 1400 further includes:

the determining module is used for determining eBPF acquisition program mounting points of the target types corresponding to the newly added acquisition indexes and target eBPF acquisition programs;

the obtaining module 1402 is specifically configured to: and loading the target eBPF acquisition program at the eBPF acquisition program mounting point of the target type, and acquiring first target data corresponding to the newly added acquisition index in the network to be monitored by using the target eBPF acquisition program.

In some embodiments, the determining module is specifically configured to: determining whether the collectable indexes in the tracking point list can cover the newly added collecting indexes; determining eBPF acquisition program mounting points of tracking point types corresponding to the newly added acquisition indexes under the condition that the acquirable indexes in the tracking point list can cover the newly added acquisition indexes; and under the condition that the acquirable indexes in the tracking point list can not cover the newly-added acquisition indexes, determining eBPF acquisition program mounting points of the kernel probe types corresponding to the newly-added acquisition indexes.

In some embodiments, the data acquisition system 1400 further comprises:

the analysis module is used for acquiring user configuration information and analyzing the user configuration information to acquire acquisition index information of the network to be monitored and index information of a target platform;

and the updating module is used for updating the mapping of the control type of the eBPF based on the acquisition index information of the network to be monitored.

In some embodiments, the acquisition configuration information further includes platform data of a target platform, and the data acquisition system 1400 further includes:

the first storage module is used for acquiring platform data corresponding to the index information of the target platform from a target component by using an interface provided by a client library of the target platform, and storing the platform data into the mapping of the control type of the eBPF.

In some embodiments, the acquisition indicator information includes at least one of: adding acquisition indexes, updating acquisition parameters and deleting acquisition indexes; the acquisition parameters include at least one of: collecting frequency, collecting period, collecting times, data collecting length and collecting time;

the update module is specifically configured to: under the condition that the acquisition index information comprises the newly added acquisition index, storing the newly added acquisition index into the mapping of the control type of the eBPF; updating the acquisition parameters of the acquisition indexes corresponding to the updated acquisition parameters in the mapping of the control type of the eBPF under the condition that the updated acquisition parameters are included in the acquisition index information; deleting the deleted acquisition indicator in the mapping of the control type of the eBPF under the condition that the acquisition indicator information comprises the deleted acquisition indicator.

In some embodiments, the data acquisition system 1400 further comprises:

a second storage module for storing the first target data into a mapping of data types of the eBPF;

a third storage module, configured to store the first target data stored in the mapping of the data type of the eBPF in a database in response to a persistence instruction.

In some embodiments, the third storage module is specifically configured to: associating the first target data stored in the mapping of the data type of the eBPF with the platform data to obtain second target data under the condition that the acquisition configuration information comprises the platform data; and storing the second target data into a database.

Those skilled in the art will appreciate that the functions implemented by the various modules in the data acquisition system 1400 shown in fig. 14 can be understood with reference to the foregoing description of the data acquisition method. The functions of the modules in the data acquisition system 1400 shown in fig. 14 may be implemented by a program running on a processor, or may be implemented by specific logic circuits.

The embodiment of the application further provides data acquisition equipment. Fig. 15 is a schematic diagram of a hardware structure of a data acquisition device 1500 according to an embodiment of the present application, and as shown in fig. 15, the data acquisition device 1500 includes: a communication component 1503 for data transfer, at least one processor 1501 and a memory 1502 for storing computer programs capable of running on the processor 1501. The various components in the terminal are coupled together by a bus system 1504. It is understood that the bus system 1504 is used to enable connected communication between these components. The bus system 1504 includes, in addition to the data bus, a power bus, a control bus, and a status signal bus. For clarity of illustration, however, the various buses are designated as bus system 1504 in fig. 15.

Wherein the processor 1501 executes the computer program to perform at least the steps of the methods shown in fig. 1 to 4 and 5 to 13.

It will be appreciated that the memory 1502 can be either volatile memory or nonvolatile memory, or can include both volatile and nonvolatile memory. Among them, the nonvolatile Memory may be a Read Only Memory (ROM), a Programmable Read Only Memory (PROM), an Erasable Programmable Read-Only Memory (EPROM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), a magnetic random access Memory (FRAM), a Flash Memory (Flash Memory), a magnetic surface Memory, an optical Disc, or a Compact Disc Read-Only Memory (CD-ROM); the magnetic surface storage may be disk storage or tape storage. Volatile Memory can be Random Access Memory (RAM), which acts as external cache Memory. By way of illustration and not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), synchronous Static Random Access Memory (SSRAM), dynamic Random Access Memory (DRAM), synchronous Dynamic Random Access Memory (SDRAM), double Data Rate Synchronous Dynamic Random Access Memory (DDRSDRAM), enhanced Synchronous Dynamic Random Access Memory (ESDRAM), enhanced Synchronous Dynamic Random Access Memory (Enhanced DRAM), synchronous Dynamic Random Access Memory (SLDRAM), direct Memory (DRmb Access), and Random Access Memory (DRAM). The memory 1502 described in embodiments herein is intended to comprise, without being limited to, these and any other suitable types of memory.

The method disclosed in the embodiments of the present application described above may be implemented in the processor 1501 or implemented by the processor 1501. The processor 1501 may be an integrated circuit chip having signal processing capabilities. In implementation, the steps of the above method may be performed by integrated logic circuits of hardware or instructions in the form of software in the processor 1501. The processor 1501 described above may be a general purpose processor, DSP, or other programmable logic device, discrete gate or transistor logic device, discrete hardware component, or the like. Processor 1501 may implement or perform the methods, steps, and logic blocks disclosed in the embodiments of the present application. The general purpose processor may be a microprocessor or any conventional processor or the like. The steps of the method disclosed in the embodiments of the present application may be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software modules may be located in a storage medium located in the memory 1502 and the processor 1501 reads the information in the memory 1502 and in conjunction with its hardware performs the steps of the method described previously.

In an exemplary embodiment, the data collection Device 1500 may be implemented by one or more Application Specific Integrated Circuits (ASICs), DSPs, programmable Logic Devices (PLDs), complex Programmable Logic Devices (CPLDs), FPGAs, general purpose processors, controllers, MCUs, microprocessors (microprocessors), or other electronic components for performing the aforementioned call recording methods.

An embodiment of the present application further provides a computer-readable storage medium, on which a computer program is stored, where the computer program is configured to, when executed by a processor, perform at least the steps of the methods shown in fig. 1 to 4 and fig. 5 to 13. The computer readable storage medium may be specifically a memory. The memory may be the memory 1502 as shown in fig. 15.

The technical solutions described in the embodiments of the present application may be arbitrarily combined without conflict.

In the several embodiments provided in the present application, it should be understood that the disclosed method and intelligent device may be implemented in other ways. The above-described device embodiments are merely illustrative, for example, the division of the unit is only a logical functional division, and there may be other division ways in actual implementation, such as: multiple units or components may be combined, or may be integrated into another system, or some features may be omitted, or not implemented. In addition, the coupling, direct coupling or communication connection between the components shown or discussed may be through some interfaces, and the indirect coupling or communication connection between the devices or units may be electrical, mechanical or in other forms.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, that is, may be located in one place, or may be distributed on a plurality of network units; some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, all functional units in the embodiments of the present application may be integrated into one second processing unit, or each unit may be separately regarded as one unit, or two or more units may be integrated into one unit; the integrated unit can be realized in a form of hardware, or in a form of hardware plus a software functional unit.

The above description is only for the specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily think of the changes or substitutions within the technical scope of the present application, and shall be covered by the scope of the present application.

Claims

1. A method of data acquisition, the method comprising:

2. The method according to claim 1, wherein in a case that the acquisition indicator information includes a newly added acquisition indicator, before the acquiring first target data corresponding to the acquisition indicator information in the network to be monitored, the method further includes:

determining an eBPF acquisition program mounting point of a target type corresponding to the newly added acquisition index and a target eBPF acquisition program;

the acquiring of the first target data corresponding to the acquisition index information in the network to be monitored includes:

and loading the target eBPF acquisition program at the eBPF acquisition program mounting point of the target type, and acquiring first target data corresponding to the newly added acquisition index in the network to be monitored by using the target eBPF acquisition program.

3. The method of claim 2, wherein the determining the eBPF acquisition procedure mount point of the target type corresponding to the newly added acquisition indicator comprises:

determining eBPF acquisition program mounting points of tracking point types corresponding to the newly added acquisition indexes under the condition that the acquirable indexes in the tracking point list can cover the newly added acquisition indexes;

and under the condition that the collectable indexes in the tracking point list can not cover the newly-added collection indexes, determining eBPF collection program mounting points of the kernel probe types corresponding to the newly-added collection indexes.

4. The method according to claim 1, wherein prior to reading the acquisition configuration information stored in the map of control types of eBPF based on the identification information of the network to be monitored, the method further comprises:

acquiring user configuration information, and analyzing the user configuration information to acquire acquisition index information of the network to be monitored and index information of a target platform;

and updating the mapping of the control type of the eBPF based on the acquisition index information of the network to be monitored.

5. The method of claim 4, wherein the collection configuration information further includes platform data of a target platform, and wherein the method further comprises:

and acquiring platform data corresponding to the index information of the target platform from a target assembly by using an interface provided by a client library of the target platform, and storing the platform data in the mapping of the control type of the eBPF.

6. The method of claim 4 or 5, wherein the collecting indicator information comprises at least one of: adding acquisition indexes, updating acquisition parameters and deleting acquisition indexes; the acquisition parameters include at least one of: collecting frequency, collecting period, collecting times, data collecting length and collecting time;

the updating of the mapping of the control type of the eBPF based on the acquisition index information of the network to be monitored comprises:

deleting the deleted acquisition indicator in the map of the control type of the eBPF if the acquisition indicator information includes the deleted acquisition indicator.

7. The method according to any one of claims 1 to 5, further comprising:

storing the first target data into a mapping of data types of eBPF;

storing the first target data stored in the map of data types of the eBPF in a database in response to a persistence instruction.

8. The method of claim 7, wherein storing the first target data stored in the map of data types of the eBPF into a database comprises:

associating the first target data stored in the mapping of the data type of the eBPF with the platform data to obtain second target data under the condition that the acquisition configuration information comprises the platform data;

and storing the second target data into a database.

9. A data acquisition system, characterized in that the data acquisition system comprises:

10. A data acquisition device, characterized in that the data acquisition device comprises: a memory having computer-executable instructions stored thereon and a processor operable to implement the method of any one of claims 1 to 8 when executing the computer-executable instructions on the memory.

11. A computer storage medium having stored thereon executable instructions which, when executed by a processor, carry out the method of any one of claims 1 to 8.