A fault handling method, apparatus and electronic device

Abstract

This invention provides a fault handling method, apparatus, and electronic device. The method includes: receiving a fault message sent when a first device malfunctions, wherein the first device is at least one of a plurality of monitored devices managed by a management device, and the fault message is used to indicate that the value of a first monitoring indicator when the first device transmits data is greater than or equal to a first monitoring threshold corresponding to the first monitoring indicator; obtaining at least one configuration information associated with the data transmitted by the first device; obtaining historical abnormal data of the first monitoring indicator associated with each configuration information; and determining, based on the historical abnormal data, whether to obtain the address information of the attacked device that caused the first device malfunction.

Description

Technical Field

[0001] This invention relates to the field of mobile communication technology, and in particular to a fault handling method, apparatus, and electronic device. Background Technology

[0002] With the deepening of digital development, the scale of equipment in operation in various organizations has gradually increased, growing by nearly 10 to 100 times compared to ten years ago. Even though equipment operation and maintenance models have evolved from manual to tool-based and platform-based models, they still cannot meet the monitoring requirements of current large-scale networks.

[0003] For example, large-scale networks include a large number of devices, and the application relationships between these devices are often complex with multiple layers of configuration. Therefore, when a network device fails, how to more reasonably trace the source of the fault is a key issue that needs to be addressed. Summary of the Invention

[0004] This invention provides a fault handling method, apparatus, and electronic device to solve at least some of the problems described above.

[0005] In a first aspect, embodiments of the present invention provide a fault handling method, including:

[0006] The system receives a fault message sent when a first device malfunctions, wherein the first device is at least one of a plurality of monitored devices managed by the management device, and the fault message is used to indicate that the value of a first monitoring indicator when the first device transmits data is greater than or equal to a first monitoring threshold corresponding to the first monitoring indicator.

[0007] Obtain at least one configuration information associated with the data transmitted by the first device;

[0008] Obtain historical abnormal data for each of the first monitoring indicators associated with each of the configuration information;

[0009] Based on the historical anomaly data, determine whether to obtain the address information of the attacked device that caused the first device malfunction.

[0010] Secondly, embodiments of the present invention provide a fault handling method, including:

[0011] A fault message is sent to the management device, wherein the fault message is used to indicate that the value of a first monitoring indicator when the monitored device transmits data is greater than or equal to a first monitoring threshold corresponding to the first monitoring indicator.

[0012] Thirdly, embodiments of the present invention provide a fault handling apparatus for use in management equipment, the apparatus comprising:

[0013] The first receiving module is used to receive a fault message sent when the first device malfunctions, wherein the first device is at least one of a plurality of monitored devices managed by the management device, and the fault message is used to indicate that the value of a first monitoring indicator when the first device transmits data is greater than or equal to a first monitoring threshold corresponding to the first monitoring indicator.

[0014] The first acquisition module is used to acquire at least one configuration information associated with the data transmitted by the first device;

[0015] The second acquisition module is used to acquire historical abnormal data of the first monitoring indicator associated with each of the configuration information.

[0016] The determination module is used to determine, based on the historical anomaly data, whether to obtain the address information of the attacked device that caused the first device malfunction.

[0017] Fourthly, embodiments of the present invention provide a fault handling device applied to a monitored device, the device comprising:

[0018] The first sending module is used to send a fault message to the management device, wherein the fault message is used to indicate that the value of a first monitoring indicator when the monitored device transmits data is greater than or equal to a first monitoring threshold corresponding to the first monitoring indicator.

[0019] Fifthly, embodiments of the present invention provide an electronic device, including a memory, a transceiver, and a processor:

[0020] The memory is used to store computer programs; the transceiver is used to send and receive data under the control of the processor; the processor is used to read the computer program in the memory and execute the fault handling method described in the first aspect above, or execute the fault handling method described in the second aspect above.

[0021] In a sixth aspect, embodiments of the present invention provide a processor-readable storage medium storing a computer program for causing the processor to perform the fault handling method described in the first aspect or the fault handling method described in the second aspect.

[0022] In an embodiment of the present invention, the management device may receive a fault message sent when a first device (i.e., multiple devices managed by the management device) fails. The fault message is used to indicate that the value of a first monitoring indicator when the first device transmits data is greater than or equal to a first monitoring threshold corresponding to the first monitoring indicator. Then, the management device obtains at least one configuration information associated with the data transmitted by the first device, and obtains historical abnormal data of the first monitoring indicator associated with each configuration information, thereby determining whether to obtain the address information of the attacked device that caused the failure of the first device based on the historical abnormal data.

[0023] Therefore, in this embodiment of the invention, after receiving the fault message sent by the first device, the management device does not immediately obtain the address information of the attacked device that caused the fault of the first device, that is, it does not immediately perform fault tracing. Instead, it obtains at least one configuration information associated with the data transmitted by the first device, and obtains historical abnormal data of the first monitoring indicator from different directions represented by different configuration information. Then, based on the historical abnormal data, it decides whether to perform fault tracing, so that fault tracing can be performed at a more reasonable time, rather than immediately tracing the fault when it occurs, reducing the probability of unreasonable tracing, thereby further saving network resources. Attached Figure Description

[0024] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 A flowchart of a fault handling method provided in an embodiment of the present invention;

[0026] Figure 2 A flowchart of another fault handling method provided in an embodiment of the present invention;

[0027] Figure 3 This is a schematic diagram of the network topology to which the fault handling method of this embodiment of the invention applies;

[0028] Figure 4 This is a structural block diagram of a fault handling device provided in an embodiment of the present invention;

[0029] Figure 5 This is a structural block diagram of another fault handling device provided in an embodiment of the present invention;

[0030] Figure 6 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0031] In this embodiment of the invention, the term "and / or" describes the relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The character " / " generally indicates that the preceding and following associated objects have an "or" relationship.

[0032] In the embodiments of this application, the term "multiple" refers to two or more, and other quantifiers are similar.

[0033] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0034] This application provides a service switching method and apparatus to solve the problem in the prior art that when a faulty UPF network element carrying a service experiences a device-level failure, the only solution is to manually delete the faulty UPF configuration, resulting in a long service interruption time.

[0035] The method and apparatus are based on the same concept of the application. Since the methods and apparatus solve problems in similar ways, the implementation of the apparatus and methods can refer to each other, and the repeated parts will not be described again.

[0036] Figure 1 This diagram illustrates a fault handling method according to an embodiment of the present invention. This method can be applied to management equipment, such as... Figure 1 As shown, the method may include the following steps 101 to 102:

[0037] Step 101: Receive the fault message sent when the first device malfunctions.

[0038] The first device is at least one of a plurality of monitored devices managed by the management device. Here, the monitored devices may include at least one of servers and other non-server devices (e.g., terminal devices).

[0039] It is understood that the monitored device may include local monitored devices and remote monitored devices.

[0040] Additionally, the fault message indicates that the value of a first monitoring indicator when the first device transmits data is greater than or equal to a first monitoring threshold corresponding to the first monitoring indicator. Here, the first monitoring indicator can be CPU utilization or memory usage. For example, when the first device detects that the CPU utilization is greater than or equal to the monitoring threshold corresponding to the CPU utilization, it can send a fault message to the management device; or, when the first device detects that the memory usage is greater than or equal to the monitoring threshold corresponding to the memory usage, it can send a fault message to the management device.

[0041] Step 102: Obtain at least one configuration information associated with the data transmitted by the first device.

[0042] The data transmitted by the first device corresponds to or is associated with at least one configuration information. Optionally, the configuration information includes at least one of the following: source address, destination address, source port, destination port, and the protocol used when transmitting data. Here, the source address is the source address of the data sent by the first device; the destination address is the address of the sending device of the data received by the first device; the source port is the source port of the data sent by the first device; and the destination port is the port of the sending device of the data received by the first device.

[0043] Step 103: Obtain the historical abnormal data of the first monitoring indicator associated with each of the configuration information.

[0044] Among them, during the historical operation of the first device, when transmitting data, there is corresponding configuration information (such as source address, destination address, source port, destination port, and protocol used), and there will also be abnormal data in the value of the first monitoring indicator (i.e., historical data) of the data transmitted during the historical operation.

[0045] It should be noted that the monitoring threshold used by the first device for the same monitoring indicator may be different in different operating time periods. Therefore, when the first device transmits data, it includes historical abnormal data of the first monitoring indicator, including data that are greater than or equal to the monitoring threshold used in the corresponding time period in different operating time periods.

[0046] Step 104: Based on the historical anomaly data, determine whether to obtain the address information of the attacked device that caused the first device malfunction.

[0047] In step 104, based on historical anomaly data, it is determined whether to obtain the address information of the attacked device that caused the first device failure, which is to evaluate whether to perform fault tracing based on historical anomaly data.

[0048] As can be seen from steps 101 to 104 above, in the embodiments of the present invention, the management device can receive a fault message sent when the first device (i.e., multiple devices managed by the management device) fails. The fault message is used to indicate that the value of the first monitoring indicator when the first device transmits data is greater than or equal to the first monitoring threshold corresponding to the first monitoring indicator. Then, the management device obtains at least one configuration information associated with the data transmitted by the first device, and obtains historical abnormal data of the first monitoring indicator associated with each configuration information, thereby determining whether to obtain the address information of the attacked device that caused the failure of the first device based on the historical abnormal data.

[0049] Therefore, in this embodiment of the invention, after receiving the fault message sent by the first device, the management device does not immediately obtain the address information of the attacked device that caused the fault of the first device, that is, it does not immediately perform fault tracing. Instead, it obtains at least one configuration information associated with the data transmitted by the first device, and obtains historical abnormal data of the first monitoring indicator from different directions represented by different configuration information. Then, based on the historical abnormal data, it decides whether to perform fault tracing, so that fault tracing can be performed at a more reasonable time, rather than immediately tracing the fault when it occurs, reducing the probability of unreasonable tracing, thereby further saving network resources.

[0050] Optionally, before step 101: "receiving the fault message sent when the first device malfunctions", the method further includes:

[0051] The monitoring period, monitoring indicators, and monitoring thresholds corresponding to the monitoring indicators are converted into a data structure file that can be accepted by the NETCONF network configuration protocol.

[0052] Send the data structure file to the first device;

[0053] The first monitoring indicator is one of the monitoring indicators in the data structure file.

[0054] The monitoring metrics here can include at least one of the following: CPU utilization, memory usage, port information, device IP, and board information. In this way, the monitoring metrics can comprehensively and accurately reflect the operating status of the monitored device. Among them, the board information is related to the CPU utilization, so it can be accurately determined which board has a problem.

[0055] Furthermore, NETCONF's Remote Procedure Call (RPC) layer provides a simple, transport protocol-independent mechanism for encoding RPC modules. That is, by using... <rpc>and <rpc-reply>The element encapsulates the request and response data (i.e., the content of the operational and content layers) of the monitored and managed devices in the NETCONF protocol. Under normal circumstances... <rpc-reply>The element encapsulates the configuration data required by the management device. When the management device request message contains errors or the server fails to process it, the server... <rpc-reply>The element will encapsulate a file containing detailed error information. <rpc-error>The elements provide feedback to the management equipment.

[0056] Furthermore, the NETCONF protocol's command set consists of a series of commands for reading and modifying device configuration data, as well as reading status data. Commands are communicated via RPCs and responded to with RPC replies. That is, an RPC reply must be responded to by an RPC before it can return. A configuration operation must consist of a series of RPCs, each with a corresponding response RPC.

[0057] Therefore, in this embodiment of the invention, the monitored devices within the network can be managed using the NETCONF protocol. On devices supporting the NETCONF protocol, the set of NETCONF Remote Procedure Call (RPC) message-related instructions is written into a program to receive and respond to messages. This enables the configuration of monitoring indicators, monitoring cycles, and monitoring thresholds for the monitored devices via the NETCONF protocol, thus achieving the subscription to monitoring events for the monitored devices.

[0058] Additionally, once a NETCONF session begins, the managing device and the monitored device exchange a set of "features." These features include information such as a list of supported NETCONF protocol versions, the existence of alternative data, and the modifiable nature of running data storage. Furthermore, features are defined in the NETCONF Request For Comments (RFC): developers can add additional features by following the specifications described in the RFC. This allows for greater flexibility in setting monitoring metrics (e.g., adding, reducing, or modifying metrics), monitoring cycles, and monitoring thresholds using the NETCONF protocol, thereby enabling the collection of more diverse data.

[0059] In addition, monitoring events can be subscribed to via the NETCONF protocol, enabling second-level monitoring.

[0060] Optionally, after step 101 "receiving the fault message sent when the first device malfunctions", the method further includes:

[0061] The data structure file is resent to the first device.

[0062] In this system, if a monitored device subscribes to monitoring events via the NETCONF protocol and the value of a monitored metric exceeds its corresponding monitoring threshold, the subscription will expire. Therefore, to ensure that the monitored device can still send a fault message to the management device when a monitored metric exceeds its threshold in the future, the management device can then resubscribe to monitoring events via the NETCONF protocol upon receiving the fault message.

[0063] It is understandable that after receiving the above fault message, the management device may either resend the data structure file to the first device or regenerate the data structure file to all the monitored devices under its management.

[0064] Optionally, step 102, "obtaining at least one configuration information associated with the data transmitted by the first device," includes:

[0065] When the number of times the data structure file is sent to the first device reaches a preset number, and the value of the first monitoring indicator when the first device transmits data is still greater than or equal to the first monitoring threshold, at least one configuration information associated with the data transmitted by the first device is obtained.

[0066] If the number of times the data structure file is sent to the first device reaches a preset number, and the value of the first monitoring indicator when the first device transmits data is still greater than or equal to the first monitoring threshold, it indicates that the fault of the first device has not been resolved even after the preset number of times the monitoring event has been resubscribed. This suggests that the fault is not caused by network jitter, and in this case, fault tracing is required, which means "obtaining at least one configuration information associated with the data transmitted by the first device".

[0067] If the number of times the data structure file is sent to the first device reaches a preset number, and the value of the first monitoring indicator when the first device transmits data is less than the first monitoring threshold, it means that when the number of times the monitoring event is resubscribed reaches a preset number, the fault of the first device has been resolved. This indicates that the fault was not caused by network jitter, and the fault caused by network jitter has been resolved. There is no need to trace the source of the fault. Therefore, in this case, it is not necessary to "obtain at least one configuration information associated with the data transmitted by the first device".

[0068] Therefore, in the embodiments of the present invention, the program can repeatedly execute the RPC message of the NETCONF protocol to subscribe to alarms again, so as to prevent alarm subscription failure caused by network jitter.

[0069] Optionally, step 104, "determining whether to obtain the address information of the attacked device that caused the first device malfunction based on the historical anomaly data," includes:

[0070] The historical anomaly data associated with the i-th configuration information is stored in the i-th set, where i is an integer from 1 to N, and N represents the number of the at least one configuration information.

[0071] Based on the target threshold and using the k-nearest neighbor algorithm prediction model, the historical abnormal data in the i-th set are classified to obtain the i-th number of historical abnormal data in the i-th set that is greater than or equal to the target threshold.

[0072] If the ratio of the i-th quantity to the number of historical abnormal data in the i-th set is greater than or equal to a preset ratio, the i-th set is determined to be an abnormal set.

[0073] If the number of the anomaly set is greater than or equal to a preset number, determine and obtain the address information of the attacked device that caused the first device to malfunction;

[0074] If the number of anomalies is less than the preset number, the step of obtaining the address information of the attacked device that caused the first device to malfunction is skipped.

[0075] For example, when the configuration information includes source address, destination address, source port, destination port, and the protocol used, the five sets mentioned above can be obtained. If there are three abnormal sets among these five sets, it is necessary to trace the source of the fault.

[0076] Among them, the k-nearest neighbor algorithm prediction model is the k-nearest neighbor classifier. Its basic idea is to search in the sample space for a sample x whose class is not determined, and find the k closest samples to the sample whose class is not determined. The class to be classified is determined by the class to which the sample belongs.

[0077] This shows that the main problems in k-nearest neighbor classification are determining the appropriate sample set, distance function, combination function, and the value of k. For various types of attributes, the distance function can refer to the sample similarity measurement formula in cluster analysis, while the combination function can use simple unweighted voting or weighted voting methods. In simple unweighted voting, the influence of each nearest neighbor x1 on the classification of x is considered the same. By counting the categories to which the k nearest neighbors x belong, x is assigned to the class with the highest count.

[0078] in, η represents a counting function, if x i ∈C j Then η(x) i ∈C j ) = 1; otherwise η(x) i ∈C j =0. When the counts of the categories are the same, a category is randomly selected for x.

[0079] in addition, Here, the weight is generally defined as w. i =1 / d(x, x) i ) 2 d(x, x) i ), representing the sample x and its nearest neighbor x. i The distance.

[0080] Furthermore, the k-nearest neighbor classifier makes predictions based on local data and is sensitive to noise. The choice of k value is data-dependent. An excessively large k value can reduce the impact of noise, but it results in a large number of nearest neighbors for unclassified samples, potentially leading to classification errors. Conversely, an excessively small k value may cause voting to become ineffective or susceptible to noise. A good k value can be obtained through various heuristic techniques.

[0081] Finding the nearest neighbors of a given sample might involve calculating the distances between all pairs of samples. To effectively discover nearest neighbors, clustering algorithms can be used to classify the training set. If the centers of two clusters are far apart, samples in the corresponding clusters are generally unlikely to be neighbors. Finding the nearest neighbors of a given sample simply requires calculating the distances between samples in adjacent clusters.

[0082] As described above, regarding the aforementioned step of "classifying the historical abnormal data in the i-th set according to the target threshold and using the k-nearest neighbor algorithm prediction model to obtain the i-th number of historical abnormal data in the i-th set that is greater than or equal to the target threshold," if the current threshold is X, and the data in the i-th set includes {Y1~Y100}, then classifying the historical abnormal data in the i-th set based on the target threshold X and using the k-nearest neighbor algorithm prediction model is as follows:

[0083] In Y1 to Y100, find the k samples that are closest to the target threshold X, where k is the i-th number of historical abnormal data that are greater than or equal to the target threshold X in the i-th set.

[0084] It should be noted that, for the aforementioned sets, if a set contains a massive amount of historical anomaly data, iterating through the data in that set and comparing it with the target threshold to obtain data in that set that is greater than or equal to the target threshold will take a considerable amount of time, thus prolonging the fault handling time. However, in this embodiment of the invention, the k-nearest neighbor algorithm prediction model is used to obtain data in the set that is greater than or equal to the target threshold, which can shorten the processing time of this process, thereby shortening the fault handling time.

[0085] Optionally, the method further includes:

[0086] Once the address information of the attacked device that caused the first device malfunction is determined, an attack tracing strategy is executed to obtain the address information of the attacked device.

[0087] The process of implementing the attack attribution strategy may include the following:

[0088] First, query the dependency information associated with the attack tracing strategy, that is, the traces and locations associated with the tracing strategy. Then, save the obtained trace and location information into variables e and d respectively. According to the process attribute of the tracing strategy and e and d, execute the attack tracing strategy, and finally obtain the address information (such as IP address) of the attacked device.

[0089] For example, Neo4j can be used as graph data to store a cybersecurity knowledge base (MDATA), the data can be queried using the declarative (Cypher) query language, and attack attribution algorithms can be implemented using the computer programming language (Python). Figure 3 As shown, the principle is to simulate an attacker using a remotely controlled computer (192.168.134.128) as the attacking host, discovering a Structured Query Language (SQL) injection vulnerability in the server (10.2.1.35), and using this vulnerability to inject a reverse shell into the server, thus enabling the server to actively communicate with the controlling host (192.168.134.130) through the reverse shell port.

[0090] In the aftermath of an attack, attribution investigators aim to identify who attacked the server and who is controlling it. Assuming the server has Apache server application software installed, investigators first use the MDATA network security knowledge base to search for attribution strategies related to Apache servers. Then, using attack attribution algorithms, they can directly obtain the IP addresses of the attacking and controlling hosts.

[0091] Figure 2 This diagram illustrates a fault handling method according to an embodiment of the present invention. This method can be applied to management equipment, such as... Figure 2 As shown, the method may include the following steps 201 to 202:

[0092] Step 201: Send a fault message to the management device.

[0093] The fault message is used to indicate that the value of a first monitoring indicator when the monitored device transmits data is greater than or equal to a first monitoring threshold corresponding to the first monitoring indicator.

[0094] Here, the monitored device may include at least one of a server or other non-server devices (such as terminal devices).

[0095] In addition, the first monitoring indicator can be CPU utilization or memory usage. For example, when the monitored device detects that the CPU utilization is greater than or equal to the monitoring threshold corresponding to the CPU utilization, it can send a fault message to the management device; or, when the monitored device detects that the memory usage is greater than or equal to the monitoring threshold corresponding to the memory usage, it can send a fault message to the management device.

[0096] In addition, after receiving a fault message, the management device can obtain at least one configuration information associated with the data transmitted by the monitored device that sent the fault message, and obtain historical abnormal data of the first monitoring indicator associated with each configuration information. Then, based on the historical abnormal data, it can determine whether to obtain the address information of the attacked device that caused the fault in the monitored device that sent the fault message.

[0097] Therefore, in this embodiment of the invention, after receiving the fault message sent by the first device, the management device does not immediately obtain the address information of the attacked device that caused the fault of the first device, that is, it does not immediately perform fault tracing. Instead, it obtains at least one configuration information associated with the data transmitted by the first device, and obtains historical abnormal data of the first monitoring indicator from different directions represented by different configuration information. Then, based on the historical abnormal data, it decides whether to perform fault tracing, so that fault tracing can be performed at a more reasonable time, rather than immediately tracing the fault when it occurs, reducing the probability of unreasonable tracing, thereby further saving network resources.

[0098] Optionally, before step 201 "sending a fault message to the management device", the method further includes:

[0099] The system receives a data structure file sent by the management device, wherein the data structure file is a data structure file that converts the monitoring period, monitoring indicators, and monitoring thresholds corresponding to the monitoring indicators into a data structure file that can be accepted by the NETCONF protocol for network configuration.

[0100] Parse the data structure file to obtain the monitoring period, the monitoring indicators, and the monitoring thresholds;

[0101] According to the monitoring period, the values ​​of the monitoring indicators are collected, and the values ​​of the monitoring indicators are compared with the monitoring thresholds corresponding to the monitoring indicators;

[0102] The first monitoring indicator is one of the monitoring indicators in the data structure file.

[0103] The monitoring metrics here can include at least one of the following: CPU utilization, memory usage, port information, device IP, and board information. In this way, the monitoring metrics can comprehensively and accurately reflect the operating status of the monitored device. Among them, the board information is related to the CPU utilization, so it can be accurately determined which board has a problem.

[0104] Therefore, in this embodiment of the invention, the monitored devices within the network can be managed by using the NETCONF protocol, which enables the configuration of monitoring indicators, monitoring cycles, and monitoring thresholds for the monitored devices through the NETCONF protocol, thereby enabling the subscription of monitoring events for the monitored devices.

[0105] Optionally, after step 201 "sending a fault message to the management device", the method further includes:

[0106] Receive the data structure file resent by the management device.

[0107] In this system, if a monitored device subscribes to monitoring events via the NETCONF protocol and the value of a monitored metric exceeds its corresponding monitoring threshold, the subscription will expire. Therefore, to ensure that the monitored device can still send a fault message to the management device when a monitored metric exceeds its threshold in the future, the management device can then resubscribe to monitoring events via the NETCONF protocol upon receiving the fault message.

[0108] It is understandable that after receiving the above fault message, the management device may either resend the structure file to the first device or regenerate the data structure file to all monitored devices under its management.

[0109] Therefore, in the embodiments of the present invention, the program can repeatedly execute the RPC message of the NETCONF protocol to subscribe to alarms again, so as to prevent alarm subscription failure caused by network jitter.

[0110] Optionally, after step 201 "sending a fault message to the management device", the method further includes:

[0111] If the value of the first monitoring indicator is less than the first monitoring threshold when the monitored device is transmitting data, the fault information will be stored in the historical database.

[0112] The fault information includes at least one of the following: the value of the first monitoring indicator, the occurrence time, the recovery time, and the fault content. Here, the fault content indicates the network effect (e.g., network lag) resulting from the value of the first monitoring indicator being greater than or equal to a first monitoring threshold.

[0113] Therefore, after the monitored equipment stores the fault information in the historical database, if it is necessary to query the relevant information of the fault, the relevant information in the historical database can be retrieved.

[0114] Furthermore, after receiving a fault message from the monitored device that has malfunctioned, the management device can obtain at least one configuration information associated with the data transmitted by the monitored device that malfunctioned, thereby obtaining historical abnormal data of the first monitoring indicator associated with each configuration information. Here, the management device can extract historical abnormal data of the first monitoring indicator associated with each configuration information from the aforementioned historical database.

[0115] In summary, the specific implementation method of the fault handling method of the present invention can be described as follows:

[0116] The management device converts monitoring indicators, monitoring cycles, and corresponding monitoring thresholds into a data structure file acceptable by the NETCONF protocol, and then distributes it to multiple servers managed by the management device to achieve a single subscription to monitoring events; (for example, subscribing to monitoring events on a server via program commands, i.e., setting the monitoring threshold for the "ColumnCondition" field; and setting the "interval" parameter to 1 second, thereby completing the second-level inspection settings for the server.)

[0117] The server parses the data structure file to obtain the monitoring indicators, monitoring period, and monitoring threshold. It then collects the values ​​of the monitoring indicators according to the monitoring period to determine whether the monitoring indicators exceed the corresponding monitoring thresholds. If the first monitoring indicator exceeds the first monitoring threshold corresponding to the first monitoring indicator, the server sends a fault message to the management device to indicate that the value of the first monitoring indicator exceeds the first monitoring threshold.

[0118] Once the faulty server is recovered, it stores the fault information in the historical database. This fault information includes the values ​​of monitoring indicators that exceed the monitoring threshold, the fault content, the occurrence time, and the recovery time.

[0119] In addition, after receiving the fault message, the management device resubscribes to the monitoring events of the server (i.e., resends the above data structure file to the server);

[0120] When the management device detects that the number of times the monitoring event has been resubscribed has reached a preset number, it obtains the configuration information associated with the data transmitted by the monitored device that has malfunctioned, such as the five-tuple information (source address, destination address, source port, destination port, and protocol used). Then, it extracts the historical abnormal data of the first monitoring indicator associated with each piece of information in the five-tuple information from the historical database and stores them into five sets respectively.

[0121] Then, based on the current threshold, the management device uses a pre-established k-nearest neighbor algorithm prediction model to divide the data in each set into abnormal data and normal data. When the proportion of abnormal data in a set is greater than a preset ratio, that set is an abnormal set.

[0122] When the number of anomalies exceeds a preset number, the attack tracing strategy is executed to obtain the address information of the attacked device that caused the failure of the monitored device.

[0123] The process of implementing the attack tracing strategy is described above and will not be repeated here.

[0124] In summary, the embodiments of the present invention, addressing the practical issues of poor timeliness and low efficiency in tracing and locating faults between local monitoring equipment and associated remote equipment, adopt the following solution:

[0125] 1. By adopting the NETCONF management protocol, local and remote servers (CPEs) within the network are managed. On CPEs that support the NETCONF protocol, the set of NETCONF RPC message related instructions are written into the program to execute the receiving and response of messages, and to subscribe to monitoring events and set up second-level monitoring.

[0126] 2. If the management device receives a fault message and the number of repeated subscriptions to the NETCONF protocol exceeds the preset number, and the fault is still not recovered, the network traffic quintuple (i.e., source address, destination address, source port, destination port, and protocol used) is analyzed. The k-nearest neighbor algorithm prediction model is used, combined with the current monitoring threshold, to comprehensively determine the proportion of abnormal data in each data set. This determines whether fault tracing is necessary. If fault tracing is required, the MDATA network security knowledge base is queried to execute the tracing strategy corresponding to the attack threat, find the traces and locations left by the attack, and finally locate the attacked device.

[0127] Therefore, the fault handling method of this invention introduces the more efficient NETCONF protocol combined with second-level monitoring and alarm subscription to prevent network jitter. This allows for more intelligent and efficient fault tracing, thereby improving the operational and maintenance capabilities of network devices.

[0128] The above describes the service switching method provided by the embodiments of the present invention. The service switching device provided by the embodiments of the present invention will be described below with reference to the accompanying drawings.

[0129] See Figure 4 The present invention also provides a fault handling device for use in management equipment, the fault handling device comprising the following modules:

[0130] The first receiving module 401 is used to receive a fault message sent when the first device malfunctions, wherein the first device is at least one of a plurality of monitored devices managed by the management device, and the fault message is used to indicate that the value of a first monitoring indicator when the first device transmits data is greater than or equal to a first monitoring threshold corresponding to the first monitoring indicator.

[0131] The first acquisition module 402 is used to acquire at least one configuration information associated with the data transmitted by the first device;

[0132] The second acquisition module 403 is used to acquire historical abnormal data of the first monitoring indicator associated with each of the configuration information;

[0133] The determination module 404 is used to determine, based on the historical anomaly data, whether to obtain the address information of the attacked device that caused the first device malfunction.

[0134] Optionally, the device further includes:

[0135] The conversion module is used to convert the monitoring period, monitoring indicators, and monitoring thresholds corresponding to the monitoring indicators into a data structure file that can be accepted by the NETCONF network configuration protocol.

[0136] The second sending module is used to send the data structure file to the first device;

[0137] The first monitoring indicator is one of the monitoring indicators in the data structure file.

[0138] Optionally, the device further includes:

[0139] The third sending module is used to resend the data structure file to the first device.

[0140] Optionally, the first acquisition module 402 is specifically used for:

[0141] When the number of times the data structure file is sent to the first device reaches a preset number, and the value of the first monitoring indicator when the first device transmits data is still greater than or equal to the first monitoring threshold, at least one configuration information associated with the data transmitted by the first device is obtained.

[0142] Optionally, the determining module 404 is specifically used for:

[0143] The historical anomaly data associated with the i-th configuration information is stored in the i-th set, where i is an integer from 1 to N, and N represents the number of the at least one configuration information.

[0144] Based on the target threshold and using the k-nearest neighbor algorithm prediction model, the historical abnormal data in the i-th set are classified to obtain the i-th number of historical abnormal data in the i-th set that is greater than or equal to the target threshold.

[0145] If the ratio of the i-th quantity to the number of historical abnormal data in the i-th set is greater than or equal to a preset ratio, the i-th set is determined to be an abnormal set.

[0146] If the number of the anomaly set is greater than or equal to a preset number, determine and obtain the address information of the attacked device that caused the first device to malfunction;

[0147] If the number of anomalies is less than the preset number, the step of obtaining the address information of the attacked device that caused the first device to malfunction is skipped.

[0148] Optionally, the device further includes:

[0149] The third acquisition module is used to determine the address information of the attacked device that caused the first device to malfunction, execute an attack tracing strategy, and acquire the address information of the attacked device.

[0150] Optionally, the at least one configuration information includes at least one of the following: source address, destination address, source port, destination port, and protocol used when transmitting data.

[0151] See Figure 5 The present invention also provides a fault handling device, applied to the monitored device, which may include the following modules:

[0152] The first sending module 501 is used to send a fault message to the management device, wherein the fault message is used to indicate that the value of a first monitoring indicator when the monitored device transmits data is greater than or equal to a first monitoring threshold corresponding to the first monitoring indicator.

[0153] Optionally, the device further includes:

[0154] The second receiving module is used to receive the data structure file sent by the management device, wherein the data structure file is a data structure file that converts the monitoring period, monitoring indicators, and monitoring thresholds corresponding to the monitoring indicators into a data structure file that can be accepted by the NETCONF protocol for network configuration.

[0155] The parsing module is used to parse the data structure file to obtain the monitoring period, the monitoring indicators, and the monitoring thresholds;

[0156] The data acquisition module is used to acquire the values ​​of the monitoring indicators according to the monitoring period, and compare the values ​​of the monitoring indicators with the monitoring thresholds corresponding to the monitoring indicators;

[0157] The first monitoring indicator is one of the monitoring indicators in the data structure file.

[0158] Optionally, the device further includes:

[0159] The third receiving module is used to receive the data structure file resent by the management device.

[0160] Optionally, the device further includes:

[0161] The storage module is used to store fault information in a historical database when the value of the first monitoring indicator is less than the first monitoring threshold while the monitored device is transmitting data.

[0162] The fault information includes at least one of the following: the value of the first monitoring indicator, the occurrence time, the recovery time, and the fault content.

[0163] As can be seen from the above, in the embodiments of the present invention, the management device can receive a fault message sent when a first device (i.e., multiple devices managed by the management device) fails. The fault message is used to indicate that the value of a first monitoring indicator when the first device transmits data is greater than or equal to a first monitoring threshold corresponding to the first monitoring indicator. Then, the management device obtains at least one configuration information associated with the data transmitted by the first device, and obtains historical abnormal data of the first monitoring indicator associated with each configuration information, thereby determining whether to obtain the address information of the attacked device that caused the failure of the first device based on the historical abnormal data.

[0164] Therefore, in this embodiment of the invention, after receiving the fault message sent by the first device, the management device does not immediately obtain the address information of the attacked device that caused the fault of the first device, that is, it does not immediately perform fault tracing. Instead, it obtains at least one configuration information associated with the data transmitted by the first device, and obtains historical abnormal data of the first monitoring indicator from different directions represented by different configuration information. Then, based on the historical abnormal data, it decides whether to perform fault tracing, so that fault tracing can be performed at a more reasonable time, rather than immediately tracing the fault when it occurs, reducing the probability of unreasonable tracing, thereby further saving network resources.

[0165] It should be noted that the division of units in the embodiments of this application is illustrative and only represents one logical functional division. In actual implementation, other division methods may be used. Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated units described above can be implemented in hardware or as software functional units.

[0166] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a processor-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0167] It should be noted that the apparatus provided in this embodiment of the invention can implement all the method steps implemented in the above method embodiment and can achieve the same technical effect. Therefore, the parts and beneficial effects that are the same as those in the method embodiment will not be described in detail here.

[0168] Embodiments of the present invention also provide an electronic device, such as... Figure 6 As shown, the electronic device includes a memory 620, a transceiver 610, and a processor 600;

[0169] Memory 620 is used to store computer programs;

[0170] Transceiver 610 is used to receive and send data under the control of processor 600;

[0171] The processor 600 is used to read the computer program in the memory 620 and execute the fault handling method described in the first or second aspect above.

[0172] Among them, Figure 6 In this context, the bus architecture can include any number of interconnected buses and bridges, specifically linking various circuits together, represented by one or more processors (processor 600) and memory (memory 620). The bus architecture can also link together various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. The bus interface provides an interface. The transceiver 610 can be multiple elements, including transmitters and receivers, providing a unit for communicating with various other devices over transmission media, including wireless channels, wired channels, optical fibers, etc. The processor 600 is responsible for managing the bus architecture and general processing, and the memory 620 can store data used by the processor 600 during operation.

[0173] The processor 600 can be a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a complex programmable logic device (CPLD). The processor 600 can also adopt a multi-core architecture.

[0174] It should be noted that the apparatus provided in this embodiment of the invention can implement all the method steps implemented in the above method embodiment and can achieve the same technical effect. Therefore, the parts and beneficial effects that are the same as those in the method embodiment will not be described in detail here.

[0175] Embodiments of the present invention also provide a processor-readable storage medium storing a computer program for causing the processor to perform the fault handling method described in the first or second aspect above.

[0176] The processor-readable storage medium can be any available medium or data storage device that the processor can access, including but not limited to magnetic memory (e.g., floppy disk, hard disk, magnetic tape, magneto-optical disk (MO)), optical memory (e.g., CD, DVD, BD, HVD), and semiconductor memory (e.g., ROM, EPROM, EEPROM, non-volatile memory (NAND FLASH), solid-state drive (SSD)).

[0177] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage and optical storage) containing computer-usable program code.

[0178] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-executable instructions. These computer-executable instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0179] These processor-executable instructions may also be stored in a processor-readable memory that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the processor-readable memory produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0180] These processors can execute instructions that can also be loaded onto a computer or other programmable data processing device, causing a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable device for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0181] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations. < / rpc>

Claims

1. A failure handling method characterized by, The method applied to a management device comprises: receiving a fault message sent when a first device fails, wherein the first device is at least one of a plurality of monitored devices managed by the management device, and the fault message is used to indicate that a value of a first monitoring index when the first device transmits data is greater than or equal to a first monitoring threshold corresponding to the first monitoring index; obtaining at least one configuration information associated with data transmission of the first device; obtaining historical abnormal data of the first monitoring index associated with each of the configuration information respectively; determining whether to obtain address information of an attacked device causing the failure of the first device according to the historical abnormal data; wherein the determining whether to obtain the address information of the attacked device causing the failure of the first device according to the historical abnormal data comprises: storing the historical abnormal data associated with the i-th configuration information into an i-th set, i is an integer from 1 to N, and N represents the number of the at least one configuration information; classifying the historical abnormal data in the i-th set according to a target threshold and using a k-nearest neighbor algorithm prediction model to obtain an i-th number of historical abnormal data greater than or equal to the target threshold in the i-th set; determining that the i-th set is an abnormal set when a ratio of the i-th number to the number of historical abnormal data in the i-th set is greater than or equal to a preset ratio; determining to obtain the address information of the attacked device causing the failure of the first device when the number of the abnormal sets is greater than or equal to a preset number; determining to skip the step of obtaining the address information of the attacked device causing the failure of the first device when the number of the abnormal sets is less than the preset number.

2. The method of claim 1, wherein, Before the receiving the fault message sent when the first device fails, the method further comprises: converting a monitoring period, a monitoring index, and a monitoring threshold corresponding to the monitoring index into a data structure file accepted by a network configuration NETCONF protocol; sending the data structure file to the first device; wherein the first monitoring index is one of the monitoring indexes in the data structure file.

3. The method of claim 2, wherein, After the receiving the fault message sent when the first device fails, the method further comprises: re-sending the data structure file to the first device.

4. The method of claim 3, wherein, The obtaining the at least one configuration information associated with data transmission of the first device comprises: when the number of times of sending the data structure file to the first device reaches a preset number of times and the value of the first monitoring index when the first device transmits data is still greater than or equal to the first monitoring threshold, obtaining the at least one configuration information associated with data transmission of the first device.

5. The method of claim 1, wherein, The method further comprises: when it is determined to obtain the address information of the attacked device causing the failure of the first device, executing an attack tracing strategy to obtain the address information of the attacked device.

6. The method according to any one of claims 1 to 5, characterized in that, The at least one configuration information comprises at least one of a source address, a destination address, a source port, a destination port, and a protocol used for data transmission.

7. A fault handling method characterized by, The method applied to a monitored device comprises: sending a fault message to a management device, wherein the fault message is used to indicate that a value of a first monitoring index of the monitored device when transmitting data is greater than or equal to a first monitoring threshold corresponding to the first monitoring index; wherein the management device is configured to: receive a fault message sent when a first device fails, wherein the first device is at least one of a plurality of monitored devices managed by the management device; obtain at least one configuration information associated with data transmission of the first device; respectively obtain historical abnormal data of the first monitoring index associated with each of the configuration information; determine whether to obtain address information of an attacked device causing the first device to fail according to the historical abnormal data; wherein the determination of whether to obtain the address information of the attacked device causing the first device to fail according to the historical abnormal data comprises: storing the historical abnormal data associated with the i-th configuration information into the i-th set, i is an integer from 1 to N, and N represents the number of the at least one configuration information; classifying the historical abnormal data in the i-th set according to a target threshold and using a k-nearest neighbor algorithm prediction model to obtain an i-th number of historical abnormal data in the i-th set greater than or equal to the target threshold; determining that the i-th set is an abnormal set when a ratio of the i-th number to the number of historical abnormal data in the i-th set is greater than or equal to a preset ratio; determining to obtain the address information of the attacked device causing the first device to fail when the number of abnormal sets is greater than or equal to a preset number; determining to skip the step of obtaining the address information of the attacked device causing the first device to fail when the number of abnormal sets is less than the preset number.

8. The method of claim 7, wherein, Before the step of sending the fault message to the management device, the method further comprises: receiving a data structure file sent by the management device, wherein the data structure file is converted from a monitoring period, a monitoring index, and a monitoring threshold corresponding to the monitoring index into a data structure file accepted by a network configuration (NETCONF) protocol; parsing the data structure file to obtain the monitoring period, the monitoring index, and the monitoring threshold; collecting a value of the monitoring index according to the monitoring period, and comparing the value of the monitoring index with the monitoring threshold corresponding to the monitoring index; wherein the first monitoring index is one of the monitoring indexes in the data structure file.

9. The method of claim 8, wherein, After the step of sending the fault message to the management device, the method further comprises: receiving the data structure file re-sent by the management device.

10. The method of claim 7, wherein, After the step of sending the fault message to the management device, the method further comprises: storing fault information into a historical database when the value of the first monitoring index of the monitored device when transmitting data is less than the first monitoring threshold; wherein the fault information comprises at least one of the value of the first monitoring index, a time of occurrence, a time of recovery, and fault content.

11. A failure handling apparatus characterized by comprising: The device is applied to a management device and comprises: The first receiving module is configured to receive a fault message sent when a first device fails, wherein the first device is at least one of a plurality of monitored devices managed by the management device, and the fault message is used to indicate that a value of a first monitoring indicator when the first device transmits data is greater than or equal to a first monitoring threshold corresponding to the first monitoring indicator; The first obtaining module is configured to obtain at least one configuration information associated with data transmission of the first device; The second obtaining module is configured to obtain historical abnormal data of the first monitoring indicator associated with each of the configuration information respectively; The determining module is configured to determine whether to obtain address information of an attacked device causing the failure of the first device according to the historical abnormal data; The determining module is specifically configured to: store the historical abnormal data associated with the i-th configuration information into an i-th set, i is an integer from 1 to N, and N represents a quantity of the at least one configuration information; classify the historical abnormal data in the i-th set according to a target threshold and using a k-nearest neighbor algorithm prediction model, to obtain an i-th quantity of historical abnormal data greater than or equal to the target threshold in the i-th set; determine that the i-th set is an abnormal set when a ratio of the i-th quantity to a quantity of the historical abnormal data in the i-th set is greater than or equal to a preset ratio; determine to obtain the address information of the attacked device causing the failure of the first device when a quantity of the abnormal sets is greater than or equal to a preset quantity; determine to skip the step of obtaining the address information of the attacked device causing the failure of the first device when the quantity of the abnormal sets is less than the preset quantity.

12. A fault handling apparatus characterized by comprising: The apparatus is applied to a monitored device, and the apparatus comprises: The first sending module is configured to send a fault message to a management device, wherein the fault message is used to indicate that a value of a first monitoring indicator when the monitored device transmits data is greater than or equal to a first monitoring threshold corresponding to the first monitoring indicator; The management device is configured to: receive a fault message sent when a first device fails, wherein the first device is at least one of a plurality of monitored devices managed by the management device; obtain at least one configuration information associated with data transmission of the first device; obtain historical abnormal data of the first monitoring indicator associated with each of the configuration information respectively; determine whether to obtain address information of an attacked device causing the failure of the first device according to the historical abnormal data; The determination of whether to obtain the address information of the attacked device causing the failure of the first device according to the historical abnormal data comprises: store the historical abnormal data associated with the i-th configuration information into an i-th set, i is an integer from 1 to N, and N represents a quantity of the at least one configuration information; classify the historical abnormal data in the i-th set according to a target threshold and using a k-nearest neighbor algorithm prediction model, to obtain an i-th quantity of historical abnormal data greater than or equal to the target threshold in the i-th set; In a case where a ratio of the ith quantity to a quantity of historical abnormal data in the ith set is greater than or equal to a preset ratio value, the ith set is determined as an abnormal set; In a case where the quantity of abnormal sets is greater than or equal to a preset quantity, address information of an attacked device causing the first device to malfunction is acquired; In a case where the quantity of abnormal sets is less than the preset quantity, a step of acquiring address information of an attacked device causing the first device to malfunction is skipped.

13. An electronic device, comprising: The device comprises a memory, a transceiver, and a processor: The memory is configured to store a computer program; The transceiver is configured to transceive data under control of the processor; The processor is configured to read the computer program in the memory and execute the fault processing method in any one of claims 1 to 6 or the fault processing method in any one of claims 7 to 10.

14. A processor-readable storage medium, characterized in that, The processor readable storage medium stores a computer program, and the computer program is configured to cause the processor to execute the fault processing method in any one of claims 1 to 6 or the fault processing method in any one of claims 7 to 10.

Images