## 7 Experiment and Analysis
### Experimental Protocol and Analysis  
(1) Experiment Triggering  
To facilitate the experimentation, the test dataset encompassing the aforementioned nine fault categories was imported into the backend's historical alert table. Concurrently, a real-time alert table with an identical table structure was established. Upon commencing the testing of a specific fault type, a timed script, running every minute, was utilized to sequentially select the minute-by-minute test data for that fault type and insert it into the real-time alert table. Additionally, the actual insertion time was updated in the timestamp field of the real-time alert table. The proposed model in this paper scans the real-time alert table every minute, retrieves the latest one-minute alert events, and performs fault localization analysis. Through this approach, the simulation of faults is achieved, thus triggering the experimental procedures. (2) Scene Design  
Design the following two experimental scenarios, focusing on comparing hit rates and positioning timeliness. Scenario 1: Pay attention to the module for filtering and screening multiple source alarms, and compare the timeliness of the fault localization program running under the condition of canceling the module and under normal conditions. Due to the alarm storm problem during business failures, it will cause performance pressure on the troubleshooting system. Therefore, before the alarm data are accessed by the troubleshooting system, the screening and filtering of alarms is critical. Time T is the trigger time of the business alarm. For this scenario, we utilized the test dataset pertaining to Fault Case 4, which focuses on the anomaly of an access switch. The experiment was conducted in two phases, with each phase utilizing the fault data to simulate fault recording and playback by inserting an empty real-time alert table for a duration of 15 min. In the first phase, the alert filtering logic was omitted from the model program. Subsequently, in the second phase, the alert filtering logic was incorporated into the model program, enabling a comparative analysis of the results. The test results are shown in Table 5, Figures 6 and 7. \begin{table}
\begin{tabular}{c c c} \hline \hline
**Fault Type** & **Data Set Failure Cases** & **CData Scale** \\ \hline Networking & Core switch hardware failure & 1.32 Ten thousand/15 min \\  & Hardware failure of aggregation switch & 1.41 Ten thousand/minutes \\  & Firewall exception & 1.25 Ten thousand/minutes \\  & Abnormal hardware of access switch & 1.18 Ten thousand/minutes \\  & Load balancing failure & 1.25 Ten thousand/15 min \\ \hline The system & Abnormal computing node & 1.51 Ten thousand/minutes \\ \hline Database & Mutual visit database exception & 1.18 Ten thousand/minutes \\  & Cache exception & 1.23 Ten thousand/15 min \\ \hline Storage area & Distributed storage exception & 1.33 Ten thousand/minutes \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Data set. Test conclusion: At time T, the business-level life and death indicator alarm was triggered. Tracing back 10 time slices from time T, statistical analysis showed that the multi-source alarm screening step was canceled. At time T, the fault localization program  
Figure 6: Request time comparison. Figure 7: Number of alarms comparison.