Cloud network data packet collection method and system for resource domain and observation domain

Abstract

The present invention provides a method and system for collecting cloud network data packets in a resource domain and an observation domain, which relates to the field of network communication technologies and includes: Resource domain steps: including resource_domain_id and resource_point_id; wherein, the resource to be collected is identified by resource_domain_id, and a certain physical network card or virtual network card on the resource is identified by resource_point_id; Observation domain steps: including observation_domain_id and observation_point_id; wherein, each collector Agent is identified by observation_domain_id, and each network card to be collected is identified by observation_point_id when the Agent collects multiple network cards. The present invention can solve the problem of data packet collection in a cloud environment, provide metadata for network data packets, balance the computing overhead and network overhead, support a wide range of application scenarios, and increase the actual usage scope.

Description

Technical Field

[0001] The present invention relates to the field of network communication technologies, and in particular, to a method and system for collecting cloud network data packets in a resource domain and an observation domain. Background Art

[0002] Network data packet collection has always been an important technical method for systems such as network performance management (NPM) and network security (Security). In traditional networks, data packet collection is achieved by mirroring network traffic to a collection device through a switch mirror or a TAP device, and then the collection device captures the packets. This method depends on the support of hardware devices and the network cable connection between the mirror device and the collection device.

[0003] With the rise of cloud computing technologies, SDN networks and Kubernetes (K8s) container networks are increasingly widely used. In these new cloud network environments, the traditional method can only collect cross-host network traffic passing through switches and cannot collect network traffic within a host. However, the network traffic within a host includes network communications between virtual machines (VMs) and between containers within the host, which is actually important cloud network traffic. At the same time, because systems such as SDN and K8s widely adopt network address translation technology (NTA), the traffic collected on switches loses the service address information and often cannot truly reflect the communication situation of actual services. Therefore, in the cloud network era, the Agent collection technology for network data packets is adopted. This technology actually moves the mirroring point forward from the switch to the location where data needs to be collected, such as within a host, within a VM, within a K8s Node, within a K8s pod, within a container, etc. The implementation method is to deploy a software Agent at the forward mirroring location, use packet capture technology to collect data traffic of network cards (including physical network cards and virtual network cards), and then encapsulate it and send it to a collection device for storage and / or analysis and processing. However, the current cloud network data packet Agent collection method has the following defects:

[0004] 1) Lack of metadata. Network data cannot be associated with the resource system, let alone the business system, resulting in few application scenarios. The resource system (resourcesystem) refers to physical machines, virtual machines, containers, etc. that run software. The business system (businessystem) refers to the software system that completes business functions. In addition to the business system, there are also auxiliary software systems such as cloud systems, management systems, and monitoring systems that support the business system. In traditional networks, since they are all physically connected, network addresses can be directly mapped to the physical resource system or directly to the business system running on the physical resource system. Therefore, after collecting network data packets, correlation and analysis can reflect the operating conditions of the resource system and the business system, with a wide range of application scenarios. In the cloud network environment, generally, the lower-layer network (underlay) carries the upper-layer network (overlay). Moreover, there are multiple levels of carrying methods. For example, the physical network carries the VM network, and the VM network then carries the Container network. Among them, only the network address of the bottom-layer physical network is fixed, and the traditional method can continue to be used to associate it with the physical system resources. In the upper-layer networks (VM network and Container network), the mapping relationship between the address and the resource system and the mapping relationship between the address and the business system are both non-fixed and dynamically adjusted. These information are maintained in the control components of the relevant cloud network and are called "metadata" in the collection system. Therefore, due to the lack of metadata, the actual application scenarios of the data collected by the current method are greatly reduced.

[0005] 2) The contradiction between computing overhead and network overhead, with a small scope of use. In the traditional method, network traffic is mirrored by hardware, and then additional collection devices are used for collection and analysis. Therefore, there is no additional overhead on the resource system that generates data. Moreover, the mirrored traffic is directly output to the collection device through an additional network cable, and there is no additional network overhead on the network being collected. However, the Agent method needs to be deployed in the system being collected, thus bringing computing overhead and network overhead to the system being collected. If the data packets are directly exported, the computing overhead is small, but the network overhead is too large, equivalent to doubling the traffic. If the data packets are filtered, compressed, or directly analyzed to calculate statistical index data, then the amount of data transmitted decreases, but the computing overhead increases significantly, affecting the available resources of the software running on the system being collected and bringing stability risks. Therefore, the current collection method is only suitable for use in systems with abundant computing resources and network resources, and the actual scope of use is small.

[0006] There are several problems in directly querying the business through the network address in the data packet, which are described as follows:

[0007] 1) Inefficiency. Firstly, since most cloud services adopt small services or microservice architectures and ensure availability and processing performance through a large number of horizontal expansions. Therefore, there are far more network addresses in the cloud network system than in traditional systems, and directly querying by address is inefficient.

[0008] 2) Timeliness issue. In addition, network addresses are often dynamically allocated and continuously adjusted. Even in the metadata of the cloud controller, only the current address is available, and there is no invalid address. However, network data packets often have a time span, and it is very likely to encounter the problem of invalid addresses.

[0009] 3) Difficulty in distinguishing capture locations. As mentioned above, there are multi-level carrier networks in the cloud network, and the mirror location (i.e., the collection location) can be within the host, within the VM, within the K8s Node, within the K8s pod, within the Container, etc. Packets collected at different collection locations contain different levels. At the same time, due to technologies such as NAT, the addresses representing the same-level network may be the same or different. At this time, relying entirely on the network addresses in the data packets to distinguish capture locations is either impossible or too complex. In cloud network analysis, distinguishing the capture point location, and thus distinguishing which level of network the collected traffic belongs to, through correlation analysis, helps to provide visibility of data flow and assist in analyzing network faults. Summary of the Invention

[0010] In view of the deficiencies in the prior art, the present invention provides a method and system for collecting cloud network data packets in a resource domain and an observation domain to solve the problem of data packet collection in a cloud environment, provide metadata for network data packets, balance computing overhead and network overhead, support a wide range of application scenarios, and increase the actual usage scope.

[0011] According to a method and system for collecting cloud network data packets in a resource domain and an observation domain provided by the present invention, the solution is as follows:

[0012] In a first aspect, a method for collecting cloud network data packets in a resource domain and an observation domain is provided, and the method includes:

[0013] Resource domain steps: including resource_domain_id and resource_point_id; wherein, the resource to be collected is identified by resource_domain_id, and a certain physical network card or virtual network card on the resource is identified by resource_point_id;

[0014] Observation domain steps: include observation_domain_id and observation_point_id; among them, each collector Agent is identified by observation_domain_id, and each network card to be collected is identified by observation_point_id when the Agent collects multiple network cards.

[0015] Preferably, the Agent registers itself with the management module Manager, and then periodically accesses Manager. During the process of the Agent registering itself with Manager, the Agent reports its local information; Manager processes the registration event and allocates observation information and configuration, and the execution steps are as follows:

[0016] Step S1: Input the network address and NIC list reported by the Agent;

[0017] Step S2: Use the cloud api to query the resource information and related meta data corresponding to the Agent network address;

[0018] Step S3: Determine the network cards to be collected according to the collection requirements;

[0019] Step S4: Allocate the corresponding observation_domain_id and observation_point_id;

[0020] Step S5: Update and cache the mapping relationship between resource and observation;

[0021] Step S6: Send the work configuration and observation information to the Agent.

[0022] Preferably, step S5 includes: for the Agent, establish a two-way mapping relationship between the resource information in step S2 and the observation information in step S4, and update it to the global cache.

[0023] Preferably, the use of the two-way mapping query includes:

[0024] Query observation from resource, mainly used in Manager for UI query and configuration of Agent and Gateway;

[0025] Query resource from observation, provided to the Consumer through the api of Manager, that is, the metadata function of Manager

[0026] In a second aspect, a cloud network data packet collection system for a resource domain and an observation domain is provided. The system includes:

[0027] Probe module Agent: Collects raw data packets and sends the raw data packets to Gateway.

[0028] Gateway module Gateway: Receives the raw data packets collected by Agent, performs analysis and processing, and then forwards the raw data packets and / or analysis results to Consumer.

[0029] Consumer module Consumer: Consumes the network data or analysis data of Gateway.

[0030] Management module Manager: Connects Agent, Gateway, and Consumer, and provides two types of functions, management and metadata, through AIP.

[0031] Preferably, the Gateway module Gateway is close to Agent according to the actual situation to balance the computing overhead and network overhead, and is widely used in cloud networks under various load conditions.

[0032] Preferably, the management functions in the Management module Manager include:

[0033] For Agent and Gateway, Manager can issue configuration parameters, control startup and shutdown, collect and display status, and play the role of managing services.

[0034] For Consumer, it has its own management method and does not require the management functions of Manager.

[0035] Preferably, the metadata in the Management module Manager includes: Manager obtains the metadata contained therein by docking various cloud controllers; Agent, Gateway, and Consumer can all query the metadata through Manager, so as to associate the collected cloud network data packets with the resource system and business system, supporting multiple application scenarios.

[0036] In a third aspect, a computer-readable storage medium storing a computer program is provided. When the computer program is executed by a processor, the steps in the cloud network data packet collection method for the resource domain and the observation domain are implemented.

[0037] In a fourth aspect, an electronic device is provided, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the computer program is executed by the processor, the steps in the cloud network data packet collection method for the resource domain and the observation domain are implemented.

[0038] Compared with the prior art, the present invention has the following beneficial effects:

[0039] 1) By adopting the mapping structure of resource domain information and observation domain information, the metadata problem of data packets is solved. Also, since the query is reduced from network address query to query within the observation domain, the size of the query space is significantly reduced, solving the efficiency problem, enabling the data packets collected in the cloud network environment to be associated with the resource system and the service system in a wide range of scenarios;

[0040] 2) By adopting the separated design of the Agent collection function and the Gateway analysis and transfer function, and the design of deploying the Agent and the Gateway nearby within the cloud, the contradiction between computing overhead and network overhead is solved, and the computing overhead and network overhead can be effectively balanced, thus being widely used in cloud networks with various load conditions.

[0041] Other beneficial effects of the present invention will be elaborated through the introduction of specific technical features and technical solutions in the specific implementation manner. Those skilled in the art should be able to understand the beneficial technical effects brought by the said technical features and technical solutions through these introductions. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] By reading the detailed description of the non-restrictive embodiments with reference to the following drawings, other features, objectives and advantages of the present invention will become more obvious:

[0043] Figure 1 It is a schematic diagram of the modules of the present invention;

[0044] Figure 2 It is the execution steps for the Manager module of the present invention to process Agent registration;

[0045] Figure 3 It is the core data structure diagram of the modules of the present invention;

[0046] Figure 4 It is the schematic diagram of the actual deployment of the modules of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0047] The present invention will be described in detail below with reference to specific embodiments. The following embodiments will help those skilled in the art to further understand the present invention, but do not limit the present invention in any form. It should be noted that those of ordinary skill in the art can make several changes and improvements without departing from the concept of the present invention. These all fall within the protection scope of the present invention.

[0048] An embodiment of the present invention provides a cloud network data packet collection system for a resource domain and an observation domain. Referring to Figure 1 as shown, the system specifically includes the following:

[0049] Probe Module Agent: Collects raw data packets and sends the raw data packets to the Gateway. Agent is deployed within the cloud, such as within a host, within a VM, within a Node of K8s, within a pod of K8s, within a Container, etc. Using packet capture technology, it collects the data traffic of network cards (including physical network cards and virtual network cards). Packet capture technologies include Lipbcap, BPF, DPDK, etc. Encapsulation technologies include using tunnel network technologies such as GRE, VxLAN, or using socket communication technologies based on TCP / UDP. When resource overhead permits, Agent can enable the filtering collection filtering function and the transmission compression function as optimization methods. However, in this invention, the analysis and statistics functions are not directly enabled on Agent, but are transferred to the Gateway, thus simplifying the implementation of Agent and reducing the failure risk.

[0050] Gateway Module Gateway: Receives the raw data packets collected by Agent, conducts analysis and processing, and then forwards the raw data packets and / or analysis results to the Consumer. Gateway is also deployed within the cloud. However, different from Agent which is directly deployed on the same resource system as the business system, Gateway can plan and allocate additional resources for deployment, thus not affecting the computing resources of the system being collected. Therefore, Gateway can perform much more complex analysis and processing than Agent, such as network flow analysis, protocol decoding, metric analysis and statistics, etc. At the same time, in the cloud network, the more the network traffic is restricted within a local switch, the less impact on the whole, and the more "cost-effective"; the more network switching devices are crossed, the greater the impact on the overall response, and the more "expensive"; the cloud-on-cloud network is the most "expensive network resource". Therefore, Gateway can be as close to Agent as possible according to the actual situation to reduce the network devices that the traffic collected by Agent needs to pass through to reach Gateway, significantly reducing the impact on the network. For example, if deployed within the same server, the collected traffic is restricted within the server network card; if deployed within the same cabinet, the collected traffic is restricted within the top-of-rack switch (TOR); if deployed within the same row of cabinets, the collected traffic is restricted within the row switch; if deployed within the same cloud, it is restricted within the cloud switch. Therefore, through the near-cloud deployment of Gateway, the computing overhead and network overhead can be balanced and it is widely used in cloud networks under various load conditions.

[0051] Consumer: Consumes Gateway network data or analyzes data. Typical Consumers include NPM (Network Performance Management) systems, Security (network security) systems, BPC (Business Performance Center) systems, network traffic analysis systems, AIOps systems, big data platform systems, etc. Consumers can be deployed either on the cloud or off the cloud according to the actual system characteristics. For example, NPM, Security, etc. are hardware devices and can only be deployed off the cloud. BPC, network traffic analysis, AIOps, and big data platforms can be deployed as software and can be deployed on the cloud, but are generally planned on different clouds. For example, the business systems to be collected are on the business cloud, while BPC, network traffic analysis, and AIOps are all deployed on the operation / management cloud, and the big data platform generally builds a separate cloud. Therefore, the network between the Gateway and the Consumer is generally "expensive".

[0052] Manager: Connects Agents, Gateways, and Consumers and provides two types of functions, management and metadata, through AIP. Explanation is as follows:

[0053] 1) Management function. For Agents and Gateways, the Manager can issue configuration parameters, control start and stop, collect and display status, serving as a management service. For Consumers, they generally have their own management methods and do not require the management function of the Manager.

[0054] 2) Metadata. The Manager obtains the metadata contained therein by docking with various cloud controllers. The metadata includes the services (or businesses) running on each resource, the types of each resource (containers, VMs, physical machines, etc.), the subordinate relationships of each resource (belonging to which server, rack, row, ZONE, etc.), the subordinate relationships between the in-cloud addresses and external service addresses of each service, the labels of each service, etc. Agents, Gateways, and Consumers can all query the metadata through the Manager, thereby associating the collected cloud network data packets with the resource system and the business system, thus supporting a wide range of application scenarios.

[0055] The present invention also provides a method for collecting cloud network data packets in a resource domain and an observation domain, which uses the method of mapping the resource domain and the observation domain to efficiently provide metadata information. Explanation is as follows:

[0056] Resource domain, which consists of resource_domain_id and resource_point_id, can be obtained by the Manager through accessing the cloud controller API. resource_domain_id is used to identify a resource to be collected, such as a host, VM, Node, pod, Container, etc., generally a string or UUID. resource_point_id is used to identify a physical network card or virtual network card on the resource, generally a string, such as "eth0", "enp2s0", etc.

[0057] Observation domain, which consists of observation_domain_id and observation_point_id, is managed and allocated by the Manager. observation_domain_id is used to identify each collector, that is, the Agent, and UInt can be used. observation_point_id is used to identify each network card to be collected when the Agent collects multiple network cards, and UInt can be used.

[0058] The Agent is generally deployed by the cloud network system, such as K8s. Once the Agent is deployed and started, it can obtain its own network address and network card information through local calls. Through the deployment configuration file, the Agent can obtain the communication address and port of the Manager. Therefore, when the Agent first accesses the Manager, it registers itself and then regularly accesses the Manager to use the management functions of the Agent.

[0059] During the process of the Agent registering itself with the Manager, the Agent reports its local information. The Manager processes the registration event and allocates observation information and configurations, and its execution steps are as Figure 2 shown. The specific description is as follows:

[0060] Step S1: Input the network address and NIC list reported by the Agent.

[0061] Step S2: Use the cloud api to query the resource information and related meta data corresponding to the Agent network address. In the present invention, the network address is queried only once in this step, replacing the network address query for each data packet, and greatly solving the efficiency problem. At the same time, the query during registration is a query of alive resources, and valid query results can be obtained. The Resource information is the resource_domain_id and resource_point_id, and the meta data is the meta data of the related resources.

[0062] Step S3: Determine the network cards to be collected according to the collection requirements. Since it is not necessary to actually collect all network cards, it is necessary to determine according to the collection requirements. The collection requirements can be determined by a configuration file or by the user selecting several of the NICs reported by the Agent through the UI.

[0063] Step S4: Allocate the corresponding observation_domain_id and observation_point_id. The Manager allocates the observation_domain_id for the Agent and allocates the observation_point_id for one or more network cards to be collected. The observation_domain_id can use an incrementing UInt and is allocated sequentially from 0 according to the registration order of the Agent. The observation_point_id can also use an incrementing UInt and is directly allocated sequentially from 0 at this time.

[0064] Step S5: Update and cache the mapping relationship between resource and observation. For the Agent, establish a two-way mapping relationship between the resource information in Step S2 and the observation information in Step S4 and update it to the global cache. The use of two-way query is as follows:

[0065] 1) Query observation from resource, mainly used in the Manager for UI query and configuration of Agent and Gateway.

[0066] 2) Query resource from observation, provided to the Consumer through the api of the Manager, that is, the metadata function of the Manager. Obviously, the value space of observation is much smaller than the network address space of the cloud network. Therefore, only Step S2 performs a query of the network address space once, and then each packet query of the network data packet is completed within the value space of observation, solving the efficiency problem.

[0067] Step S6: Send the work configuration and observation information to the Agent. After the Agent registration is completed, the Manager sends the work configuration to the Agent, including which network cards' data packets to collect using what technology, how to send them out, which Gateway to send them to, etc., and also including the synchronization interval with the Manager. The observation information sent along with the work configuration, that is, the observation_domain_id and observation_point_id, needs to be included in the collected data packets. Then the Consumer can use the observation information to query the resource information and metadata.

[0068] The resource domain information and the observation domain information, that is, the observation information and the resource information, are the core data structures of the present invention. Through this structure, both the metadata problem and the efficiency problem are solved, enabling the data packets collected in the cloud network environment to play the same extensive utility as in the traditional network. In each module, the usage of the resource domain and the observation domain data structures is as Figure 3 shown and is specifically described as follows:

[0069] Agent module: The observation_domain_id and the observation_point_id are the observation information sent by the Manager when the Agent registers. The observation data... mainly refers to data packets, and can also be other collected data, such as system metric data (CPU, MEM, DISK, NET, etc.), Log, etc. If GRE, VxLAN and other tunneling technologies are used for communication between the Agent and the Gateway, then the observation_domain_id and the observation_point_id need to be encoded into the GRE and VxLAN fields (rewrite the semantics of the existing fields or use reserved fields), and only data packets can be sent at this time. If TCP / UDP-based socket communication technology is used, then these information fields can be defined by oneself, and Metric and Log information can be sent at the same time.

[0070] Gateway Module: The Gateway module can also communicate with the Manager, register itself, and accept the management of the Manager. However, as an intermediate link, the Gateway has no additional observation information. The observation_domain_id, observation_point_id, observation data... in the Gateway all come from the Agent. The measure data... is the measurement data analyzed and calculated by the Gateway, such as network flow analysis data, protocol decoding results, index analysis and statistical data, etc. The Gateway can send data using the same mechanism as the Agent module.

[0071] Consumer Module: The Consumer module obtains data such as observation_domain_id, observation_point_id, observation data..., measure data... from the Gateway. At the same time, the Consumer uses the observation information to access the metadata function of the Manager through the management api to obtain resouce_domain_id, resource_point_id, metadata..., thereby associating with the resource system and the business system to support a wide range of application scenarios.

[0072] Manager Module: The Manager queries the Cloud Controller through the cloudapi to obtain resouce_domain_id, resource_point_id, metadata, and then maintains a bidirectional mapping relationship between the observation_domain_id and observation_point_id generated when registering with the Agent. It provides a metadata service. The Consumer generally uses the metadata service when consuming network data packets. The observation_domain_id is cyclically incremented using the UInt32 identifier. There are 4,294,967,296 possible values, so there will be no conflicts. Therefore, it can effectively solve the timeliness problem of directly using network addresses.

[0073] In an actual cloud network system, the Agent, Gateway, and Consumer of the present invention are not single modules, but batch modules, as Figure 4 shown and described as follows:

[0074] Data stream. A group of Agents are connected to a Gateway. In actual deployment, multiple groups of Agents and multiple Gateways are deployed. Multiple Consumers can actually be deployed, such as NPM, Security, etc. The connections between the Gateway and the Consumers are many-to-many. These connections form a data stream.

[0075] Management API. All modules are connected to the Manager through the management API. The Manager manages the data stream formed by the topological connections between Agents, Gateways, and Consumers, etc. The Manager provides management functions and metadata functions through the management API.

[0076] Cloud API. The Manager accesses the Cloud Controller through the cloud API to obtain metadata.

[0077] The embodiments of the present invention provide a method and system for collecting cloud network data packets in a resource domain and an observation domain. The Manager is used to obtain resource domain information and metadata from the cloud controller, and allocate observation domain information during Agent registration, thereby establishing a bidirectional mapping structure between the resource domain information and the observation domain information. The Agent is used to collect data packets in the cloud network and attach the observation domain information. The Gateway undertakes the analysis and transfer function and is deployed in the cloud network close to the Agent, thereby balancing the computing overhead and the network overhead and expanding the applicability to the cloud network load. Then the Gateway sends the data to a Consumer under the cloud or in another cloud for consumption. The Manager is used to manage the data stream of the Agents, Gateways, and Consumers. The Manager provides metadata services to the Consumers, thereby solving the metadata problem of the data packets, so that they can be associated with the resource system and the business system, and thus can be efficiently applied to a wide range of analysis scenarios.

[0078] Those skilled in the art know that, in addition to implementing the system and its various devices, modules, and units provided by the present invention in the form of pure computer-readable program code, the method steps can be logically programmed to enable the system and its various devices, modules, and units provided by the present invention to be implemented in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers, etc., to achieve the same functions. Therefore, the system and its various devices, modules, and units provided by the present invention can be considered as a kind of hardware component, and the devices, modules, and units included therein for implementing various functions can also be regarded as the structures within the hardware component; the devices, modules, and units for implementing various functions can also be regarded as either software modules for implementing the method or structures within the hardware component.

[0079] The specific embodiments of the present invention have been described above. It should be understood that the present invention is not limited to the above specific embodiments, and those skilled in the art can make various changes or modifications within the scope of the claims, which do not affect the essence of the present invention. Without conflict, the embodiments of the present application and the features in the embodiments can be combined with each other arbitrarily.

Claims

1. A method for collecting cloud network data packets in a resource domain and an observation domain, characterized in that It includes: Resource domain steps: including resource_domain_id and resource_point_id; among them, the collected resource is identified by resource_domain_id, and a physical network card or virtual network card on the resource is identified by resource_point_id; Observation domain steps: including observation_domain_id and observation_point_id; among them, each collector Agent is identified by observation_domain_id, and each collected network card is identified by observation_point_id when the Agent collects multiple network cards; The Agent registers itself with the management module Manager, and then regularly accesses Manager. During the process of the Agent registering itself with Manager, the Agent reports its local information; Manager processes the registration event and allocates observation information and configuration, and the steps are as follows: Step S1: Input the network address and NIC list reported by the Agent; Step S2: Use the cloud api to query the resource information and related meta data corresponding to the Agent network address; Step S3: Determine the network cards to be collected according to the collection requirements; Step S4: Allocate the corresponding observation_domain_id and observation_point_id; Step S5: Update and cache the mapping relationship between resource and observation; Step S6: Send the work configuration and observation information to the Agent.

2. The cloud network data packet acquisition method for the resource domain and the observation domain according to claim 1, characterized in that The said Step S5 includes: for the Agent, establish a two-way mapping relationship between the resource information in Step S2 and the observation information in Step S4, and update it to the global cache.

3. The cloud network data packet acquisition method for the resource domain and the observation domain according to claim 2, wherein The use of the query of the said two-way mapping includes: Query observation from resource, mainly used in Manager for UI query and configuration of Agent and Gateway; Query resource from observation, provided to the Consumer through the api of Manager, that is, the metadata function of Manager.

4. A cloud network data packet acquisition system for a resource domain and an observation domain, based on the cloud network data packet acquisition method for the resource domain and the observation domain according to any one of claims 1-3, characterized in that, It includes: Probe module Agent: collect raw data packets and send the said raw data packets to Gateway; Gateway module Gateway: receive the raw data packets collected by the Agent, analyze and process them, and then forward the raw data packets and / or analysis results to the Consumer; Consumer module Consumer: consume the network data or analysis data of Gateway; Management module Manager: connect Agent, Gateway and Consumer, and provide two types of functions, management and metadata, through AIP.

5. The cloud network data packet acquisition system for the resource domain and the observation domain according to claim 4, characterized in that, The gateway module Gateway is close to the Agent according to the actual situation to balance the computing overhead and network overhead, and is widely used in cloud networks under various load conditions.

6. The cloud network data packet acquisition system for the resource domain and the observation domain according to claim 4, characterized in that, The management functions in the management module Manager include: For the Agent and Gateway, the Manager can issue configuration parameters, control startup and shutdown, collect and display status, and play the role of managing services; For the Consumer, it has its own management method and does not require the management functions of the Manager.

7. The cloud network data packet acquisition system for resource domain and observation domain according to claim 4, characterized in that, The metadata in the management module Manager includes: The Manager obtains the metadata contained therein by docking with various cloud controllers; The Agent, Gateway, and Consumer can all query the metadata through the Manager, so as to associate the collected cloud network data packets with the resource system and business system, supporting multiple application scenarios.

8. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the cloud network data packet collection method for the resource domain and the observation domain described in any one of claims 1 to 3.

9. An electronic device, comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, When the computer program is executed by a processor, it implements the steps of the cloud network data packet collection method for the resource domain and the observation domain described in any one of claims 1 to 3.

Images