Big data-based switch troubleshooting method and system

Abstract

The application discloses a switch troubleshooting method and system based on big data, relates to the technical field of network operation and maintenance, and utilizes an adaptive controller to distribute various network link state nodes and collect network state data; a stream processing engine is constructed, and a dynamic baseline alarm device is set to preliminarily classify the network state data; a controller code is adopted to query switch information corresponding to the network state data, and abnormal index analysis is performed to obtain fault data labels; and an AI pipeline detection is deployed to intelligently analyze the fault data labels, so that gradual optimization from alarm to root cause positioning is realized, and the average repair time is greatly shortened.

Description

Technical Field

[0001] This invention relates to the field of network operation and maintenance technology, and in particular to a method and system for troubleshooting switch faults based on big data. Background Technology

[0002] In the field of network communication technology, switches are the core interconnection devices for building local area networks and data centers. The stability and reliability of their operation directly determine the availability of the entire network services. Therefore, troubleshooting switches is an important part of network operation and maintenance.

[0003] Traditional methods for troubleshooting switch problems mainly rely on the following approaches: First, manual troubleshooting via command-line interface. After receiving a fault report, network engineers log into the suspected faulty switch via SSH or Telnet, execute a series of troubleshooting commands one by one, and manually observe and analyze the output results to determine the fault location. Second, simple network management protocol monitoring. By deploying a network management system (NMS), key performance indicators such as CPU utilization, memory usage, port traffic, and packet loss / error counts are collected, and static threshold alarm devices are set to troubleshoot the problem. Third, system log analysis. The switch sends important runtime events to a centralized log server, and maintenance personnel can trace the sequence of events that caused the fault by searching the log management interface using keywords after a fault occurs.

[0004] The aforementioned technologies cannot meet the rapid response requirements of modern services for high-availability networks. When faced with massive amounts of data, manual troubleshooting is inefficient and makes it difficult to classify and analyze the root causes of switch failures. Summary of the Invention

[0005] The technical problem solved by this invention is that it cannot meet the rapid response requirements of modern services for high-availability networks, manual troubleshooting is inefficient when faced with massive amounts of data, and it is difficult to classify and detect switch faults by root cause analysis.

[0006] To solve the above-mentioned technical problems, the present invention provides the following technical solution: The first aspect is a troubleshooting method for switches based on big data, which includes the following steps: Step S1: Use the adaptive controller to allocate the status nodes of each network link and collect network status data; Step S2: Build a streaming processing engine and set up a dynamic baseline alarm device to perform preliminary classification of the network status data; Step S3: Use controller coding to query the switch information corresponding to the network status data, and perform abnormal indicator analysis to obtain fault data tags; Step S4: Deploy AI pipeline detection to perform intelligent root cause analysis on the fault data tags.

[0007] Preferably, step S1 specifically includes: Step S11: Based on the performance fluctuation range, set the sampling frequency and sampling target for each network link status node; Step S12: Deploy controllers at each network link status node and collect link status information of all network switches through the interface; Step S13: Use distributed storage technology to store the link status information of all network switches and generate network status data; The network status data includes CPU status, timestamps, memory usage, port traffic, and packet error counts.

[0008] Preferably, step S2 specifically includes: The network status data is sorted chronologically, a streaming processing engine is built, a fixed time window is set to segment and package the network status data, generating several traffic data sequences, and the timestamp corresponding to the first row of sample data in the traffic data sequence is used as the time point of the current traffic data sequence. Calculate the average port traffic of several traffic data sequences at corresponding time points as the first state, then sort the traffic data sequences by incremental trend, calculate the slope of port traffic in the current window, and generate the second state. Take one day as a period length, calculate the periodicity coefficient of one day according to the fixed time window interval, and save the first state, the second state and the periodicity coefficient as a state feature sequence. The triple exponential smoothing model is used to predict the state feature sequence and generate a baseline prediction value. The baseline prediction value is the network state data at the next time moment predicted by the triple exponential smoothing model using the state feature sequence of the previous time window. When new network state data arrives, the error between the current network state data and the baseline prediction value is calculated to obtain an error window sequence. The error window sequence is used to define the scalar value of the uncertainty of the current model.

[0009] Preferably, step S2 further includes: Calculate the standard deviation of all errors in the error window sequence, and use the baseline predicted value and the standard deviation to construct the dynamic interval of the dynamic baseline alarm device. The range of the dynamic interval is the baseline predicted value. Two standard deviations; The network status data is first judged based on the dynamic range to generate first status data and second status data. When the network status data is greater than the dynamic range at the current time, the network status data is judged to be abnormally high and classified as first status data. When the network status data is less than the dynamic range at the current time, the network status data is judged to be abnormally low and classified as second status data.

[0010] Preferably, step S3 specifically includes: Step S31: Use the controller coding driver to query the switch device data corresponding to the first status data and the second status data. The switch device data includes device model, serial number, location, topology information and upstream and downstream devices. The first status data, the second status data and the switch device data are saved as the first abnormal data. Step S32: Write a header data before each sample of the switch device data. The header data is used to mark the data flow information of the switch and its upstream and downstream devices before each sample. The header data includes ingress / egress port, timestamp, queue delay, queue congestion level and buffer occupancy rate. Step S33: Record the timestamp of the first abnormal data entering the switch, and add another timestamp when it leaves the switch. Calculate the difference between the timestamps to obtain the processing delay of the data packet inside the switch chip. Step S34: Set up an anomaly detection engine at the switch egress point to perform mirror matching diagnosis on the first anomaly data and processing delay to obtain fault data tags.

[0011] Preferably, the specific method for setting up an anomaly detection engine at the switch egress point to perform mirror matching diagnosis on the first abnormal data and processing delay is as follows: The anomaly detection engine is used to design the discrimination logic code. When there is an anomaly flag packet in the first anomaly data, the current sample is mirrored. When the processing delay time is too high, the current sample is mirrored. When the outgoing queue is congested, some samples are randomly selected to be mirrored. All samples that are mirrored are packaged into a mirror package and sent to the backend monitoring server. In the backend monitoring server, a multivariate regression analysis is performed on the mirror package to obtain fault data labels.

[0012] Preferably, the method for the multiple regression analysis is as follows: Extract the trigger time, ingress port number, egress port number, and processing delay of the image package, and perform DBscan density clustering analysis to generate a density heatmap and find the fault data labels corresponding to the delay hotspots.

[0013] Preferably, step S4 specifically includes: The AI ​​pipeline detection is deployed in the backend. When the image package contains a sample with the corresponding fault data label, the AI ​​pipeline is triggered. At the same time, the first abnormal data corresponding to the fault event is extracted. After feature engineering extraction of the first abnormal data, the associated features and related topology map are obtained. The root cause analysis model is constructed. The associated features are input into the root cause analysis model, and the root cause analysis diagnosis report is output.

[0014] Preferably, the specific content of constructing the root cause analysis model is as follows: By integrating correlation features and related topology graphs, a root cause analysis model is constructed. The first abnormal data is trained based on a machine learning model to generate a root cause probability distribution. The related topology graphs are then used to store historical fault cases, operation and maintenance rules, and the relationships between the upper and lower layers of the devices. The root cause probability distributions are then incorporated into the related topology graphs for verification.

[0015] Secondly, a big data-based switch troubleshooting system includes a link acquisition module, a preliminary classification module, an anomaly detection module, and a root cause analysis module. The preliminary classification module is used to build a streaming processing engine and set up a dynamic baseline alarm device to perform preliminary classification of the network status data to obtain first status data and second status data. The anomaly detection module is used to set up controllers before and after the switch input, detect the switch information corresponding to the network status data, and perform anomaly indicator analysis to obtain fault data tags. The root cause analysis module deploys AI pipeline detection, performs feature engineering extraction and related topology graph construction on the fault data labels, and generates intelligent root cause analysis results.

[0016] The beneficial effects of this invention are as follows: First, an adaptive acquisition strategy is adopted, with the controller issuing decisions to the collectors at each node. The collectors execute instructions to accurately acquire high-quality network status data. Then, a triple exponential smoothing model is used to adaptively learn the normal behavior patterns of the data. The implemented data is compared with the model's predicted baseline values ​​and fluctuation ranges to initially screen abnormal event streams. Next, rich contextual information is injected into the previously generated abnormal events, and through rules and simple associations, they are upgraded to fault events with clear semantics, generating structured fault data labels rich in context. Finally, based on a machine learning model, in-depth mining and pattern recognition are performed on historical and real-time data to output a root cause analysis report, including the most likely root cause, confidence level, evidence, and remediation suggestions. This achieves a step-by-step optimization from alarm to root cause localization, greatly shortening the average repair time. Attached Figure Description

[0017] Figure 1 A flowchart illustrating the steps of a big data-based switch troubleshooting method according to an embodiment of the present invention; Figure 2 This is a basic flowchart of a big data-based switch troubleshooting system provided in one embodiment of the present invention. Detailed Implementation

[0018] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0019] Example 1, referring to Figure 1 It provides a method for troubleshooting switch faults based on big data, including the following steps: Step S1: Use the adaptive controller to allocate the status nodes of each network link and collect network status data; Step S2: Build a streaming processing engine and set up a dynamic baseline alarm device to perform preliminary classification of network status data; Step S3: Use controller coding to query the switch information corresponding to the network status data, and perform abnormal indicator analysis to obtain fault data tags; Step S4: Deploy AI pipeline detection and perform intelligent root cause analysis on fault data tags.

[0020] In this embodiment, an adaptive acquisition strategy is first adopted. The controller sends decisions to the collectors at each node, and the collectors execute instructions to accurately acquire high-quality network status data. Then, a triple exponential smoothing model is used to adaptively learn the normal behavior patterns of the data. The implemented data is compared with the model's predicted baseline values ​​and fluctuation ranges to initially screen abnormal event streams. Then, rich contextual information is injected into the previously generated abnormal events, and through rules and simple associations, they are upgraded to fault events with clear semantics, generating structured fault data labels rich in context. Finally, based on the machine learning model, in-depth mining and pattern recognition are performed on historical and real-time data to output a root cause analysis report, including the most likely root cause, confidence level, evidence, and remediation suggestions. This achieves step-by-step optimization from alarm to root cause location, greatly shortening the average repair time.

[0021] Step S1 specifically includes: Step S11: Based on the performance fluctuation range, set the sampling frequency and sampling target for each network link status node; Step S12: Deploy controllers at each network link status node and collect link status information of all network switches through the interface; Step S13: Use distributed storage technology to store the link status information of all network switches and generate network status data; Network status data includes CPU status, timestamps, memory usage, port traffic, and packet error counts.

[0022] First, an SDN controller is set up to continuously monitor the fluctuation range of each network link node. When the fluctuation range of a node or link exceeds a preset threshold, the controller will dynamically make a decision to increase the sampling frequency of the target (from once per minute to once every 5 seconds) and list it as a high-priority sampling target. Conversely, the frequency of stable nodes will be reduced to save resources. Then, a distributed architecture is adopted, and a lightweight collector is deployed in each network node or area. The collector collects the link status information of the entire network switches through standard interfaces (such as SNMP, gRPC, NETCONF). This method avoids the single-point bottleneck and network latency that may be caused by centralized collection. Finally, the collector sends the collected data to the central platform, stores it using distributed storage technology, and adds a timestamp to generate structured network status data. In this embodiment, the controller dynamically adjusts the monitoring frequency of network nodes, which greatly reduces unnecessary monitoring overhead and the impact on the performance of network devices. At the same time, it can capture transient faults and minor sudden events more quickly. The distributed acquisition architecture avoids the performance bottleneck of a single acquisition server. When the network scale expands, only new acquisition nodes need to be added to expand the acquisition capacity, effectively improving the efficiency of data acquisition and the accuracy of the data itself.

[0023] Step S2 specifically includes: The network status data is sorted chronologically, a streaming processing engine is built, and a fixed time window is set to segment and package the network status data to generate several traffic data sequences. The timestamp corresponding to the first sample data of the traffic data sequence is used as the time point of the current traffic data sequence. Calculate the average port traffic of several traffic data sequences at corresponding time points as the first state. Then sort the traffic data sequences by incremental trend, calculate the slope of port traffic in the current window, and generate the second state. Take one day as a period length, calculate the periodicity coefficient of one day according to the fixed time window interval, and save the first state, the second state and the periodicity coefficient as a state feature sequence. The triple exponential smoothing model is used to predict the state feature sequence and generate a baseline prediction value. The baseline prediction value is the network state data at the next time step predicted by the triple exponential smoothing model using the state feature sequence of the previous time window. When the new network state data arrives, the error between the current network state data and the baseline prediction value is calculated to obtain the error window sequence. The error window sequence is used to define the scalar value of the uncertainty of the current model.

[0024] A streaming engine is built. Within a five-second window, 60 traffic data points from a given port are received. These 60 data points are sorted by time and packaged into a traffic data sequence S1. The start time of this sequence is taken as the time point T1 of the sequence. The arithmetic mean of the 60 data points is calculated, representing the average traffic level within five seconds, as the first state. Linear regression or simple difference is used to calculate the slope of the current sequence. Using the time axis as the x-axis and the traffic value as the y-axis, a straight line y=βx+α is fitted, and the slope β is the second state. The window at the same time yesterday is found, and the first state of that window is calculated. Then, the ratio of today's window level to the level of yesterday's window at the same time is calculated as the periodicity coefficient. The first state, the second state, and the periodicity coefficient are stored as a vector as the state feature F1 of time point T1. Using the sequence F1, F2,..., the state feature F2_predicted of the next time point T2 is predicted. F2_predicted is a baseline prediction value that includes the expected average flow, trend and seasonality over the past 5 minutes. When the real window ends, we calculate the real state feature F2_real, calculate the error between the real value and the predicted value (for a three-dimensional feature vector, the error is also three-dimensional), save the prediction errors [E1, E2, ..., E100] of the most recent N (e.g. 100) time windows, calculate the standard deviation (σ) of this error sequence, and set the dynamic prediction interval. The final baseline prediction value is not a point, but a range: [F_predicted-2σ, F_predicted+2σ].

[0025] In this embodiment, faults that develop slowly and are difficult to detect with traditional thresholds can be detected. For example, if the bit error rate of a link increases by 0.1% per day, the trend component will remain a small positive value. After several weeks, although the absolute value does not instantly exceed a certain threshold, its clear growth trend will be captured by the model, thus issuing an early warning before the fault fully erupts. This embodiment constructs an intelligent network anomaly detection system by combining stream processing, feature engineering, and time series prediction models.

[0026] Step S2 also includes: Calculate the standard deviation of all errors in the error window sequence. Using the baseline predicted value and the standard deviation, construct the dynamic interval of the dynamic baseline alarm device. The range of the dynamic interval is the baseline predicted value. Two standard deviations; The network status data is first judged based on the dynamic range, generating first status data and second status data. When the network status data is greater than the dynamic range at the current time, the network status data is judged to be abnormally high and classified as first status data. When the network status data is less than the dynamic range at the current time, the network status data is judged to be abnormally low and classified as second status data.

[0027] The actual average traffic value F_real_level within 5 minutes is calculated and compared with the dynamic range to determine the generation of first and second state data. In this embodiment, the dynamic range is adjusted accordingly based on the predicted baseline value, which accurately distinguishes between business peaks and abnormal peaks. There is no need to manually increase the static threshold as business grows. The dynamic range of this method is bidirectional and has the same detection capability for both excessively high and excessively low values, covering a more comprehensive range of fault scenarios.

[0028] Step S3 specifically includes: Step S31: Use the controller coding driver to query the switch device data corresponding to the first state data and the second state data. The switch device data includes the device model, serial number, location, topology information and upstream and downstream devices. The first state data, the second state data and the switch device data are saved as the first abnormal data. Step S32: Write a header data before each sample of switch device data. The header data is used to mark the data flow information of the switch and its upstream and downstream devices before each sample. The header data includes ingress / egress port, timestamp, queue delay, queue congestion level and buffer occupancy rate. Step S33: Record the timestamp of the first abnormal data entering the switch, and add another timestamp when it leaves the switch. Calculate the difference between the timestamps to obtain the processing delay of the data packet inside the switch chip. Step S34: Set up an anomaly detection engine at the switch egress point to perform mirror matching diagnosis on the first abnormal data and processing delay to obtain fault data tags.

[0029] In this embodiment, the source is quickly located through tray relationships and internal telemetry. Only one root cause alarm needs to be reported, and all downstream derivative alarms are suppressed. Furthermore, transient micro-bursts and gray faults are detected. The switch port may not be completely down (the port status is still UP), but its performance is degraded due to uplink congestion. This embodiment can clearly capture this performance degradation by processing two internal indicators, latency and queue depth, and achieve more in-depth fault detection.

[0030] The specific method for setting up an anomaly detection engine at the switch egress point and performing mirror matching diagnosis on the first abnormal data and processing latency is as follows: The anomaly detection engine is used to design the discrimination logic code. When an anomaly flag packet exists in the first anomaly data, the current sample is mirrored. When the processing delay is too high, the current sample is mirrored. When the outgoing queue is congested, some samples are randomly selected for mirroring. All samples that are mirrored are packaged into an image package and sent to the backend monitoring server. In the backend monitoring server, multivariate regression analysis is performed on the image package to obtain fault data labels.

[0031] In this embodiment, by employing a random sampling statistical method, representative data is obtained with minimal overhead, avoiding itself from becoming a performance bottleneck. Computationally intensive data analysis is offloaded to the backend server, and hidden causal relationships between variables are mined from the enriched image package data, thereby going beyond simple correlation. Through anomaly flags and random sampling mechanisms, the performance disaster caused by traditional full image processing is avoided.

[0032] The method of multiple regression analysis is as follows: Extract the trigger time, ingress port number, egress port number, and processing delay of the image package, and perform DBscan density clustering analysis to generate a density heatmap and find the fault data labels corresponding to the delay hotspots.

[0033] The image packet includes the following: image trigger timestamp, switch ID, ingress port number, egress port number, and processing latency. A two-dimensional coordinate space is created, with the X-axis representing time, the Y-axis representing the port path, and the Z-axis representing the average processing latency of all image packets on that time window and port path. A data visualization library is used to plot the above two-dimensional data into a heatmap using a gradient color scheme (e.g., green -> yellow -> red), where green represents low latency (normal) and red represents high latency (abnormal). A hot spot (red area) is clearly displayed on the heatmap, indicating that the processing latency is abnormally high on the Gi2 / 0 / 10 egress port of the switch (regardless of which ingress port it enters from, as long as it exits from this egress port). This embodiment avoids complex technical discussions based on command line output, greatly improving communication efficiency.

[0034] Step S4 specifically includes: The AI ​​pipeline detection is deployed in the backend. When a sample with the corresponding fault data label appears in the image package, the AI ​​pipeline is triggered. At the same time, the first abnormal data corresponding to the fault event is extracted. After feature engineering extraction of the first abnormal data, the associated features and related topology map are obtained. The root cause analysis model is constructed. The associated features are input into the root cause analysis model, and the root cause analysis diagnosis report is output.

[0035] In this embodiment, the analysis and diagnostic report obtained by running the root cause analysis model no longer stays at the level of core switch port congestion, but accurately locates the source device causing the congestion, which greatly improves the reliability of the AI ​​system in operation and maintenance work. The automated system can parse this report, check its port count and restart predefined operations such as potentially faulty ports, and finally achieve network self-healing.

[0036] The specific content of constructing the root cause analysis model is as follows: By integrating correlation features with relevant topology graphs, a root cause analysis model is constructed. The model is trained on the first abnormal data based on a machine learning model to generate a root cause probability distribution. The relevant topology graphs are then used to store historical fault cases, operation and maintenance rules, and the relationships between the upper and lower layers of the devices. Finally, the root cause probability distribution is incorporated into the relevant topology graphs for verification.

[0037] In this embodiment, a gradient boosting tree model (XGBoost) is trained using labeled fault cases. The associated feature vectors obtained in the previous step are input into the model, and the network state (device indicators, connection relationships) at the time of the fault is constructed into a graph. The centrality algorithm is run, and the abnormal indicators propagate in the graph. The algorithm finds the signal source that first shows an anomaly. After the XGBoost model analyzes the feature vectors, the model outputs the predicted probability. The generated root cause analysis diagnostic report includes associated features, causal analysis, topology analysis, and detection suggestions.

[0038] Example 2, refer to Figure 2 It provides a big data-based switch troubleshooting system, including a link acquisition module, a preliminary classification module, an anomaly detection module, and a root cause analysis module; The preliminary classification module is used to build the streaming processing engine and set up a dynamic baseline alarm device to perform preliminary classification of network status data to obtain first status data and second status data. The anomaly detection module is used to set up controllers before and after the switch input, detect the switch information corresponding to the network status data, and perform anomaly indicator analysis to obtain fault data tags. The root cause analysis module deploys AI pipeline detection, performs feature engineering extraction on fault data labels and constructs relevant topology graphs to generate intelligent root cause analysis results.

[0039] In this embodiment, the system is divided into a link acquisition module, a preliminary classification module, an anomaly detection module, and a root cause analysis module. The system achieves full-process automation from data acquisition, preliminary judgment, in-depth analysis to root cause location. Through the streaming processing of the preliminary classification module, it can monitor all indicators of all devices in the network in real time. Through the controller query and mirror diagnosis of the anomaly detection module, it can conduct fine-grained investigation of specific anomalies and obtain in-depth data of the switch (such as queue latency and cache usage). The dynamic baseline alarm device can learn the normal behavior pattern of each indicator and adapt to its periodic changes and long-term trends. The root cause analysis module is no longer a simple keyword matching or rule filtering, but extracts the correlation features between devices through feature engineering and performs global analysis in combination with the topology map, providing the possibility for predictive maintenance.

[0040] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product implemented on one or more computer-usable storage media containing computer-usable program code. The storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium 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.

[0041] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A method for troubleshooting switch faults based on big data, characterized in that, Includes the following steps: Step S1: Use the adaptive controller to allocate the status nodes of each network link and collect network status data; Step S2: Build a streaming processing engine and set up a dynamic baseline alarm device to perform preliminary classification of the network status data; Step S3: Use controller coding to query the switch information corresponding to the network status data, and perform abnormal indicator analysis to obtain fault data tags; Step S4: Deploy AI pipeline detection to perform intelligent root cause analysis on the fault data tags; Step S2 specifically includes: The network status data is sorted chronologically, a streaming processing engine is built, a fixed time window is set to segment and package the network status data, generating several traffic data sequences, and the timestamp corresponding to the first row of sample data in the traffic data sequence is used as the time point of the current traffic data sequence. Calculate the average port traffic of several traffic data sequences at corresponding time points as the first state, then sort the traffic data sequences by incremental trend, calculate the slope of port traffic in the current window, and generate the second state. Take one day as a period length, calculate the periodicity coefficient of one day according to the fixed time window interval, and save the first state, the second state and the periodicity coefficient as a state feature sequence. Using a triple exponential smoothing model, the state feature sequence is predicted to generate a baseline prediction value. The baseline prediction value is the network state data at the next time step predicted by the triple exponential smoothing model using the state feature sequence of the previous time window. When new network state data arrives, the error between the current network state data and the baseline prediction value is calculated to obtain an error window sequence. The error window sequence is used to define the scalar value of the uncertainty of the current model. Step S2 further includes: Calculate the standard deviation of all errors in the error window sequence, and use the baseline predicted value and the standard deviation to construct the dynamic interval of the dynamic baseline alarm device. The range of the dynamic interval is the baseline predicted value. Two standard deviations; The network status data is first judged based on the dynamic range to generate first status data and second status data. When the network status data is greater than the dynamic range at the current time, the network status data is judged to be abnormally high and classified as first status data. When the network status data is less than the dynamic range at the current time, the network status data is judged to be abnormally low and classified as second status data.

2. The method for troubleshooting switch faults based on big data as described in claim 1, characterized in that, Step S1 specifically includes: Step S11: Based on the performance fluctuation range, set the sampling frequency and sampling target for each network link status node; Step S12: Deploy controllers at each network link status node and collect link status information of all network switches through the interface; Step S13: Use distributed storage technology to store the link status information of all network switches and generate network status data; The network status data includes CPU status, timestamps, memory usage, port traffic, and packet error counts.

3. The method for troubleshooting switch faults based on big data as described in claim 2, characterized in that, Step S3 specifically includes: Step S31: Use the controller coding driver to query the switch device data corresponding to the first status data and the second status data. The switch device data includes device model, serial number, location, topology information and upstream and downstream devices. The first status data, the second status data and the switch device data are saved as the first abnormal data. Step S32: Write a header data before each sample of the switch device data. The header data is used to mark the data flow information of the switch and its upstream and downstream devices before each sample. The header data includes ingress / egress port, timestamp, queue delay, queue congestion level and buffer occupancy rate. Step S33: Record the timestamp of the first abnormal data entering the switch, and add another timestamp when it leaves the switch. Calculate the difference between the timestamps to obtain the processing delay of the data packet inside the switch chip. Step S34: Set up an anomaly detection engine at the switch egress point to perform mirror matching diagnosis on the first anomaly data and processing delay to obtain fault data tags.

4. The method for troubleshooting switch faults based on big data as described in claim 3, characterized in that, The specific method for setting up an anomaly detection engine at the switch egress point to perform mirror matching diagnosis on the first abnormal data and processing latency is as follows: The anomaly detection engine is used to design the discrimination logic code. When there is an anomaly flag packet in the first anomaly data, the current sample is mirrored. When the processing delay time is too high, the current sample is mirrored. When the outgoing queue is congested, some samples are randomly selected to be mirrored. All samples that are mirrored are packaged into a mirror package and sent to the backend monitoring server. In the backend monitoring server, a multivariate regression analysis is performed on the mirror package to obtain fault data labels.

5. The method for troubleshooting switch faults based on big data as described in claim 4, characterized in that, The method for the multiple regression analysis is as follows: Extract the trigger time, ingress port number, egress port number, and processing delay of the image package, and perform DBscan density clustering analysis to generate a density heatmap and find the fault data labels corresponding to the delay hotspots.

6. The method for troubleshooting switch faults based on big data as described in claim 5, characterized in that, Step S4 specifically includes: The AI ​​pipeline detection is deployed in the backend. When the image package contains a sample with the corresponding fault data label, the AI ​​pipeline is triggered. At the same time, the first abnormal data corresponding to the fault event is extracted. After feature engineering extraction of the first abnormal data, the associated features and related topology map are obtained. The root cause analysis model is constructed. The associated features are input into the root cause analysis model, and the root cause analysis diagnosis report is output.

7. The method for troubleshooting switch faults based on big data as described in claim 6, characterized in that, The specific content of constructing the root cause analysis model is as follows: By integrating correlation features and related topology graphs, a root cause analysis model is constructed. The first abnormal data is trained based on a machine learning model to generate a root cause probability distribution. The related topology graphs are then used to store historical fault cases, operation and maintenance rules, and the relationships between the upper and lower layers of the devices. The root cause probability distributions are then incorporated into the related topology graphs for verification.

8. A big data-based switch troubleshooting system, applied in any one of the big data-based switch troubleshooting methods as described in claims 1-7, characterized in that, It includes a link acquisition module, a preliminary classification module, an anomaly detection module, and a root cause analysis module; The preliminary classification module is used to build a streaming processing engine and set up a dynamic baseline alarm device to perform preliminary classification of the network status data to obtain first status data and second status data. The anomaly detection module is used to set up controllers before and after the switch input, detect the switch information corresponding to the network status data, and perform anomaly indicator analysis to obtain fault data tags. The root cause analysis module deploys AI pipeline detection, performs feature engineering extraction and related topology graph construction on the fault data labels, and generates intelligent root cause analysis results.

Images