A network device fault rapid positioning method and system based on historical data

Abstract

The application discloses a network equipment fault rapid positioning method and system based on historical data, and relates to the technical field of network equipment fault detection.The method comprises the following steps: collecting historical operation data of network equipment;network faults are summarized into three application scenarios, and positioning is performed according to different logics;the collected network equipment data is cleaned and preprocessed, recursive feature elimination and screening are performed based on the preprocessing result, real-time features are matched with a historical database, and the priority of the application scenario is calculated;the matching degree of the current fault features and the three application scenarios is evaluated, the most matched scenario is selected as a fault positioning strategy, and the priority order of execution is recorded to a historical scenario library;for a newly identified fault scenario, expansion is performed as a sub-scenario, the occurrence frequency of the sub-scenario is counted according to the number of occurrences, and it is judged whether the sub-scenario needs to be upgraded to a main scenario, so that the network equipment fault rapid positioning is realized.

Description

Technical Field

[0001] This invention relates to the field of network equipment fault detection technology, specifically a method and system for rapid fault location of network equipment based on historical data. Background Technology

[0002] In today's digital age, the network has been deeply integrated into all aspects of society. Whether it is business operations, daily life, industrial production, or scientific research activities, they all rely heavily on a stable and efficient network environment. As the core component of the network, the stable operation of network equipment is crucial. Once network equipment fails, it may lead to business interruption and data loss, causing huge economic losses and inconvenience to enterprises and users.

[0003] However, existing network equipment fault location methods have many limitations. First, traditional fault location mainly relies on the experience of maintenance personnel, who check network equipment data one by one. This makes it difficult to quickly identify complex faults. With the continuous development of network technology, network structures and business models are becoming increasingly complex. Network data includes multi-dimensional information, such as traffic changes in different areas and performance parameters of various devices. Traditional methods cannot uncover potential fault risks from the correlation of these multi-dimensional data. Second, network data processing lacks global review capabilities. Traditional methods often focus only on faults of single devices or local networks, without comprehensively analyzing the overall network operating status, including the changing trends of network traffic in different areas and the mutual influence of various device performance indicators. In addition, traditional fault location methods rely heavily on human experience. Faced with complex and ever-changing network environments and ever-growing network scale, manual troubleshooting is inefficient and makes it difficult to quickly and accurately determine the fault point. Summary of the Invention

[0004] The purpose of this invention is to provide a method and system for rapid fault location of network devices based on historical data, so as to solve the problems raised in the prior art.

[0005] To achieve the above objectives, the present invention provides the following technical solution: a method for rapid fault location of network devices based on historical data, the method comprising the following steps:

[0006] Collect historical operational data of network devices;

[0007] Network failures are categorized into three application scenarios and located based on different logics;

[0008] The collected network device data is cleaned and preprocessed. Based on the preprocessing results, recursive feature elimination and filtering are performed, and real-time features are matched with historical databases to calculate the priority of application scenarios.

[0009] Assess the degree of matching between the current fault characteristics and the three types of application scenarios, select the most matching scenario as the fault localization strategy, and record the execution priority order in the historical scenario library;

[0010] For newly identified fault scenarios, they are expanded as sub-scenarios, and their frequency of occurrence is used to determine whether they need to be upgraded to main scenarios. The sub-scenarios refer to newly identified fault scenarios that have not yet been included in the existing main scenarios during the fault localization process. The sub-scenarios are generated based on the fact that the current fault characteristics do not completely match the existing fault scenario patterns, but have similarities or correlations. The main scenarios refer to a set of representative and typical fault scenarios formed after classifying and summarizing network faults. The set of fault scenarios is based on historical fault data and practical experience. Each main scenario corresponds to specific fault characteristics, localization logic, and processing strategies.

[0011] Collecting historical operational data of network devices via the SNMP protocol, including device logs, traffic information, device performance configurations, and fault records, involves the following steps:

[0012] Historical operational data of network devices is collected via the SNMP protocol, including device logs, traffic information, network device performance configuration, and fault records; wherein, the traffic information includes network traffic involving multiple areas of offline and online platforms, as well as network traffic demand data;

[0013] The network traffic demand data represents the demand for data transmission traffic and traffic usage behavior characteristics in the network within a specific time period, denoted as [F1, F2, ..., Fz]; where z is a positive integer representing the number of traffic demand types, and F1, F2, ..., Fz represent the 1st, 2nd, ..., zth traffic demand types, respectively; the traffic demand data is obtained through network traffic monitoring equipment and network service providers; historical traffic demand data at different times have the same time interval Δf; the data is arranged in chronological order [f1, f2, ..., fw] to form a network traffic demand time series data; where w represents the number of times, and f1, f2, ..., fw represent the 1st, 2nd, ..., wth traffic demand data collection times, respectively;

[0014] The network device performance configuration data represents the operating performance status, dynamic process of configuration parameter adjustment, and health status data of the network device, denoted as [P1, P2, ..., Pu]; where u is a positive integer representing the type of network device performance configuration data, P1, P2, ..., Pu representing the 1st, 2nd, ..., uth types of network device performance configuration data, respectively; the network device performance configuration data is obtained from the device's own monitoring system and the device manufacturer; the historical data of the network device performance configuration at different times have the same time interval Δp; the data is arranged in chronological order [p1, p2, ..., pv], forming the network device performance configuration time series data; where v represents the number of times, p1, p2, ..., pv representing the 1st, 2nd, ..., vth network device performance configuration data collection times, respectively.

[0015] Network failures were categorized into three application scenarios and located according to different logics. The specific steps included:

[0016] In the first type of application scenario: when the traffic in the i-th region drops to the designed traffic threshold and there is no switch error in the device log, in the first type of application scenario, historical link interruption cases (fiber optic cable is cut) are matched first, and the link detection tool (Traceroute) is directly triggered. Here, i is used to identify a specific region, and the designed traffic threshold is determined by historical data.

[0017] In the second type of application scenario: when there are multiple areas and traffic anomalies, and the device log shows that the switch CPU / memory is overloaded or the port is down, in the second type of application scenario, the core switch status (port status, load threshold) should be checked first, and the recovery strategy (restart or switch to backup switch) for similar historical faults should be compared.

[0018] In the third application scenario: when local users fail to connect and authentication errors or ARP conflicts frequently appear in the logs, the configuration snapshot of the edge device (store switch) should be checked first and compared with the historical correct configuration version.

[0019] The first type of application scenario, the second type of application scenario, and the third type of application scenario together constitute the initial application scenario set for network device fault location.

[0020] The collected network device-related data is cleaned and preprocessed to remove noise data. For traffic data, if the traffic value at a certain moment is missing, it is filled in using linear interpolation based on the traffic data of the preceding and following moments. The data format is standardized and all data is stored in a unified database table structure.

[0021] Features are extracted from the preprocessed data and denoted as [T1,T2,...,Tn].

[0022] The decision tree machine learning model was chosen for fault prediction. The initial model was trained using preprocessed and feature-extracted data as input and historical fault records as labels.

[0023] The contribution of each feature to the model performance is measured by calculating the information gain of the features;

[0024] Remove the feature with the smallest contribution from the current feature set, retrain the model, and evaluate the model performance. If the model performance fluctuates within 2%, retain the feature set after removing the feature; otherwise, restore the feature. Here, q represents the threshold parameter that measures the degree of change in model performance.

[0025] Repeat the above process until the impact of all features in the feature set on the model performance reaches the set impact threshold, which is determined by cross-validation and model performance evaluation accuracy index.

[0026] Real-time features are matched with historical databases and sorted by priority. The priority order of the three application scenarios is analyzed. Based on the impact scope and repair time involved in the application scenarios, an application scenario priority calculation formula is constructed. According to the application scenario priority calculation formula, the three application scenarios are prioritized according to their priority. The application scenario priority calculation formula is as follows:

[0027] Asp = α*Si + β*Rt;

[0028] Where Asp represents the application scenario priority, Si represents the scope of impact of the application scenario, Rt represents the repair time involved in the application scenario, and α and β represent weighting coefficients.

[0029] Calculating the degree of matching between the current fault characteristics and the three types of application scenarios involves the following steps:

[0030] Calculate the degree of matching between the current fault characteristics and the three types of application scenarios. When real-time data is compared with the three types of application scenarios one by one in a prescribed priority order, it is denoted as m1, m2 and m3. Here, m1 represents the degree of matching between real-time data and the first type of application scenario, m2 represents the degree of matching between real-time data and the second type of application scenario, and m3 represents the degree of matching between real-time data and the third type of application scenario.

[0031] The calculated matching degrees m1, m2, and m3 between the current fault features and the three application scenarios are sorted, and the matching degree with the highest degree is selected as the localization strategy to be adopted for the current fault features.

[0032] Determine whether the location strategy with the highest matching degree has successfully resolved the current fault. If the location measure with the highest matching degree has failed to resolve the current fault, select other scenarios in descending order of priority as the location measures to be taken for the current scenario.

[0033] The specific steps for resolving the current fault using the location method with the highest matching degree are as follows:

[0034] The sub-scenario types under the application scenario involved by the positioning measures with the highest matching degree are sorted according to the number of times the sub-scenario appears in the application scenario. Under the current application scenario, the sub-scenarios are analyzed one by one in the order of the number of occurrences until the current fault is resolved by the sub-scenario under the application scenario. The sub-scenario under the application scenario is recorded as the solution to the current fault.

[0035] Add the priority order of the current fault characteristics to the historical scenario library;

[0036] The current fault characteristics are classified into the three application scenarios, that is, the newly added scenarios are extended as sub-scenarios, and the number of times the current sub-scenarios appears is recorded as 1. When the current sub-scenarios appears later, the number of times the current sub-scenarios appears is incremented by 1. Finally, the number of times the current sub-scenarios appears over a period of time is counted.

[0037] When a sub-scene is adjusted to become the main scene, the number of times the sub-scene appears is set to U1. If the number of times the current sub-scene appears exceeds the set number of times the sub-scene is adjusted to become the main scene, the current sub-scene is adjusted to become the main scene. The formula for calculating the number of times the sub-scene is adjusted to become the main scene is as follows: U1 = γ * TNF.

[0038] Wherein, TNF represents the total number of faults, and γ represents the weighting coefficient.

[0039] A network device fault rapid location system based on historical data includes a data acquisition module, a data processing module, a fault scenario analysis module, a fault location decision module, and a scenario management module. The data acquisition module collects historical operational data of the network devices. The data processing module cleans and preprocesses the collected network device-related data and extracts features from the preprocessed data. The fault scenario analysis module categorizes network faults into three application scenarios, locates them according to different logics, matches real-time features with a historical database, and calculates the priority of each application scenario. The fault location decision module evaluates the matching degree between current fault features and the three application scenarios, selects the most matching scenario as the fault location strategy, and records the execution priority order in a historical scenario database. The scenario management module expands newly identified fault scenarios as sub-scenarios and determines whether to upgrade them to primary scenarios based on their frequency of occurrence.

[0040] The data acquisition module includes a data acquisition unit and a time series construction unit. The data acquisition unit uses the SNMP protocol to collect data from multiple channels, including network devices, network traffic monitoring devices and network service providers, device monitoring systems, and device manufacturers. The collected data includes device logs, traffic information, device performance configuration data, and fault records. The time series construction unit is used to construct network traffic demand time series data and network device performance configuration time series data respectively from the collected traffic demand data and device performance configuration data according to their respective time intervals.

[0041] The data processing module includes a preprocessing unit, a feature extraction unit, and a feature selection unit. The preprocessing unit removes noisy data from the collected data, fills in missing values ​​in the traffic data using linear interpolation, and standardizes all data formats, storing them uniformly in a database table structure. The feature extraction unit extracts features from the preprocessed data, denoted as [T1, T2, ..., Tn]. The feature selection unit selects a decision tree machine learning model, using the preprocessed and feature-extracted data as input and historical fault records as labels to train the initial model. It measures the contribution of features to model performance by calculating the information gain of each feature, recursively removes the features with the smallest contribution, and retrains and evaluates the model. When the model performance fluctuation is within a set threshold, the removed feature set is retained; otherwise, the feature is restored. This process continues until the impact of all features on model performance reaches the set threshold, selecting the features with the greatest influence on fault prediction.

[0042] The fault scenario analysis module includes a scenario classification and localization unit and a priority calculation unit. The scenario classification and localization unit is used to classify network faults into three application scenarios and locate them according to different logics. The priority calculation unit is used to construct an application scenario priority calculation formula based on the impact range and repair time involved in the application scenario. The formula is used to calculate and analyze the priority order of the three application scenarios to determine the order of fault handling. The fault localization decision module includes a matching evaluation unit and a strategy execution verification unit. The matching evaluation unit is used to calculate the matching degree between the current fault characteristics and the three application scenarios, denoted as m1, m2, and m3, respectively. These matching degrees are sorted, and the scenario with the highest matching degree is selected as the initial fault localization strategy. The strategy execution verification unit is used to execute the localization strategy with the highest matching degree and determine whether the current fault is successfully resolved. If it is not resolved, other scenario localization measures are selected in descending order of priority to continue trying. For cases where the fault is successfully resolved, the relevant sub-scenarios are recorded as fault resolution measures.

[0043] The scenario management module includes a historical scenario recording unit and a scenario expansion and adjustment unit. The historical scenario recording unit is used to add the priority order of the current fault characteristics to the historical scenario library and record information during the fault handling process. The scenario expansion and adjustment unit is used to expand the newly identified fault scenario as a sub-scenario to the three types of application scenarios, count the number of times the sub-scenario appears, and adjust it to the main scenario when the number of times the sub-scenario appears exceeds the set number of times.

[0044] Compared with the prior art, the beneficial effects of the present invention are:

[0045] 1. As new fault scenarios continue to emerge, this invention expands them into the historical scenario library as sub-scenarios and counts their occurrence frequency based on the number of occurrences. When the occurrence frequency of a certain sub-scenario reaches a certain level, it is upgraded to the main scenario, so that it can continuously adapt to new network fault modes.

[0046] 2. By using recursive feature elimination and filtering, features are extracted from multi-dimensional network data. These features reflect the operating status of network devices and help to discover potential fault risks.

[0047] 3. By collecting historical operating data of network devices and establishing a database, when a fault occurs, the database information is called up and combined with real-time network monitoring information to narrow down the scope of fault investigation. Compared with the traditional manual investigation method, it is not necessary to check a large number of network devices and data one by one. Attached Figure Description

[0048] Figure 1 This is a flowchart illustrating a method for rapid fault location of network devices based on historical data according to the present invention.

[0049] Figure 2 This is a schematic diagram of the structure of a network device fault rapid location system based on historical data according to the present invention. Detailed Implementation

[0050] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0051] In the embodiment: such as Figures 1-2 As shown, the present invention provides a technical solution, a method for rapid fault location of network devices based on historical data, the method comprising the following steps:

[0052] Collect historical operational data of network devices;

[0053] Network failures are categorized into three application scenarios and located based on different logics;

[0054] The collected network device data is cleaned and preprocessed. Based on the preprocessing results, recursive feature elimination and filtering are performed, and real-time features are matched with historical databases to calculate the priority of application scenarios.

[0055] Assess the degree of matching between the current fault characteristics and the three types of application scenarios, select the most matching scenario as the fault localization strategy, and record the execution priority order in the historical scenario library;

[0056] For newly identified fault scenarios, they are expanded as sub-scenarios, and their frequency of occurrence is used to determine whether they need to be upgraded to main scenarios. The sub-scenarios refer to newly identified fault scenarios that have not yet been included in the existing main scenarios during the fault localization process. The sub-scenarios are generated based on the fact that the current fault characteristics do not completely match the existing fault scenario patterns, but have similarities or correlations. The main scenarios refer to a set of representative and typical fault scenarios formed after classifying and summarizing network faults. The set of fault scenarios is based on historical fault data and practical experience. Each main scenario corresponds to specific fault characteristics, localization logic, and processing strategies.

[0057] Collecting historical operational data of network devices via the SNMP protocol, including device logs, traffic information, device performance configurations, and fault records, involves the following steps:

[0058] Historical operational data of network devices is collected via the SNMP protocol, including device logs, traffic information, network device performance configuration, and fault records; wherein, the traffic information includes network traffic involving multiple areas of offline and online platforms, as well as network traffic demand data;

[0059] The network traffic demand data represents the demand for data transmission traffic and traffic usage behavior characteristics in the network within a specific time period, denoted as [F1, F2, ..., Fz]; where z is a positive integer representing the number of traffic demand types, and F1, F2, ..., Fz represent the 1st, 2nd, ..., zth traffic demand types, respectively; the traffic demand data is obtained through network traffic monitoring equipment and network service providers; historical traffic demand data at different times have the same time interval Δf; the data is arranged in chronological order [f1, f2, ..., fw] to form a network traffic demand time series data; where w represents the number of times, and f1, f2, ..., fw represent the 1st, 2nd, ..., wth traffic demand data collection times, respectively;

[0060] The network device performance configuration data represents the operating performance status, dynamic process of configuration parameter adjustment, and health status data of the network device, denoted as [P1, P2, ..., Pu]; where u is a positive integer representing the type of network device performance configuration data, P1, P2, ..., Pu representing the 1st, 2nd, ..., uth types of network device performance configuration data, respectively; the network device performance configuration data is obtained from the device's own monitoring system and the device manufacturer; the historical data of the network device performance configuration at different times have the same time interval Δp; the data is arranged in chronological order [p1, p2, ..., pv], forming the network device performance configuration time series data; where v represents the number of times, p1, p2, ..., pv representing the 1st, 2nd, ..., vth network device performance configuration data collection times, respectively.

[0061] Specifically, in a certain clothing store that has multiple offline stores (taking three stores as an example, labeled as store A, store B, and store C respectively) and conducts business through an online platform, its network architecture covers multiple regional networks, which are connected and supported by various network devices. In actual operation, a large amount of historical operation data of network devices is generated.

[0062] Traffic Information: Using network traffic monitoring equipment and network service providers, network traffic demand data for the past month was obtained. During the weekday mornings from 10:00 to 11:00, the network traffic demand data for Store A are F1, F2, and F3 (representing sales system data traffic, surveillance video data traffic, and office system data traffic, respectively). On a certain weekday at 10:00, the traffic values ​​are 5Mbps, 2Mbps, and 1Mbps, and the time interval Δf between different historical times is 1 minute. The data is arranged in time order f1, f2, ..., f60 to form a time series data.

[0063] Network device performance configuration data was collected from the device's own monitoring system and the device manufacturer. Taking the core switch of store A as an example, its network device performance configuration data P1, P2, and P3 (representing CPU utilization, memory utilization, and port bandwidth utilization, respectively) were 60%, 70%, and 50% at 10:10 AM on a certain day, with a data interval Δp of 10 minutes. The data, arranged in chronological order (p1, p2, ..., p144), constitutes a time-series data set.

[0064] By collecting device logs and fault records via the SNMP protocol, the switch in store B recorded "port 5 connection abnormal" at a certain time, as well as various fault information that occurred in the past, including fault time and fault description.

[0065] Network failures were categorized into three application scenarios and located according to different logics. The specific steps included:

[0066] In the first type of application scenario: when the traffic in the i-th region drops to the designed traffic threshold and there is no switch error in the device log, in the first type of application scenario, historical link interruption cases (fiber optic cable is cut) are matched first, and the link detection tool (Traceroute) is directly triggered. Here, i is used to identify a specific region, and the designed traffic threshold is determined by historical data.

[0067] In the second type of application scenario: when there are multiple areas and traffic anomalies, and the device log shows that the switch CPU / memory is overloaded or the port is down, in the second type of application scenario, the core switch status (port status, load threshold) should be checked first, and the recovery strategy (restart or switch to backup switch) for similar historical faults should be compared.

[0068] In the third application scenario: when local users fail to connect and authentication errors or ARP conflicts frequently appear in the logs, the configuration snapshot of the edge device (store switch) should be checked first and compared with the historical correct configuration version.

[0069] The first type of application scenario, the second type of application scenario, and the third type of application scenario together constitute the initial application scenario set for network device fault location.

[0070] The collected network device-related data is cleaned and preprocessed to remove noise data. For traffic data, if the traffic value at a certain moment is missing, it is filled in using linear interpolation based on the traffic data of the preceding and following moments. The data format is standardized and all data is stored in a unified database table structure.

[0071] Features are extracted from the preprocessed data and denoted as [T1,T2,...,Tn].

[0072] The decision tree machine learning model was chosen for fault prediction. The initial model was trained using preprocessed and feature-extracted data as input and historical fault records as labels.

[0073] The contribution of each feature to the model performance is measured by calculating the information gain of the features;

[0074] Remove the feature with the smallest contribution from the current feature set, retrain the model, and evaluate the model performance. If the model performance fluctuates within 2%, retain the feature set after removing the feature; otherwise, restore the feature. Here, q represents the threshold parameter that measures the degree of change in model performance.

[0075] Repeat the above process until the impact of all features in the feature set on the model performance reaches the set impact threshold, which is determined by cross-validation and model performance evaluation accuracy index.

[0076] Real-time features are matched with historical databases and sorted by priority. The priority order of the three application scenarios is analyzed. Based on the impact scope and repair time involved in the application scenarios, an application scenario priority calculation formula is constructed. According to the application scenario priority calculation formula, the three application scenarios are prioritized according to their priority. The application scenario priority calculation formula is as follows:

[0077] Asp = α*Si + β*Rt;

[0078] Where Asp represents the application scenario priority, Si represents the scope of impact of the application scenario, Rt represents the repair time involved in the application scenario, and α and β represent weighting coefficients.

[0079] Specifically, a reasonable threshold range is set for the collected traffic data. The normal range for sales system data traffic is 2Mbps-10Mbps. If the traffic value is 20Mbps at a certain moment, it is judged as noise data and removed.

[0080] Missing value imputation: When the traffic value of the surveillance video data of store C is missing at a certain moment, it is filled by linear interpolation based on the traffic data of the adjacent moments. According to the traffic of the previous moment is 1.8Mbps and the traffic of the next moment is 2.2Mbps, the missing value imputation is (1.8+2.2)÷2=2Mbps.

[0081] Unify all data formats, standardize the time format to “YYYY-MM-DDHH:MM:SS”, standardize the unit of traffic data to Mbps, standardize the representation of device performance data as a percentage, and store it according to a unified database table structure;

[0082] Features T1, T2, and T3 are extracted from the preprocessed data, such as traffic change magnitude, error log type, and device load. Taking the data traffic of the sales system of store A as an example, the traffic change magnitude within a certain period is calculated. If the traffic was 5 Mbps at the previous moment and 6 Mbps at the current moment, then the traffic change magnitude is (6-5) ÷ 5 × 100% = 20%. Error log types are counted, such as "authentication failed" and "port connection timeout". Device load is calculated based on CPU utilization, memory utilization, and other comprehensive load indicators.

[0083] The decision tree machine learning model is selected, and the preprocessed and feature-extracted data is used as input. Historical fault records are used as labels to train the initial model. The contribution is measured by calculating the information gain of the features. According to the initial feature set T1, T2, and T3, it is found that T3 has the smallest contribution. After removing T3, the model is retrained and the model performance is evaluated. If the model accuracy fluctuates from 80% to 79% (fluctuation within the set 2% threshold q), the feature set after removing T3 is retained, and the process is repeated until the impact of all features on the model performance reaches the set impact threshold.

[0084] Calculating the degree of matching between the current fault characteristics and the three types of application scenarios involves the following steps:

[0085] Calculate the degree of matching between the current fault characteristics and the three types of application scenarios. When real-time data is compared with the three types of application scenarios one by one in a prescribed priority order, it is denoted as m1, m2 and m3. Here, m1 represents the degree of matching between real-time data and the first type of application scenario, m2 represents the degree of matching between real-time data and the second type of application scenario, and m3 represents the degree of matching between real-time data and the third type of application scenario.

[0086] The calculated matching degrees m1, m2, and m3 between the current fault features and the three application scenarios are sorted, and the matching degree with the highest degree is selected as the localization strategy to be adopted for the current fault features.

[0087] Determine whether the location strategy with the highest matching degree has successfully resolved the current fault. If the location measure with the highest matching degree has failed to resolve the current fault, select other scenarios in descending order of priority as the location measures to be taken for the current scenario.

[0088] The specific steps for resolving the current fault using the location method with the highest matching degree are as follows:

[0089] The sub-scenario types under the application scenario involved by the positioning measures with the highest matching degree are sorted according to the number of times the sub-scenario appears in the application scenario. Under the current application scenario, the sub-scenarios are analyzed one by one in the order of the number of occurrences until the current fault is resolved by the sub-scenario under the application scenario. The sub-scenario under the application scenario is recorded as the solution to the current fault.

[0090] Add the priority order of the current fault characteristics to the historical scenario library;

[0091] The current fault characteristics are classified into the three application scenarios, that is, the newly added scenarios are extended as sub-scenarios, and the number of times the current sub-scenarios appears is recorded as 1. When the current sub-scenarios appears later, the number of times the current sub-scenarios appears is incremented by 1. Finally, the number of times the current sub-scenarios appears over a period of time is counted.

[0092] When a sub-scene is adjusted to become the main scene, the number of times the sub-scene appears is set to U1. If the number of times the current sub-scene appears exceeds the set number of times the sub-scene is adjusted to become the main scene, the current sub-scene is adjusted to become the main scene. The formula for calculating the number of times the sub-scene is adjusted to become the main scene is as follows: U1 = γ * TNF.

[0093] Wherein, TNF represents the total number of faults, and γ represents the weighting coefficient.

[0094] Specifically, at a certain moment, store B experienced a network failure, some users failed to connect, and at the same time, the device logs frequently showed authentication errors.

[0095] Scenario matching: The fault is determined to be in the third type of application scenario. First, check the configuration snapshot of the edge device (store B switch), compare it with the historical correct configuration version, and find that a certain VLAN of the switch is misconfigured, causing some users to be unable to authenticate correctly;

[0096] Priority Calculation: Based on the impact scope and repair time involved in the application scenario, the application scenario priority calculation formula Asp=α*Si+β*Rt is constructed. The impact scope Si is determined to be 8 (out of 10) based on the number of affected users, the number of business functions, etc. The repair time Rt is expected to be 2 (the repair time for simple configuration errors is shorter). The weight coefficients α=0.6 and β=0.4. Then the priority of this scenario Asp=0.6×8+0.4×2=5.6. After comparing with the priority of other possible failure scenarios, the processing order is determined.

[0097] Troubleshooting: Based on the configuration snapshot comparison results, the switch VLAN configuration was corrected, the network returned to normal, users connected successfully, and the authentication error disappeared;

[0098] Recording and updating: Add the priority order of the current fault characteristics to the historical scenario library. This fault scenario is an extension of the third type of application scenario. The initial occurrence count is recorded as 1. When a similar fault scenario occurs again, the occurrence count of the sub-scenario is incremented by 1. Set the number of occurrences required when the sub-scenario is adjusted to the main scenario to U1 = γ × TNF (total number of faults TNF = 100, weight coefficient γ = 0.1, then U1 = 10). When the occurrence count of the sub-scenario exceeds 10 times, upgrade it to the main scenario and optimize the fault location strategy.

[0099] A network device fault rapid location system based on historical data includes a data acquisition module, a data processing module, a fault scenario analysis module, a fault location decision module, and a scenario management module. The data acquisition module collects historical operational data of the network devices. The data processing module cleans and preprocesses the collected network device-related data and extracts features from the preprocessed data. The fault scenario analysis module categorizes network faults into three application scenarios, locates them according to different logics, matches real-time features with a historical database, and calculates the priority of each application scenario. The fault location decision module evaluates the matching degree between current fault features and the three application scenarios, selects the most matching scenario as the fault location strategy, and records the execution priority order in a historical scenario database. The scenario management module expands newly identified fault scenarios as sub-scenarios and determines whether to upgrade them to primary scenarios based on their frequency of occurrence.

[0100] The data acquisition module includes a data acquisition unit and a time series construction unit. The data acquisition unit uses the SNMP protocol to collect data from multiple channels, including network devices, network traffic monitoring devices and network service providers, device monitoring systems, and device manufacturers. The collected data includes device logs, traffic information, device performance configuration data, and fault records. The time series construction unit is used to construct network traffic demand time series data and network device performance configuration time series data respectively from the collected traffic demand data and device performance configuration data according to their respective time intervals.

[0101] The data processing module includes a preprocessing unit, a feature extraction unit, and a feature selection unit. The preprocessing unit removes noisy data from the collected data, fills in missing values ​​in the traffic data using linear interpolation, and standardizes all data formats, storing them uniformly in a database table structure. The feature extraction unit extracts features from the preprocessed data, denoted as [T1, T2, ..., Tn]. The feature selection unit selects a decision tree machine learning model, using the preprocessed and feature-extracted data as input and historical fault records as labels to train the initial model. It measures the contribution of features to model performance by calculating the information gain of each feature, recursively removes the features with the smallest contribution, and retrains and evaluates the model. When the model performance fluctuation is within a set threshold, the removed feature set is retained; otherwise, the feature is restored. This process continues until the impact of all features on model performance reaches the set threshold, selecting the features with the greatest influence on fault prediction.

[0102] The fault scenario analysis module includes a scenario classification and localization unit and a priority calculation unit. The scenario classification and localization unit is used to classify network faults into three application scenarios and locate them according to different logics. The priority calculation unit is used to construct an application scenario priority calculation formula based on the impact range and repair time involved in the application scenario. The formula is used to calculate and analyze the priority order of the three application scenarios to determine the order of fault handling. The fault localization decision module includes a matching evaluation unit and a strategy execution verification unit. The matching evaluation unit is used to calculate the matching degree between the current fault characteristics and the three application scenarios, denoted as m1, m2, and m3, respectively. These matching degrees are sorted, and the scenario with the highest matching degree is selected as the initial fault localization strategy. The strategy execution verification unit is used to execute the localization strategy with the highest matching degree and determine whether the current fault is successfully resolved. If it is not resolved, other scenario localization measures are selected in descending order of priority to continue trying. For cases where the fault is successfully resolved, the relevant sub-scenarios are recorded as fault resolution measures.

[0103] The scenario management module includes a historical scenario recording unit and a scenario expansion and adjustment unit. The historical scenario recording unit is used to add the priority order of the current fault characteristics to the historical scenario library and record information during the fault handling process. The scenario expansion and adjustment unit is used to expand the newly identified fault scenario as a sub-scenario to the three types of application scenarios, count the number of times the sub-scenario appears, and adjust it to the main scenario when the number of times the sub-scenario appears exceeds the set number of times.

[0104] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered in all respects as exemplary and non-limiting, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

Claims

1. A method for rapid fault location of network devices based on historical data, characterized in that: The method includes the following steps: Collect historical operational data of network devices; Network failures are categorized into three application scenarios and located based on different logics; Network failures were categorized into three application scenarios and located according to different logics. The specific steps included: In the first type of application scenario: when the traffic in the i-th region drops to the designed traffic threshold and there is no switch error in the device log, historical link interruption cases are matched first in the first type of application scenario to directly trigger the link detection tool. Here, i is used to identify a specific region, and the designed traffic threshold is determined by historical data. In the second type of application scenario: when there are multiple areas and traffic anomalies, and the device log shows that the switch CPU / memory is overloaded or the port is down, in the second type of application scenario, the status of the core switch should be checked first and the recovery strategy for similar historical faults should be compared. In the third application scenario: when local users fail to connect and authentication errors or ARP conflicts frequently appear in the logs, the configuration snapshot of the edge device is checked first and compared with the historical correct configuration version. The first type of application scenario, the second type of application scenario, and the third type of application scenario together constitute the initial set of application scenarios for network device fault location. The collected network device data is cleaned and preprocessed. Based on the preprocessing results, recursive feature elimination and filtering are performed, and real-time features are matched with historical databases to calculate the priority of application scenarios. The collected network device-related data is cleaned and preprocessed to remove noise data. For traffic data, if the traffic value at a certain moment is missing, it is filled in using linear interpolation based on the traffic data of the preceding and following moments. The data format is standardized and all data is stored in a unified database table structure. Features are extracted from the preprocessed data and denoted as [T1,T2,...,Tn]. A decision tree machine learning model is selected for fault prediction, with the preprocessed and feature-extracted data as input and historical fault records as labels to train the initial model. The contribution of each feature to the model performance is measured by calculating the information gain of the features; Remove the feature with the smallest contribution from the current feature set, retrain the model, and evaluate the model performance. If the model performance fluctuates within q, retain the feature set after removing the feature; otherwise, restore the feature. Here, q represents a threshold parameter that measures the degree of change in model performance. Repeat the above process until the impact of all features in the feature set on the model performance reaches the set impact threshold, which is determined by cross-validation and model performance evaluation accuracy index. Real-time features are matched with historical databases and sorted by priority. The priority order of the three types of application scenarios is analyzed. An application scenario priority calculation formula is constructed based on the impact scope and repair time involved in the application scenario. According to the application scenario priority calculation formula, the three types of application scenarios are prioritized according to their priority. Assess the degree of matching between the current fault characteristics and the three types of application scenarios, select the most matching scenario as the fault localization strategy, and record the execution priority order in the historical scenario library. The three types of application scenarios belong to the main scenario category and are the initial application scenario set. For newly identified fault scenarios, they are expanded as sub-scenarios, and it is determined whether they need to be upgraded to main scenarios based on the frequency of occurrence. The main scenario refers to a set of representative and typical fault scenarios formed after classifying and summarizing network faults; the sub-scenarios refer to newly identified fault scenarios that have not yet been summarized into existing main scenarios during the fault localization process. Calculating the degree of matching between the current fault characteristics and the three types of application scenarios involves the following steps: Calculate the degree of matching between the current fault characteristics and the three types of application scenarios. When real-time data is compared with the three types of application scenarios one by one in a prescribed priority order, it is denoted as m1, m2 and m3. Here, m1 represents the degree of matching between real-time data and the first type of application scenario, m2 represents the degree of matching between real-time data and the second type of application scenario, and m3 represents the degree of matching between real-time data and the third type of application scenario. The calculated matching degrees m1, m2, and m3 between the current fault features and the three application scenarios are sorted, and the matching degree with the highest degree is selected as the localization strategy to be adopted for the current fault features. Determine whether the location strategy with the highest matching degree has successfully resolved the current fault. If the location strategy with the highest matching degree has failed to resolve the current fault, select other scenarios in descending order of priority as the required location strategy for the current scenario. The location strategy with the highest matching degree is used to resolve the current fault. The specific steps are as follows: The sub-scenario types under the application scenario involved by the positioning strategy with the highest matching degree are sorted according to the number of times the sub-scenario appears in the application scenario. Under the current application scenario, the sub-scenarios are analyzed one by one in the order of the number of occurrences until the current fault is resolved by the sub-scenario under the application scenario. The sub-scenario under the application scenario is recorded as the solution to the current fault. Add the priority order of the current fault characteristics to the historical scenario library; The current fault characteristics are classified into the three application scenarios, that is, the newly added scenarios are extended as sub-scenarios, and the number of times the current sub-scenarios appears is recorded as 1. When the current sub-scenarios appears later, the number of times the current sub-scenarios appears is incremented by 1. Finally, the number of times the current sub-scenarios appears over a period of time is counted. When a sub-scene is adjusted to become the main scene, the number of times the sub-scene appears is set to U1. If the number of times the current sub-scene appears exceeds the set number of times the sub-scene is adjusted to become the main scene, the current sub-scene is adjusted to become the main scene. The formula for calculating the number of times the sub-scene is adjusted to become the main scene is as follows: U1=γ*TNF. Wherein, TNF represents the total number of faults, and γ represents the weighting coefficient.

2. The method for rapid fault location of network devices based on historical data according to claim 1, characterized in that: Collecting historical operational data of network devices via the SNMP protocol, including device logs, traffic information, device performance configurations, and fault records, involves the following steps: Historical operational data of network devices is collected via the SNMP protocol, including device logs, traffic information, network device performance configuration, and fault records; wherein, the traffic information includes network traffic involving multiple areas of offline and online platforms, as well as network traffic demand data; The network traffic demand data represents the demand for data transmission traffic and traffic usage behavior characteristics in the network within a specific time period, denoted as [F1, F2, ..., Fz]; where z is a positive integer representing the number of traffic demand types, and F1, F2, ..., Fz represent the 1st, 2nd, ..., zth traffic demand types, respectively; the traffic demand data is obtained through network traffic monitoring equipment and network service providers; historical traffic demand data at different times have the same time interval Δf; the data is arranged in chronological order [f1, f2, ..., fw] to form a network traffic demand time series data; where w represents the number of times, and f1, f2, ..., fw represent the 1st, 2nd, ..., wth traffic demand data collection times, respectively; The network device performance configuration data represents the operating performance status, dynamic process of configuration parameter adjustment, and health status data of the network device, denoted as [P1, P2, ..., Pu]; where u is a positive integer representing the type of network device performance configuration data, P1, P2, ..., Pu representing the 1st, 2nd, ..., uth types of network device performance configuration data, respectively; the network device performance configuration data is obtained from the device's own monitoring system and the device manufacturer; the historical data of the network device performance configuration at different times have the same time interval Δp; the data is arranged in chronological order [p1, p2, ..., pv], forming the network device performance configuration time series data; where v represents the number of times, p1, p2, ..., pv representing the 1st, 2nd, ..., vth network device performance configuration data collection times, respectively.

3. A network device fault rapid location system based on historical data, applied to the network device fault rapid location method based on historical data as described in any one of claims 1-2, characterized in that: The system includes a data acquisition module, a data processing module, a fault scenario analysis module, a fault location decision module, and a scenario management module. The data acquisition module collects historical operating data of network devices. The data processing module is used to clean and preprocess the collected network device-related data, and extract features based on the preprocessed data. The fault scenario analysis module is used to categorize network faults into three application scenarios, locate them according to different logics, match real-time features with historical databases, and calculate the priority of application scenarios. The fault location decision module is used to evaluate the degree of matching between the current fault characteristics and the three types of application scenarios, select the most matching scenario as the fault location strategy, and record the execution priority order into the historical scenario library. The scenario management module is used to expand newly identified fault scenarios as sub-scenarios and determine whether to upgrade them to main scenarios based on the number of times they occur.

4. The network device fault rapid location system based on historical data according to claim 3, characterized in that: The data acquisition module includes a data acquisition unit and a time series construction unit. The data acquisition unit uses the SNMP protocol to collect data from multiple channels, including network devices, network traffic monitoring devices and network service providers, device monitoring systems, and device manufacturers. The collected data includes device logs, traffic information, device performance configuration data, and fault records. The time series construction unit is used to construct network traffic demand time series data and network device performance configuration time series data respectively from the collected traffic demand data and device performance configuration data according to their respective time intervals.

5. A network device fault rapid location system based on historical data according to claim 4, characterized in that: The data processing module includes a preprocessing unit, a feature extraction unit, and a feature selection unit. The preprocessing unit removes noisy data from the collected data, fills in missing values ​​in the traffic data using linear interpolation, and standardizes all data formats, storing them uniformly in a database table structure. The feature extraction unit extracts features from the preprocessed data, denoted as [T1, T2, ..., Tn]. The feature selection unit selects a decision tree machine learning model, using the preprocessed and feature-extracted data as input and historical fault records as labels to train the initial model. It measures the contribution of features to model performance by calculating the information gain of each feature, recursively removes the features with the smallest contribution, and retrains and evaluates the model. When the model performance fluctuation is within a set threshold, the removed feature set is retained; otherwise, the feature is restored. This process continues until the impact of all features on model performance reaches the set threshold, selecting the features with the greatest influence on fault prediction.

6. A network device fault rapid location system based on historical data according to claim 5, characterized in that: The fault scenario analysis module includes a scenario classification and positioning unit and a priority calculation unit. The scenario classification and positioning unit categorizes network faults into three application scenarios and locates them according to different logics. The priority calculation unit constructs an application scenario priority calculation formula based on the impact range and repair time involved in the application scenario, analyzes the priority order of the three application scenarios, and determines the order of fault handling. The fault location decision module includes a matching evaluation unit and a strategy execution verification unit. The matching evaluation unit is used to calculate the matching degree between the current fault characteristics and three types of application scenarios, denoted as m1, m2, and m3, respectively. These matching degrees are sorted, and the scenario with the highest matching degree is selected as the initial fault location strategy. The strategy execution verification unit is used to execute the location strategy with the highest matching degree and determine whether the current fault is successfully resolved. If it is not resolved, other scenario location strategies are selected in descending order of priority to continue trying. For cases where the fault is successfully resolved, the relevant sub-scenarios are recorded as fault resolution measures.

7. A network device fault rapid location system based on historical data according to claim 6, characterized in that: The scenario management module includes a historical scenario recording unit and a scenario expansion and adjustment unit. The historical scenario recording unit is used to add the priority order of the current fault characteristics to the historical scenario library and record information during the fault handling process. The scenario expansion and adjustment unit is used to expand the newly identified fault scenario as a sub-scenario to the three types of application scenarios, count the number of times the sub-scenario appears, and adjust it to the main scenario when the number of times the sub-scenario appears exceeds the set number of times.

Images