A clientless private cloud full-link monitoring method and system

Abstract

The application belongs to the technical field of network communication, and specifically discloses a private cloud full-link monitoring method and system based on no client, which comprises the following steps: periodically calling a cloud platform API to obtain device performance data and calculate resource usage, screening low-load devices as detection sources and writing all data into a list library; issuing a task to each detection source through a cloud platform native interface, calling a system self-provided tool to concurrently detect all other detection sources in the list library and generate a result; after obtaining the result, sequentially performing three-layer judgment: judging whether a global exception occurs in a subnet and triggering an alarm, and shielding all single-device alarms in the subnet; for the subnet which is not judged to have a global exception, judging whether there is a directional link exception between subnets; for the detection source which does not have a global exception in the subnet, judging whether there is a self exception and triggering an alarm. The application can effectively reduce the interference of network detection on core business, accurately locate an abnormal position and avoid an alarm storm.

Description

Technical Field

[0001] This application belongs to the field of network communication technology, and more specifically, relates to a clientless private cloud end-to-end monitoring method and system. Background Technology

[0002] With the rapid development of cloud computing technology, enterprise IT infrastructure is gradually evolving towards multi-cloud and hybrid cloud architectures. In a multi-cloud environment, effectively monitoring network connectivity across clouds and availability zones and ensuring the stable operation of business systems has become one of the core challenges in cloud operations and maintenance.

[0003] Existing technology discloses a multi-cloud network node detection method. This method determines the detection level based on network scale, extracts at least one subnet availability zone in each virtual private cloud, selects detection nodes based on host usage frequency weights, constructs a detection list, and then initiates communication link detection to other nodes to obtain link reachability information (such as packet latency, packet loss rate, etc.). This method introduces usage frequency weights, prioritizing hosts with lower recent usage frequency as detection sources, and updates the weights after detection to achieve node rotation and load balancing. Furthermore, existing technologies typically employ automated operation and maintenance tools such as SaltStack to automatically connect detection nodes and distribute tasks. This involves installing a node detection program on the target node, receiving and executing detection tasks issued by the management center, and transmitting the detection results back for analysis.

[0004] However, existing technologies still have the following drawbacks: when the selected node happens to be in a peak business period or under high load, the execution of the probe task may further intensify the resource competition among nodes, potentially interfering with business stability; at the same time, existing technologies rely on installing and keeping node probe programs resident on the target node, which increases the workload of operation and maintenance and poses a risk of competing for resources with business processes; in addition, existing technologies mainly determine whether the communication link between two nodes is reachable, lacking the ability to analyze the specific location and level of anomalies. When a subnet-level global failure occurs (such as gateway failure or switch stack collapse), it will generate an independent unreachable alarm for each pair of probe paths, leading to an alarm storm that overwhelms key anomaly information, causing fault location deviations and operation and maintenance response delays.

[0005] Therefore, how to reduce the interference of network detection on core business, accurately locate abnormal locations, and avoid alarm storms are urgent problems that need to be solved. Summary of the Invention

[0006] In view of the shortcomings of the existing technology, the purpose of this application is to provide a clientless private cloud end-to-end monitoring method and system, which can effectively reduce the interference of network probing on core business, accurately locate abnormal locations, and avoid alarm storms.

[0007] To achieve the above objectives, firstly, this application provides a clientless private cloud end-to-end monitoring method, comprising the following steps: S10: Obtain the performance data of devices under each subnet in the private cloud platform, determine the resource utilization rate of each device based on the performance data, select devices that meet the low load conditions in each subnet as probe sources based on the resource utilization rate, and write the information of the selected probe sources into the probe device list library. S20, using the command issuance capability of the private cloud platform, a detection command is issued to each detection source in the detection device list library. The detection command is used to instruct the detection source to call the parallel network detection tool built into the local operating system to initiate fping network detection to other detection sources in the detection device list library other than itself, and obtain the detection results. S30, obtain the detection results returned by each detection source, and perform the following judgments in sequence based on the detection results: determine whether a global network anomaly has occurred in each subnet; when a global network anomaly is determined to occur in any subnet, trigger a subnet global anomaly alarm and block the single device anomaly alarms of all detection sources in the subnet that has been determined to have a global network anomaly; for any two subnets that have not been determined to have a global network anomaly, determine whether a directional link anomaly has occurred between the two subnets; when a directional link anomaly is determined to exist between the two subnets, trigger a directional link anomaly alarm; for any detection source device, if its subnet has not been determined to have a global network anomaly, determine whether the detection source has its own network anomaly; when a network anomaly is determined to exist, trigger a single device anomaly alarm for that detection source.

[0008] As a further preferred embodiment, in step S10, the performance data includes real-time CPU utilization, real-time memory utilization, and real-time network I / O utilization.

[0009] As a further preferred embodiment, in step S10, the resource utilization rate of each device is calculated using a weighted arithmetic mean method based on the performance data. The calculation formula is:

[0010] In the formula, Real-time CPU utilization; Real-time memory utilization; Real-time network I / O utilization; , , These are the weighting coefficients.

[0011] As a further preferred embodiment, in step S10, selecting devices that meet the low-load condition as detection sources in each subnet includes: Based on the total number of devices in each subnet, determine the number T of detection sources to be selected in each subnet according to the preset selection method; Sort the devices in each subnet by resource utilization from low to high, and use the first T devices as the initial probe sources; Devices with resource utilization rates exceeding a certain threshold are removed from the initial detection sources to obtain the final detection sources.

[0012] As a further preferred option, the preset quantity selection method includes: Calculate the basic sample number The calculation formula is: ,in Sampling ratio, To be the minimum guaranteed number, Maximum upper limit; If the basic sampling number If the number is even, then the basic sample number will be... Subtracting 1 gives the number of detection sources T, if the basic sampling number If the number is odd, then the basic sample number will be... The number of detection sources, T, is directly used.

[0013] As a further preferred embodiment, in step S20, the detection results include average latency, packet loss rate, and network reachability; when the packet loss rate is greater than a first threshold, the average latency is greater than a second threshold, the network is unreachable, or no detection result is received within a preset time, it is determined to be a detection anomaly.

[0014] As a further preferred embodiment, in step S20, the detection source divides the detection task into several batches during the execution of the detection task. After each batch is completed, it automatically collects its current resource usage status. If any resource indicator is detected to exceed a preset threshold, the detection task for this round is terminated, and an exit information is reported to the management center. After receiving the exit information, the management center marks the detection source as unavailable for this period, and selects a new node from the candidate node pool of the corresponding subnet according to the principle of lowest load to add to the detection device list library, and issues the remaining detection tasks to the selected node.

[0015] As a further preferred embodiment, in step S20, the fping network probe includes: sending a probe packet every 1 second, sending 50 probe packets per minute, including a 10-second process rest period; the probe results are returned in JSON format.

[0016] As a further preferred embodiment, in step S30, determining whether a global network anomaly has occurred in each subnet specifically includes: obtaining a first detection result obtained by all probe sources within the target subnet probing all probe sources in other external subnets, and a second detection result obtained by all probe sources in other external subnets probing all probe sources within the target subnet; when the first detection result indicates that all probes sent by all probe sources within the target subnet to all other external subnets are detection anomalies, and the second detection result indicates that all probes sent by probe sources in other external subnets to all probe sources within the target subnet are detection anomalies, it is determined that a global network anomaly has occurred in the target subnet; The determination of whether a directional link anomaly has occurred between the two subnets specifically includes: for any two subnets, the first and the second, that are not determined to be global network anomalies, obtaining a third detection result obtained from all probe sources in the first subnet probing to all probe sources in the second subnet, and a fourth detection result obtained from each probe source in the first and the second subnet probing to probe sources in other subnets besides the first and the second subnets; when the third detection result indicates that all probes sent by all probe sources in the first subnet to all probe sources in the second subnet are all detection anomalies, and the fourth detection result indicates that there is at least one probe source in both the first and the second subnets that can normally access probe sources in other subnets, it is determined that a directional link anomaly has occurred between the first and the second subnets; The determination of whether the detection source has its own network anomaly specifically includes: obtaining a fifth detection result obtained from detection sources from at least two different subnets probing the target detection source, and a sixth detection result obtained from detection sources from at least two different subnets probing other detection sources under the subnet to which the target detection source belongs; when the fifth detection result indicates that detection sources from at least two different subnets both determine that the target detection source is a detection anomaly, and the sixth detection result indicates that at least one other detection source within the subnet to which the target detection source belongs is normally accessed by detection sources from at least two different subnets, it is determined that the target detection source has a single device anomaly.

[0017] Secondly, this application provides a clientless private cloud end-to-end monitoring system for implementing the clientless private cloud end-to-end monitoring method described in any one of the above-mentioned methods, including: The probe node list library update module is used to obtain the performance data of devices under each subnet in the private cloud platform, determine the resource utilization rate of each device based on the performance data, select devices that meet the low load conditions in each subnet as probe sources based on the resource utilization rate, and write the information of the selected probe sources into the probe device list library in full. The network detection task instruction module is used to issue network detection task instructions to each detection source in the detection device list library through the native batch execution interface of the private cloud platform. The network detection task instructions are used to instruct the detection source to call the parallel network detection tool built into the local operating system to initiate fping network detection to other detection sources in the detection device list library other than itself, and generate detection results. The anomaly analysis module is used to obtain the detection results returned by each detection source and, based on the detection results, sequentially perform the following judgments: Determine whether a global network anomaly has occurred in each subnet. If a global network anomaly is determined in any subnet, trigger a global anomaly alarm for that subnet and block single-device anomaly alarms from all detection sources within the subnet determined to have a global network anomaly; For any two subnets that are not determined to have a global network anomaly, determine whether a directional link anomaly has occurred between the two subnets. If a directional link anomaly is determined to exist between the two subnets, trigger a directional link anomaly alarm; For any detection source device, if its subnet is not determined to have a global network anomaly, determine whether the detection source has its own network anomaly. If a network anomaly is determined to exist, trigger a single-device anomaly alarm for that detection source.

[0018] This application has at least the following beneficial effects: This application eliminates the need to install any resident monitoring client or agent program on the target node. It relies entirely on the private cloud platform's native API interface and the operating system's built-in network probing tools to distribute and execute probing tasks, achieving truly "clientless" zero-intrusion monitoring. This avoids the memory consumption, CPU usage, and disk I / O overhead associated with installing and running monitoring clients, fundamentally eliminating the risk of monitoring programs competing for system resources with business processes. Furthermore, by acquiring real-time resource utilization data for each node, this application dynamically selects the node with the lowest load in each subnet as the probing source, transferring the minimal overhead of the probing task to idle resources, further reducing interference with core business operations. Furthermore, this application adopts a full-scale concurrent cross-probing mechanism, in which the probing nodes selected by each subnet use fping to initiate high-concurrency ICMP probes to all other probing nodes, forming an N×(N-1) distributed mesh probing matrix, which completely covers the internal links from subnet to subnet and end to end, eliminating the monitoring blind spots of the traditional centralized probing mode. On this basis, this application performs aggregate operations and hierarchical diagnosis on the probe results through three-layer progressive analysis (subnet-level global fault determination, inter-subnet directional link fault determination, and single node self-anomaly determination). This not only accurately locates the fault level, but also automatically masks the redundant alarms at the lower level when a high-level fault is triggered, effectively avoiding alarm storms. Attached Figure Description

[0019] Figure 1This is a flowchart illustrating the clientless private cloud end-to-end monitoring method provided in this application. Figure 2 This is a schematic diagram illustrating the specific process of the clientless private cloud end-to-end monitoring method provided in this application; Figure 3 This is a schematic diagram of the distributed mesh detection execution of the device provided in this application. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0021] like Figure 1 and Figure 2 As shown, this application provides a clientless private cloud end-to-end monitoring method, including: Step S1: Periodically call the resource monitoring API interface of the private cloud platform to obtain the raw performance data of all devices in each subnet of the cloud environment, calculate the resource utilization rate of each device based on the raw performance data, and select devices that meet the low load conditions in each subnet as probe source devices based on the resource utilization rate, and fully cover the device information of the selected probe source devices into the probe device list library.

[0022] In step S1, the system configures a scheduled task to periodically call the resource monitoring API interface of the private cloud platform to obtain the network topology of the current cloud environment (such as VPC and subnetting). For each subnet, the system obtains the real-time resource utilization (such as CPU, memory, and network I / O utilization) of all devices under it. The system then uses a sorting and evaluation algorithm to select low-load devices that meet the requirements under each subnet. The system extracts the IP addresses and subnet information of these devices and writes them into the global probe node list library in a full-coverage manner.

[0023] Step S2: Through the native batch execution interface of the private cloud platform, a network detection task instruction is issued to each detection source device in the current detection device list. The network detection task instruction is used to instruct the detection source device receiving the instruction to call the parallel network detection tool built into the local operating system, initiate fping network detection to all other detection source devices in the detection device list except itself, and generate detection results.

[0024] In step S2, based on the list of probe devices generated in step S1, the backend management center uses a scheduled task to call the native batch execution API interface of the private cloud platform (such as the command delivery channel of the cloud management platform) to distribute the link probe task to all low-load devices recorded in the "probe device list". This process does not require any customized monitoring agent to be pre-installed on the target devices, and relies purely on the native capabilities of the cloud management channel.

[0025] After receiving the probe task, the selected low-load device executes the task script on its local terminal. The core of the task is to call the system's native fping program, such as... Figure 3 As shown, all IP addresses in the "IP list library" other than the IP address of this device are used as targets to launch high-concurrency ICMP probes (1 packet is sent every 1 second, a total of 50 packets are sent per minute, with a 10-second process rest).

[0026] Compared to traditional ping, fping has the ability to probe multiple targets concurrently. It can quickly collect core link metrics such as network latency and packet loss from the current node to all other subnet nodes, and return the probe results to the management center in a unified JSON format.

[0027] This ultimately forms an N*(N-1) distributed mesh probe matrix, where N is the number of device addresses in the "probe node list library", completely covering the internal links "subnet to subnet" and "end to end".

[0028] Meanwhile, to avoid interference from sudden loads on business nodes caused by the detection task, this application also requires that after the selected detection source device starts executing the detection task, the detection source device divides the detection task into several batches. After each batch is completed (e.g., every 50 detection targets), the detection source device automatically collects its current resource usage status, including but not limited to CPU utilization, memory utilization, and network I / O utilization. If any resource indicator is detected to exceed the preset threshold (e.g., CPU utilization > 70%, or network I / O utilization > 80%), the detection source device immediately terminates the current round of detection task and reports the exit information to the management center. The exit information includes the exit reason, the current load value, and the list of targets that have been detected. After receiving the exit information, the management center performs the following operations: (1) marks the detection source device as "unavailable in this period" and removes it from the detection list of the current period; (2) selects a new node from the candidate node pool of the corresponding subnet according to the principle of the lowest load and adds it to the detection list; (3) issues the remaining detection tasks to the selected node. Through the aforementioned dynamic exit mechanism, the probe behavior can proactively "give way" when business load suddenly increases, avoiding exacerbating business anomalies due to probes, and achieving further protection of core business through monitoring.

[0029] Step S3: Obtain the detection results returned by each device, and perform the following anomaly determinations in sequence: Determine whether a global network anomaly has occurred in each subnet. If a global network anomaly is determined in any subnet, trigger a global anomaly alarm for the subnet and block the individual device anomaly alarms of all detection source devices within the subnet that has been determined to have a global network anomaly; For any two subnets that have not been determined to have a global network anomaly, determine whether a directional link anomaly has occurred between the two subnets. If a directional link anomaly is determined to exist between the two subnets, trigger a directional link anomaly alarm; For any detection source device, if its subnet has not been determined to have a global network anomaly, determine whether the detection source device has its own network anomaly. If a network anomaly is determined to exist, trigger an individual device anomaly alarm for the detection source device.

[0030] In step S3, the management center performs a three-level progressive analysis on the detection indicators collected in step S2. If a high-level fault is triggered, the subsequent level judgment results will only serve as auxiliary evidence and will not trigger independent alarms again.

[0031] (1) Subnet-level global fault determination (highest level): Judgment criteria: If all probe source devices belonging to subnet A in the list library in step 1 return "network unreachable" or "100% packet loss" when probing all other external subnets (B, C, D...); and in reverse probing, all external subnets also return "network unreachable" when probing subnet A.

[0032] Conclusion: The network is determined to be abnormal across the entire subnet A (common causes include gateway failure or stack failure of access switches in subnet A). In this case, the "self-network abnormality" alarms of all nodes in subnet A are automatically masked to avoid alarm storm.

[0033] (2) Inter-subnet directional link fault determination (second level): Judgment criteria: Assuming no global faults within the subnet itself, if more than half of the probe paths between subnet A and subnet B return abnormal results (delay > 10ms or packet loss > 5%), but the probe results from subnet A to other subnets such as subnets C and D are normal.

[0034] Conclusion: The directional path between subnet A and subnet B is determined to be abnormal (common causes include incorrect cross-subnet routing policies or congestion on specific physical links).

[0035] (3) Single device node anomaly detection (lowest level): Judgment criteria: Under the premise of excluding the above-mentioned hierarchical faults, if a specific node X in subnet A in step 1 is determined to be "network unreachable" by multiple probe sources from different subnets (B, C, etc.), but other probe nodes (Y, Z) in subnet A behave normally to external probes.

[0036] Conclusion: The issue is determined to be an anomaly in the network components of device node X itself.

[0037] Based on the above data, a complete link status topology is finally formed and displayed on the monitoring screen or an alarm is triggered.

[0038] In the aforementioned clientless private cloud end-to-end monitoring method, this application eliminates the need to install any resident monitoring client or agent program on the target node. It relies entirely on the private cloud platform's native API interface and the operating system's built-in network probing tools to complete the distribution and execution of probing tasks, achieving truly "clientless" zero-intrusion monitoring. This avoids the memory consumption, CPU usage, and disk I / O overhead associated with installing and running monitoring clients, fundamentally eliminating the risk of monitoring programs competing for system resources with business processes. Furthermore, by obtaining real-time resource utilization data for each node, this application dynamically selects the node with the lowest load in each subnet as the probing source, transferring the minimal overhead of the probing task to idle resources, further... This reduces interference with core business operations. Furthermore, this application adopts a full-scale concurrent cross-probing mechanism, where selected probe nodes in each subnet use fping to initiate high-concurrency ICMP probes to all other probe nodes, forming an N×(N-1) distributed mesh probe matrix. This thoroughly covers internal links from subnet to subnet and end to end, eliminating the monitoring blind spots of traditional centralized probe modes. Based on this, this application performs aggregated operations and hierarchical diagnosis on the probe results through three-layer progressive analysis (subnet-level global fault determination, inter-subnet directional link fault determination, and single-node self-anomaly determination). This not only accurately locates the fault level but also automatically masks redundant alarms at the lower level when a higher-level fault is triggered, effectively avoiding alarm storms.

[0039] In one embodiment, raw performance data includes: real-time CPU utilization, real-time memory utilization, and real-time network I / O utilization.

[0040] In one embodiment, calculating the resource utilization of each device based on raw performance data includes: The resource utilization rate of each device is calculated using the weighted arithmetic mean method according to the following formula:

[0041] in, For real-time CPU utilization, For real-time memory utilization, For real-time network I / O utilization, , , These are weighting coefficients. Weighting coefficients, for example, are 0.4, 0.3, and 0.3, and can be dynamically adjusted according to the actual business environment.

[0042] In one embodiment, selecting devices that meet low-load conditions as probe source devices in each subnet includes: Based on the total number of devices in each subnet, determine the number T of detection source devices to be selected in each subnet according to the preset selection method; The resource utilization of devices in each subnet is sorted in ascending order, and the top T devices that meet the low load condition are used as the initial probe source devices. Delete devices with resource utilization rates exceeding a certain threshold from the initial detection source devices.

[0043] Specifically, the preset quantity selection methods include: The basic sample number is calculated using the following formula. :

[0044] in, Sampling ratio, To be the minimum guaranteed number, Maximum upper limit; If the basic sample number If it is even, then the basic sample number will be... Subtract 1 to get the number of detection source devices T, if the basic sampling number If it is an odd number, then the basic sample number will be... The number of devices directly used as detection sources, T.

[0045] In one embodiment, the detection results include: average latency, packet loss rate, and network reachability; when any of the following occurs, the detection is determined to be abnormal: packet loss rate is greater than a first threshold, average latency is greater than a second threshold, network is unreachable, or no detection result is received within a preset time.

[0046] In this embodiment, the exception handling methods may differ at different levels.

[0047] In one embodiment, determining whether a global network anomaly has occurred in each subnet specifically includes: obtaining a first detection result obtained by all probe source devices within the target subnet probing all other external subnet probe source devices, and a second detection result obtained by all external subnet probe source devices probing all probe source devices within the target subnet; when the first detection result indicates that all probe source devices within the target subnet have probed all other external subnets and the second detection result indicates that all probe source devices outside the external subnet have probed all other external subnets and all probe source devices within the target subnet have probed all other external subnets, it is determined that a global network anomaly has occurred in the target subnet; Determining whether a directional link anomaly has occurred between two subnets specifically includes: for any two subnets, the first and second, that are not determined to be globally network anomalies, obtaining the third detection results obtained from all probe source devices in the first subnet probing to all probe source devices in the second subnet, and the fourth detection results obtained from each probe source device in the first and second subnets probing to probe source devices in other subnets besides the first and second subnets; when the third detection result indicates that all probes sent by all probe source devices in the first subnet to all probe source devices in the second subnet are all detection anomalies, and the fourth detection result indicates that at least one probe source device in both the first and second subnets can normally access probe source devices in other subnets, a directional link anomaly is determined to have occurred between the first and second subnets; Determining whether a probe source device has a network anomaly specifically includes: obtaining the fifth probe result obtained from probe source devices from at least two different subnets probing the target probe source device, and the sixth probe result obtained from probe source devices from at least two different subnets probing other probe source devices in the subnet to which the target probe source device belongs; when the fifth probe result indicates that probe source devices from at least two different subnets both determine that the target probe source device is a probe anomaly, and the sixth probe result indicates that there is at least one other probe source device in the subnet to which the target probe source device belongs that can be accessed normally by probe source devices from at least two different subnets, it is determined that the target probe source device has a single device anomaly.

[0048] When a global network anomaly is detected, if the system does not receive the first detection result within a preset time (i.e., the subnet is globally unreachable), it cannot upload the detection result. The second detection result is obtained by the external subnet probing the target subnet. The second detection result is either network unreachable or packet loss rate of 100%.

[0049] The third detection result for determining an abnormality in the directional link is due to any of the following: packet loss rate is greater than the first threshold, average latency is greater than the second threshold, the network is unreachable, or no detection result is received within a preset time.

[0050] When determining that its own network is abnormal, the fifth detection result is due to any of the following: packet loss rate is greater than the first threshold, average latency is greater than the second threshold, network is unreachable, or no detection result is received within a preset time.

[0051] Based on the same inventive concept, this application also provides a clientless private cloud end-to-end monitoring system, including: The probe node list library update module is used to periodically obtain the raw performance data of all devices in each subnet of the cloud environment by calling the resource monitoring API interface of the private cloud platform, calculate the resource utilization rate of each device based on the raw performance data, and select devices that meet the low load conditions in each subnet as probe source devices based on the resource utilization rate, and fully overwrite the device information of the selected probe source devices into the probe device list library. Network Probe Task Instruction Module: This module is used to issue network probe task instructions to each probe source device in the current probe device list through the native batch execution interface of the private cloud platform. The network probe task instructions are used to instruct the probe source device receiving the instructions to call the parallel network probe tool built into the local operating system, initiate fping network probes to all other probe source devices in the probe device list except itself, and generate probe results. Anomaly Analysis Module: Used to obtain the detection results returned by each device and perform the following anomaly determinations in sequence: Determine whether a global network anomaly has occurred in each subnet. If a global network anomaly is determined in any subnet, trigger a global anomaly alarm for that subnet and disable individual device anomaly alarms for all probe source devices within the subnet with the global network anomaly. For any two subnets that are not determined to have a global network anomaly, determine whether a directional link anomaly has occurred between the two subnets. If a directional link anomaly is determined to exist between the two subnets, trigger a directional link anomaly alarm. For any probe source device, if its subnet is not determined to have a global network anomaly, determine whether the probe source device has its own network anomaly. If an internal network anomaly is determined to exist, trigger an individual device anomaly alarm for that probe source device.

[0052] The advantages of this application include: (1) Zero intrusion and low resource consumption (Agentless): Innovatively utilizes the existing APIs of the private cloud and the native fping tool of the operating system to achieve zero-intrusion monitoring without the need to install, configure and maintain any monitoring client, which greatly reduces the operation and maintenance management cost and protects the security and purity of the business environment.

[0053] (2) Dynamic detection without business awareness: By selecting only the "preset number of devices with the lowest usage rate" as the detection executor each time, the small amount of computation and network overhead brought by network detection is cleverly transferred to idle resources, reducing the interference of monitoring on core business.

[0054] (3) Eliminate blind spots in internal network monitoring: The traditional central radial detection method was abandoned, and a distributed "inter-subnet mutual detection" mechanism was adopted instead. Since the IP list database covers all subnets, the real link quality between any two subnets within the private cloud can be fully and accurately grasped through fping cross-probing, realizing true "full link".

[0055] The key technical point of this application is: (1) Load-aware dynamic detection source rotation mechanism: It breaks through the limitation of fixed detection nodes in the existing monitoring system, dynamically pulls low-load nodes as temporary detection sources through private cloud API, and dynamically refreshes the detection node list library.

[0056] (2) Agentless detection method that reuses the native API of the cloud platform: Combining the command delivery channel of the private cloud platform with the high-concurrency detection characteristics of native fping, complex distributed network speed test tasks can be completed without installing a resident agent.

[0057] (3) Mesh topology analysis logic based on subnet intersection: Using the fping result data collected in a distributed manner, the single node failure is eliminated through set operation, thereby macroscopically deriving the underlying link connectivity status at the subnet level.

[0058] (4) Traditional random sampling probing (such as frequency polling-based probing) has two uncertainties: first, the selection of probe nodes is random, which cannot ensure that the selected points cover all subnets; second, the selection of probe targets is also random, which cannot ensure that the targets cover all subnets. As a result, the probe results obtained are difficult to effectively cover all communication between subnets. In contrast, this application accurately extracts low-load nodes in each subnet to construct a full list, and uses the native capabilities of fping to implement N×(N-1) deterministic full-coverage probing, thus providing the only data foundation that can support the logical derivation of the subsequent "three-layer progressive analysis".

[0059] (5) This application, without relying on dedicated testing equipment, without deploying any monitoring agents, and without interfering with core business, can macroscopically and accurately deduce complex subnet routing anomalies and firewall policy failures at the underlying level of the private cloud simply by analyzing the ICMP connectivity set between edge endpoints. This breaks through the mindset of traditional technologies that "routing faults must be located by relying on heavy probes or underlying network flow analysis".

[0060] For specific limitations regarding a clientless private cloud end-to-end monitoring system, please refer to the aforementioned limitations regarding a clientless private cloud end-to-end monitoring method, which will not be repeated here. Each module in the aforementioned clientless private cloud end-to-end monitoring system can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can invoke and execute the corresponding operations of each module.

[0061] In one embodiment, this application also provides a computer-readable storage medium having a computer program stored thereon relating to all or part of the processes in the methods of the above embodiments.

[0062] In one embodiment, this application also provides a computer program product, including a computer program / instructions that, when executed by a processor, relate to all or part of the processes in the methods of the above embodiments.

[0063] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, or optical storage, etc. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc.

[0064] Those skilled in the art will readily understand that the above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A clientless, end-to-end monitoring method for private clouds, characterized in that, Includes the following steps: S10: Obtain the performance data of devices under each subnet in the private cloud platform, determine the resource utilization rate of each device based on the performance data, select devices that meet the low load conditions in each subnet as probe sources based on the resource utilization rate, and write the information of the selected probe sources into the probe device list library. S20, using the command issuance capability of the private cloud platform, a detection command is issued to each detection source in the detection device list library. The detection command is used to instruct the detection source to call the parallel network detection tool built into the local operating system to initiate fping network detection to other detection sources in the detection device list library other than itself, and obtain the detection results. S30, obtain the detection results returned by each detection source, and perform the following judgments in sequence based on the detection results: determine whether a global network anomaly has occurred in each subnet; when a global network anomaly is determined to occur in any subnet, trigger a subnet global anomaly alarm and block the single device anomaly alarms of all detection sources in the subnet that has been determined to have a global network anomaly; for any two subnets that have not been determined to have a global network anomaly, determine whether a directional link anomaly has occurred between the two subnets; when a directional link anomaly is determined to exist between the two subnets, trigger a directional link anomaly alarm; for any detection source device, if its subnet has not been determined to have a global network anomaly, determine whether the detection source has its own network anomaly; when a network anomaly is determined to exist, trigger a single device anomaly alarm for that detection source.

2. The clientless private cloud end-to-end monitoring method as described in claim 1, characterized in that, In step S10, the performance data includes real-time CPU utilization, real-time memory utilization, and real-time network I / O utilization.

3. The clientless private cloud end-to-end monitoring method as described in claim 1, characterized in that, In step S10, the resource utilization rate of each device is calculated using a weighted arithmetic mean method based on the performance data. The calculation formula is: In the formula, Real-time CPU utilization; Real-time memory utilization; Real-time network I / O utilization; , , These are the weighting coefficients.

4. The clientless private cloud end-to-end monitoring method as described in claim 1, characterized in that, In step S10, selecting devices that meet the low-load condition as detection sources in each subnet includes: Based on the total number of devices in each subnet, determine the number T of detection sources to be selected in each subnet according to the preset selection method; Sort the devices in each subnet by resource utilization from low to high, and use the first T devices as the initial probe sources; Devices with resource utilization rates exceeding a certain threshold are removed from the initial detection sources to obtain the final detection sources.

5. The clientless private cloud end-to-end monitoring method as described in claim 4, characterized in that, The preset quantity selection methods include: Calculate the basic sample number The calculation formula is: ,in The sampling ratio, To be the minimum guaranteed number, Maximum upper limit; If the basic sampling number If the number is even, then the basic sample number will be... Subtracting 1 gives the number of detection sources T, if the basic sampling number If the number is odd, then the basic sample number will be... The number of detection sources, T, is directly used.

6. The clientless private cloud end-to-end monitoring method as described in claim 1, characterized in that, In step S20, the detection results include average latency, packet loss rate, and network reachability; When the packet loss rate exceeds the first threshold, the average latency exceeds the second threshold, the network is unreachable, or no detection result is received within a preset time, the detection is judged to be abnormal.

7. The clientless private cloud end-to-end monitoring method as described in claim 1, characterized in that, In step S20, during the execution of the detection task, the detection source divides the detection task into several batches. After each batch is completed, it automatically collects its current resource usage status. If any resource indicator is detected to exceed a preset threshold, the detection task for this round is terminated and an exit information is reported to the management center. After receiving the exit information, the management center marks the detection source as unavailable for this period, selects a new node from the candidate node pool of the corresponding subnet according to the principle of lowest load, adds it to the detection device list library, and issues the remaining detection tasks to the selected node.

8. The clientless private cloud end-to-end monitoring method as described in claim 1, characterized in that, In step S20, the fping network probe includes: sending one probe packet every 1 second, sending 50 probe packets per minute, including a 10-second process rest period; the probe results are returned in JSON format.

9. The clientless private cloud end-to-end monitoring method as described in claim 1, characterized in that, In step S30, determining whether a global network anomaly has occurred in each subnet specifically includes: obtaining a first detection result obtained by all probe sources within the target subnet probing all probe sources in other external subnets, and a second detection result obtained by all probe sources in other external subnets probing all probe sources within the target subnet; when the first detection result indicates that all probes sent by all probe sources within the target subnet to all other external subnets are abnormal, and the second detection result indicates that all probes sent by probe sources in other external subnets to all probe sources within the target subnet are abnormal, it is determined that a global network anomaly has occurred in the target subnet; The determination of whether a directional link anomaly has occurred between the two subnets specifically includes: for any two subnets, the first and the second, that are not determined to be global network anomalies, obtaining a third detection result obtained from all probe sources in the first subnet probing to all probe sources in the second subnet, and a fourth detection result obtained from each probe source in the first and the second subnet probing to probe sources in other subnets besides the first and the second subnets; when the third detection result indicates that all probes sent by all probe sources in the first subnet to all probe sources in the second subnet are all detection anomalies, and the fourth detection result indicates that there is at least one probe source in both the first and the second subnets that can normally access probe sources in other subnets, it is determined that a directional link anomaly has occurred between the first and the second subnets; The determination of whether the detection source has its own network anomaly specifically includes: obtaining a fifth detection result obtained from detection sources from at least two different subnets probing the target detection source, and a sixth detection result obtained from detection sources from at least two different subnets probing other detection sources under the subnet to which the target detection source belongs; when the fifth detection result indicates that detection sources from at least two different subnets both determine that the target detection source is a detection anomaly, and the sixth detection result indicates that at least one other detection source within the subnet to which the target detection source belongs is normally accessed by detection sources from at least two different subnets, it is determined that the target detection source has a single device anomaly.

10. A clientless private cloud end-to-end monitoring system, characterized in that, The steps for implementing the clientless private cloud end-to-end monitoring method according to any one of claims 1 to 9 include: The probe node list library update module is used to obtain the performance data of devices under each subnet in the private cloud platform, determine the resource utilization rate of each device based on the performance data, select devices that meet the low load conditions in each subnet as probe sources based on the resource utilization rate, and write the information of the selected probe sources into the probe device list library in full. The network detection task instruction module is used to issue network detection task instructions to each detection source in the detection device list library through the native batch execution interface of the private cloud platform. The network detection task instructions are used to instruct the detection source to call the parallel network detection tool built into the local operating system to initiate fping network detection to other detection sources in the detection device list library other than itself, and generate detection results. The anomaly analysis module is used to obtain the detection results returned by each detection source and, based on the detection results, sequentially perform the following judgments: Determine whether a global network anomaly has occurred in each subnet. If a global network anomaly is determined in any subnet, trigger a global anomaly alarm for that subnet and block single-device anomaly alarms from all detection sources within the subnet determined to have a global network anomaly; For any two subnets that are not determined to have a global network anomaly, determine whether a directional link anomaly has occurred between the two subnets. If a directional link anomaly is determined to exist between the two subnets, trigger a directional link anomaly alarm; For any detection source device, if its subnet is not determined to have a global network anomaly, determine whether the detection source has its own network anomaly. If a network anomaly is determined to exist, trigger a single-device anomaly alarm for that detection source.

Images