Broadcast storm monitoring method and system, storage medium and terminal

Abstract

The invention provides a broadcast storm monitoring method and system, a storage medium and a terminal. The method comprises the following steps: establishing a network topology model; constructing a broadcast storm monitoring framework based on the network topology model; setting a data acquisition strategy in the broadcast storm monitoring framework; performing data acquisition on each monitoring object in the broadcast storm monitoring framework based on the data acquisition strategy; and carrying out broadcast storm monitoring based on the collected data. According to the broadcast storm monitoring method and system, the storage medium and the terminal, broadcast storm monitoring can be carried out in real time, and safe operation of a network is facilitated.

Description

Technical Field

[0001] The present invention relates to the technical field of Ethernet, and in particular to a broadcast storm monitoring method, system, storage medium and terminal. Background Art

[0002] A broadcast storm, also known as a network storm, refers to a situation in which broadcast packets are meaninglessly replicated and propagated in large quantities within a network due to design defects in the network topology, human operational errors, equipment failures, and other reasons, resulting in a large number of broadcast packets in the network.

[0003] Once a broadcast storm occurs, it will have a huge impact and harm to the VLAN and even the entire network, hindering the normal operation and use of the network. The main impacts of broadcast storms include the following aspects:

[0004] (1) Switching devices such as HUBs and switches in the network will flood broadcast data frames. If a loop occurs in the network, after multiple flooding operations, a large number of broadcast flows with different directions will appear in the network, far exceeding the upper limit of the data that the switching device can carry.

[0005] (2) A large number of broadcast packets will consume a large amount of link bandwidth, resulting in the suppression of normal data frame transmission, which cannot be effectively transmitted, causing network congestion and reducing network transmission efficiency and accuracy. This will eventually manifest as channel congestion, delay in normal data frame transmission or frame loss.

[0006] (3) Network devices such as switches must perform operations such as caching, error detection, and MAC address table query on each frame, all of which will occupy part of the CPU. When a large number of broadcast frames are processed by the switch, a large amount of switch resources will be occupied, resulting in increased CPU usage of network devices, and the inability to process data and respond in a timely manner, resulting in an unresponsive pseudo-dead state or even a crash, which may further damage the device hardware and reduce the life of the device.

[0007] (4) There are many reasons for broadcast storms in the network. The most common one is the network loop. The broadcast storm caused by the loop problem is relatively severe and can cause partial or complete paralysis of the network within one or two seconds to several minutes.

[0008] (5) A large number of normal data packets cannot be responded to or respond incorrectly, or even the network is paralyzed, which will affect the normal use of the network and cause the production work and business flow based on the network to be unable to operate normally.

[0009] In the existing technology, mainstream network management provides some commonly used classic solutions and means to detect or avoid network storms, mainly including the following:

[0010] (1) VLAN technology is usually used to divide different broadcast domains, which not only meets the need for business isolation, but also reduces the number of devices affected by broadcast storms.

[0011] (2) Most manageable switches provide the function of suppressing and monitoring broadcast storms. If you need to use them, you need to manually set and enable these functions. For example, the broadcast suppression function for a port requires setting specific suppression thresholds, including the number of packets per second (pps) or bits per second (bs or kbs) received by the port. You can also set the actions after the trigger, including closing the port, limiting packet loss, or sending information.

[0012] However, although the above solutions can alleviate the impact of network storms to a certain extent, in common production networks, the storm suppression function provided by switches is often used in few scenarios and is very cumbersome. Once a problem occurs, it still takes a lot of time and manpower to troubleshoot and locate the problem. Summary of the invention

[0013] In view of the above-mentioned shortcomings of the prior art, the object of the present invention is to provide a broadcast storm monitoring method, system, storage medium and terminal, which can monitor broadcast storms in real time and contribute to the safe operation of the network.

[0014] In a first aspect, the present invention provides a broadcast storm monitoring method, which includes the following steps: establishing a network topology model; constructing a broadcast storm monitoring framework based on the network topology model; setting a data collection strategy within the broadcast storm monitoring framework; collecting data for each monitoring object within the broadcast storm monitoring framework based on the data collection strategy; and performing broadcast storm monitoring based on the collected data.

[0015] In an implementation of the first aspect, constructing a broadcast storm monitoring framework based on the network topology model includes the following steps:

[0016] Acquire all network devices and corresponding interconnection ports based on the network topology model;

[0017] Acquire each divided VLAN and each VLAN port based on the network topology model;

[0018] Acquire a monitoring port based on the network topology model;

[0019] The broadcast storm monitoring framework is constructed based on all the network devices and the corresponding interconnection ports, the VLAN ports and the monitoring ports.

[0020] In an implementation of the first aspect, setting a data collection strategy within the broadcast storm monitoring framework includes the following steps:

[0021] Set the data collection cycle;

[0022] Set the data collection content for each monitoring object.

[0023] In an implementation of the first aspect, the data collection content of the network device includes CPU usage and ping connectivity; the data collection content of the interconnection port is the number of incoming broadcast packets per second, the number of outgoing broadcast packets per second, the number of incoming discarded packets per second, and the number of outgoing discarded packets per second; the data collection content of the VLAN port is the number of incoming broadcast packets, the number of outgoing broadcast packets, the number of incoming discarded packets, and the number of outgoing discarded packets; the data collection content of the monitoring port is the number of incoming broadcast packets.

[0024] In an implementation of the first aspect, performing broadcast storm monitoring based on the collected data includes the following steps:

[0025] Obtain the thresholds, weights, and storm trigger scores of each monitoring object;

[0026] Obtaining collected data of each monitoring object;

[0027] Calculate the mean of the collected data and use the mean as a reference value for the monitoring content;

[0028] Comparing the reference value with the corresponding threshold value to obtain a comparison score;

[0029] Calculate the product of the comparison score of each monitored object and the corresponding weight, and use the product as the actual score of the monitored object;

[0030] The final score of each monitored object is calculated according to 100*(1-(actual score / total score)), where the total score is the sum of the actual scores when the reference values ​​of each monitored object are greater than the threshold;

[0031] When there is at least one final score that is smaller than the storm trigger score, it is determined that a broadcast storm is formed.

[0032] In an implementation manner of the first aspect, it also includes taking snapshots of the collected data and the final score, and performing rolling storage.

[0033] In an implementation manner of the first aspect, the method further includes, when a broadcast storm is monitored, performing broadcast storm location based on snapshot data between adjacent broadcast storms.

[0034] In a second aspect, the present invention provides a broadcast storm monitoring system, the system comprising a building module, a construction module, a setting module, a collection module and a monitoring module;

[0035] The establishment module is used to establish a network topology model;

[0036] The construction module is used to construct a broadcast storm monitoring framework based on the network topology model;

[0037] The setting module is used to set the data collection strategy within the broadcast storm monitoring framework;

[0038] The acquisition module is used to collect data from each monitoring object within the broadcast storm monitoring framework based on the data acquisition strategy;

[0039] The monitoring module is used to perform broadcast storm monitoring based on the collected data.

[0040] In a third aspect, the present invention provides a storage medium having a computer program stored thereon, which implements the above-mentioned broadcast storm monitoring method when executed by a processor.

[0041] In a fourth aspect, the present invention provides a broadcast storm monitoring terminal, comprising: a processor and a memory;

[0042] The memory is used to store computer programs;

[0043] The processor is used to execute the computer program stored in the memory, so that the broadcast storm monitoring terminal executes the above-mentioned broadcast storm monitoring method.

[0044] As described above, the broadcast storm monitoring method, system, storage medium and terminal of the present invention have the following beneficial effects:

[0045] (1) It can monitor broadcast storms in real time, reducing the workload of network management and operation and maintenance personnel;

[0046] (2) It can timely discover and locate the scope and even source of broadcast storms, which helps to solve related problems in a timely manner. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] Figure 1 Shown is a flow chart of a broadcast storm monitoring method in one embodiment of the present invention;

[0048] Figure 2 Shown is a schematic structural diagram of a broadcast storm monitoring system in one embodiment of the present invention;

[0049] Figure 3 Shown is a schematic structural diagram of a broadcast storm monitoring terminal in one embodiment of the present invention. DETAILED DESCRIPTION

[0050] The following describes the embodiments of the present invention by specific examples, and those skilled in the art can easily understand other advantages and effects of the present invention from the contents disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that the following embodiments and features in the embodiments can be combined with each other without conflict.

[0051] It should be noted that the illustrations provided in the following embodiments are only schematic illustrations of the basic concept of the present invention, and thus the drawings only show components related to the present invention rather than being drawn according to the number, shape and size of components in actual implementation. In actual implementation, the type, quantity and proportion of each component may be changed arbitrarily, and the component layout may also be more complicated.

[0052] The broadcast storm monitoring method, system, storage medium and terminal of the present invention timely monitor broadcast storms by collecting data in the network structure in real time, and discover and locate the scope and even the source of the broadcast storm, thereby facilitating the safe operation of the network. It should be noted that the broadcast storm monitoring terminal of the present invention can adopt a gateway machine. If the network management machine is a physical machine, multiple network cards can be used, and the remaining network cards can also be connected to the VLAN of the production environment.

[0053] like Figure 1 As shown, in one embodiment, the broadcast storm monitoring method of the present invention includes the following steps:

[0054] Step S1: Establish a network topology model.

[0055] Specifically, device identification and topology scanning are performed according to the network construction and operation conditions in actual scenarios to establish a network topology model.

[0056] Step S2: construct a broadcast storm monitoring framework based on the network topology model.

[0057] Specifically, the broadcast storm monitoring object is determined according to the network topology model, thereby constructing a broadcast storm monitoring framework.

[0058] Wherein, constructing a broadcast storm monitoring framework based on the network topology model includes the following steps:

[0059] 21) Acquire all network devices and corresponding interconnection ports based on the network topology model. The interconnection ports refer to the ports connected between the network devices obtained by scanning.

[0060] Among them, the counters of the number of incoming and outgoing broadcast packets and the number of lost packets of the interconnected ports of the network device need to change in real time. The update frequency of the flow data of the interconnected ports can be observed through commands. For example, the network device can provide 32-bit and 64-bit port flow data (counters). Since the 32-bit counter is easy to overflow and flip, try to use a 64-bit counter. It is necessary to determine whether the network device supports a 64-bit counter and whether the value of the counter is valid, because some devices have a return value, but the return value is always 0.

[0061] Recording the changes in interconnection ports helps to determine the port that caused the broadcast storm. Since broadcast storms will affect data collection after they occur (it is likely that data can only be collected after the storm disappears), the record of interconnection port status changes can only play an auxiliary role. Among them, if the operating status of the interconnection port between two collection points is inconsistent, it means that the interconnection port status has changed. If the status of the interconnection port at two collection points is down, it is also necessary to compare the port traffic difference between the two collection points. If the difference is not 0, it means that the port was up between the two collection points, but it returned to the down state before the next collection point.

[0062] 22) Acquire each divided VLAN and each VLAN port based on the network topology model.

[0063] The production network should be divided into different VLANs based on business or location factors. Monitoring terminals should be divided into separate VLANs to effectively prevent broadcast storms in the production network from affecting the network management system.

[0064] 23) Acquire a monitoring port based on the network topology model.

[0065] 24) Constructing the broadcast storm monitoring framework based on all the network devices and the corresponding interconnection ports, the VLAN ports and the monitoring ports.

[0066] The broadcast storm monitoring framework can be selected according to actual needs. For example, the network device can choose whether to monitor according to needs. It is recommended that all interconnection ports be monitored, but they can also be reduced as needed. At least two VLAN ports in each VLAN must be selected for monitoring. The monitoring port must be monitored.

[0067] Step S3: setting a data collection strategy within the broadcast storm monitoring framework.

[0068] Specifically, the data collection strategy includes a data collection cycle and data collection content for each monitored object. The data collection cycle needs to be selected according to the actual application scenario. If the cycle is too long, it will affect the accuracy of broadcast storm monitoring; if the cycle is too short, it will increase the system load.

[0069] In one embodiment, the data collection content of the network device includes CPU usage and ping connectivity. The data collection content of the interconnection port is the number of incoming broadcast packets per second (PPS), the number of outgoing broadcast packets per second (PPS), the number of incoming discarded packets per second (PPS), and the number of outgoing discarded packets per second (PPS). The data collection content of the VLAN port is the number of incoming broadcast packets (PPS), the number of outgoing broadcast packets (PPS), the number of incoming discarded packets (PPS), and the number of outgoing discarded packets (PPS). The data collection content of the monitoring port is the number of incoming broadcast packets (PPS).

[0070] Step S4: collecting data from each monitoring object within the broadcast storm monitoring framework based on the data collection strategy.

[0071] Specifically, data collection is mainly carried out through SNMP / SSH / ICMP and other protocols to periodically collect data from the observed devices.

[0072] Step S5: Perform broadcast storm monitoring based on the collected data.

[0073] Specifically, broadcast storm monitoring based on the collected data includes the following steps:

[0074] 51) Obtain the thresholds, weights, and storm trigger scores of each monitoring object.

[0075] The threshold, the weight and the storm trigger score may be set according to different application scenarios.

[0076] In one embodiment, the threshold of the number of incoming broadcast messages of the interconnection port and the VLAN port is 1200, and the weight is 1; the threshold of the number of outgoing broadcast messages is 1200, and the weight is 1; the threshold of the number of incoming discarded messages is 1, and the weight is 3; the threshold of the number of outgoing discarded messages is 1, and the weight is 3. The threshold of the CPU usage rate is 80%, and the weight is 10; the threshold of the ping connectivity is not connected, and the weight is 10. The threshold of the number of incoming broadcast messages of the monitoring port is 1200, and the weight is 30.

[0077] 52) Obtain the collected data of each monitoring object.

[0078] 53) Calculate the mean of the collected data and use the mean as a reference value for the monitoring content.

[0079] 54) Compare the reference value with the corresponding threshold value to obtain a comparison score.

[0080] When the reference value is greater than the corresponding threshold, the comparison score is 1, otherwise it is 0.

[0081] 55) Calculate the product of the comparison score of each monitored object and the corresponding weight, and use the product as the actual score of the monitored object.

[0082] 56) The final score of each monitored object is calculated according to 100*(1-(actual score / total score)), where the total score is the sum of the actual scores when the reference values ​​of each monitored object are greater than the threshold.

[0083] 57) When there is at least one final score that is smaller than the storm trigger score, it is determined that a broadcast storm is formed.

[0084] For example, the storm trigger score is 90. When the final score is less than 90, it is considered that the broadcast storm has been formed.

[0085] In the present invention, according to the broadcast storm monitoring framework, all covered devices and related data in the broadcast storm monitoring framework are periodically batch collected. All data collected in each period and the final score are taken as a snapshot. It should be noted that the frequency of snapshots is related to the data scale in the broadcast storm monitoring framework and the performance of the monitoring terminal. Within 1000 data collection points (each indicator of each device is a collection point), the reference frequency is 2 seconds. The snapshot data will be rolled and persistently stored to control the data scale and prevent excessive disk usage. The number of rolls can be distinguished by score. For example, snapshots above 98 points retain the most recent 200 times, and snapshots above 90 points retain the most recent 2000 times. This can better focus on abnormal situations and facilitate subsequent analysis.

[0086] When the broadcast storm is successfully detected, all existing snapshots will no longer be rolled back. Broadcast storms are located based on the snapshot data between adjacent broadcast storms. From the moment of triggering, snapshots are read forward to obtain the snapshots of the previous broadcast storm. All snapshots in this process are compared by device in chronological order to calculate the path of the broadcast storm spread, so as to infer the starting point of the broadcast storm.

[0087] The broadcast storm monitoring method of the present invention is further described below through specific embodiments.

[0088] Example 1: High frequency acquisition feasibility

[0089] Experimental purpose: To verify the feasibility of high-frequency acquisition

[0090] Test process:

[0091] Increase the frequency of collecting broadcast traffic on the specified port. The following is the snmpwalk command to obtain the port operation status. The -CT option is used to display the time taken for each request / response in the first column on the left in seconds.

[0092] Operating system: Windows. This Windows machine needs to access 192.168.200.2 through a WI-FI router. The specific information is as follows:

[0093]

[0094] Operating system: Linux. This Linux machine and the 192.168.200.2 switch are in the same network segment and are connected through multiple switches. The specific data is as follows:

[0095]

[0096]

[0097] As can be seen from the above, since the data collection time for a single OID generally does not exceed 0.1 seconds, and most of the time is around 0.001 seconds, it is feasible to increase the collection frequency to seconds. OID is the abbreviation of Object Identifier, which is a digital identifier used to uniquely identify network devices, protocols, applications, organizations, and any other types of objects.

[0098] Example 2: Validity of triggering algorithm

[0099] Test purpose: To verify the effectiveness of the trigger algorithm

[0100] Test process:

[0101] A total of 15 devices with 48 ports were selected as monitoring points. These devices form a multi-VLAN local area network. The ports of two switches were selected, and a loop was set at 17:19:15, which was released at the end of the experiment. After the loop was set, SNMP collection failed on 9 switches, and Ping was unavailable, but data could be collected on 6 devices. The first trigger was issued at 17:19:21, including five devices: 192.168.200.4, 192.168.200.6, 192.168.200.7, 192.168.200.8, and 192.168.200.10, 6 seconds after the storm was generated.

[0102] The specific information is as follows:

[0103]

[0104]

[0105] From the above, it can be seen that the results generated by the trigger algorithm fully meet the trigger conditions and can respond quickly.

[0106] The protection scope of the broadcast storm monitoring method described in the embodiment of the present invention is not limited to the execution order of the steps listed in this embodiment. All solutions implemented by adding, reducing or replacing steps in the prior art based on the principles of the present invention are included in the protection scope of the present invention.

[0107] An embodiment of the present invention also provides a broadcast storm monitoring system, which can implement the broadcast storm monitoring method described in the present invention. However, the implementation device of the broadcast storm monitoring system described in the present invention includes but is not limited to the structure of the broadcast storm monitoring system listed in this embodiment. All structural deformations and replacements of the prior art made according to the principles of the present invention are included in the protection scope of the present invention.

[0108] like Figure 2 As shown, in one embodiment, the broadcast storm monitoring system of the present invention includes an establishment module 21 , a construction module 22 , a setting module 23 , a collection module 24 and a monitoring module 25 .

[0109] The establishing module 21 is used to establish a network topology model.

[0110] The construction module 22 is connected to the establishment module 21 and is used to construct a broadcast storm monitoring framework based on the network topology model.

[0111] The setting module 23 is used to set the data collection strategy within the broadcast storm monitoring framework.

[0112] The collection module 24 is connected to the construction module 22 and the setting module 23, and is used to collect data from each monitoring object in the broadcast storm monitoring framework based on the data collection strategy.

[0113] The monitoring module 25 is connected to the collecting module 24 and is used for performing broadcast storm monitoring based on the collected data.

[0114] Among them, the structures and principles of the establishment module 21, the construction module 22, the setting module 23, the collection module 24 and the monitoring module 25 correspond one to one with the steps in the above-mentioned broadcast storm monitoring method, so they are not repeated here.

[0115] It should be noted that it should be understood that the division of the various modules of the above device is only a division of logical functions. In actual implementation, they can be fully or partially integrated into one physical entity, or they can be physically separated. And these modules can all be implemented in the form of software called by processing elements, or they can all be implemented in the form of hardware, or some modules can be implemented in the form of software called by processing elements, and some modules can be implemented in the form of hardware. For example: the x module can be a separately established processing element, or it can be integrated in a certain chip of the above device. In addition, the x module can also be stored in the memory of the above device in the form of program code, and called and executed by a certain processing element of the above device. The implementation of other modules is similar. These modules can be integrated together in whole or in part, or they can be implemented independently. The processing element described here can be an integrated circuit with signal processing capabilities. In the implementation process, each step of the above method or each module above can be completed by an integrated logic circuit of hardware in the processor element or instructions in the form of software. The above modules may be one or more integrated circuits configured to implement the above methods, such as one or more application specific integrated circuits (ASIC), one or more microprocessors (DSP), one or more field programmable gate arrays (FPGA), etc. When a module is implemented in the form of a processing element scheduling program code, the processing element may be a general-purpose processor, such as a central processing unit (CPU) or other processor that can call program code. These modules may be integrated together and implemented in the form of a system-on-a-chip (SOC).

[0116] The storage medium of the present invention stores a computer program, which implements the above-mentioned broadcast storm monitoring method when executed by a processor. Preferably, the storage medium includes: ROM, RAM, disk, USB flash drive, memory card or optical disk and other media that can store program codes.

[0117] like Figure 3 As shown, in one embodiment, the broadcast storm monitoring terminal of the present invention includes: a processor 31 and a memory 32 .

[0118] The memory 32 is used to store computer programs, including ROM, RAM, disk, USB flash drive, memory card, optical disk, and other media that can store program codes.

[0119] The processor 31 is connected to the memory 32 and is used to execute the computer program stored in the memory so that the broadcast storm monitoring terminal executes the above-mentioned broadcast storm monitoring method.

[0120] Preferably, the processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components.

[0121] When the broadcast storm monitoring terminal uses a network management machine, since the network management machine itself is also in the monitored network, when a broadcast storm occurs, data collection requests for other devices in the network may also be affected. A typical situation is that the starting point of the network storm is in the VLAN where the network management machine is located, and the network management machine will immediately be unable to obtain data from all other devices. At this time, there is not enough snapshot data to support backtracking and positioning, which is not conducive to tracing the cause. Therefore, in terms of network management machine deployment, when there is only one network management machine, it is recommended to place it in an independent VLAN, or on a core network device with storm suppression enabled. In a network environment with a smaller scale or simple structure, usually one network management machine can support all data collection and analysis work. However, in actual situations, some devices have a low response speed due to network or geographical reasons, and since broadcast storm monitoring requires high-frequency monitoring, it is necessary to get a fast response from the device; some networks are very large, and the number of devices that need to be accessed is large, and the amount of calculation is large; some network topologies are relatively complex, or the robustness is low. In these situations, the network topology needs to be divided into different monitoring perspectives or areas according to the structural characteristics, and a separate network management machine is used to perform data sampling, independent analysis and calculation to improve sensitivity and accuracy.

[0122] In summary, the broadcast storm monitoring method, system, storage medium and terminal of the present invention can monitor broadcast storms in real time, reducing the workload of network management and operation and maintenance personnel; can timely discover and locate the scope and even the source of broadcast storms, and help to solve related problems in a timely manner. Therefore, the present invention effectively overcomes various shortcomings in the prior art and has a high industrial utilization value.

[0123] The above embodiments are merely illustrative of the principles and effects of the present invention, and are not intended to limit the present invention. Anyone familiar with the art may modify or alter the above embodiments without departing from the spirit and scope of the present invention. Therefore, all equivalent modifications or alterations made by a person of ordinary skill in the art without departing from the spirit and technical concept disclosed by the present invention shall still be covered by the claims of the present invention.

Claims

1. A broadcast storm monitoring method, characterized in that: The method comprises the following steps: Establish network topology model; Constructing a broadcast storm monitoring framework based on the network topology model; Setting a data collection strategy within the broadcast storm monitoring framework; Based on the data collection strategy, data is collected from each monitoring object within the broadcast storm monitoring framework; Perform broadcast storm monitoring based on the collected data.

2. The broadcast storm monitoring method according to claim 1, characterized in that: Building a broadcast storm monitoring framework based on the network topology model includes the following steps: Acquire all network devices and corresponding interconnection ports based on the network topology model; Acquire each divided VLAN and each VLAN port based on the network topology model; Acquire a monitoring port based on the network topology model; The broadcast storm monitoring framework is constructed based on all the network devices and the corresponding interconnection ports, the VLAN ports and the monitoring ports.

3. The broadcast storm monitoring method according to claim 2, characterized in that: Setting the data collection strategy within the broadcast storm monitoring framework includes the following steps: Set the data collection cycle; Set the data collection content for each monitoring object.

4. The broadcast storm monitoring method according to claim 3, characterized in that: The data collection content of the network equipment includes CPU usage and ping connectivity; the data collection content of the interconnection port is the number of incoming broadcast packets per second, the number of outgoing broadcast packets per second, the number of incoming discarded packets per second, and the number of outgoing discarded packets per second; the data collection content of the VLAN port is the number of incoming broadcast packets, the number of outgoing broadcast packets, the number of incoming discarded packets, and the number of outgoing discarded packets; the data collection content of the monitoring port is the number of incoming broadcast packets.

5. The broadcast storm monitoring method according to claim 1, characterized in that: Broadcast storm monitoring based on the collected data includes the following steps: Obtain the thresholds, weights, and storm trigger scores of each monitoring object; Obtaining collected data of each monitoring object; Calculate the mean of the collected data and use the mean as a reference value for the monitoring content; Comparing the reference value with the corresponding threshold value to obtain a comparison score; Calculate the product of the comparison score of each monitored object and the corresponding weight, and use the product as the actual score of the monitored object; The final score of each monitored object is calculated according to 100*(1-(actual score / total score)), where the total score is the sum of the actual scores when the reference values ​​of each monitored object are greater than the threshold; When there is at least one final score that is smaller than the storm trigger score, it is determined that a broadcast storm is formed.

6. The broadcast storm monitoring method according to claim 5, characterized in that: The method also includes taking snapshots of the collected data and the final score, and performing rolling storage.

7. The broadcast storm monitoring method according to claim 6, characterized in that: The method also includes locating the broadcast storm based on snapshot data between adjacent broadcast storms when a broadcast storm is detected.

8. A broadcast storm monitoring system, characterized in that: The system includes a building module, a construction module, a setting module, a collection module and a monitoring module; The establishment module is used to establish a network topology model; The construction module is used to construct a broadcast storm monitoring framework based on the network topology model; The setting module is used to set the data collection strategy within the broadcast storm monitoring framework; The acquisition module is used to collect data from each monitoring object within the broadcast storm monitoring framework based on the data acquisition strategy; The monitoring module is used to perform broadcast storm monitoring based on the collected data.

9. A storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the broadcast storm monitoring method according to any one of claims 1 to 7 is implemented.

10. A broadcast storm monitoring terminal, characterized in that: include: Processor and memory; The memory is used to store computer programs; The processor is used to execute the computer program stored in the memory, so that the broadcast storm monitoring terminal executes the broadcast storm monitoring method according to any one of claims 1 to 7.

Images