A multi-dimensional solid-state drive testing anomaly monitoring method and system

Abstract

This invention discloses a multi-dimensional solid-state drive (SSD) testing anomaly monitoring method and system, belonging to the field of SSD technology. The method includes the following stages: Rule base construction stage: A scalable anomaly judgment rule base is pre-built; Data acquisition and input stage: During SSD testing, multi-dimensional monitoring data is collected in real-time through the testing framework and input into the anomaly judgment module; Scene matching and rule selection stage: The corresponding anomaly judgment rules are automatically matched according to the current test scenario; Multi-dimensional collaborative judgment stage: Parallel processing is used to perform anomaly judgment on the monitoring data of each dimension separately, and data correlation analysis is performed based on the logical conditions in the anomaly judgment rule base; Result generation and output stage: The judgment results of each dimension are integrated to generate an anomaly report and output to a specified file path. This invention achieves full coverage of anomaly detection through multi-dimensional data fusion analysis, improving the accuracy of anomaly detection and effectively avoiding missed detection of silent faults.

Description

Technical Field

[0001] This invention relates to the field of solid-state drive (SSD) technology, and in particular to a multi-dimensional SSD testing anomaly monitoring method and system. Background Technology

[0002] During the SSD product verification phase, various automated tests are required, including basic functional tests, reliability tests, and long-term stability tests, to verify their reliability, durability, and stability under extreme operating conditions. Currently, mainstream monitoring methods have the following significant limitations: Manual inspection mode: Test engineers need to periodically log in to each test server and manually check the SSD's SMART attributes, performance metrics, device status, system logs, test processes, etc. This method is extremely inefficient, cannot achieve real-time monitoring, and is prone to missed detections due to human error.

[0003] Limitations of general monitoring tools: Existing monitoring systems (such as Zabbix and Prometheus) primarily monitor general server metrics and lack in-depth monitoring capabilities for SSD-specific parameters and disk logs. These tools cannot effectively identify SSD-specific anomaly patterns, such as flash memory wear and read / write errors.

[0004] Existing SSD testing and monitoring solutions are mostly simple monitoring systems based on threshold alarms. Their main characteristics include: monitoring only a limited number of general SMART parameters (such as temperature, remaining lifespan percentage, etc.); using fixed thresholds for anomaly detection, lacking flexibility; providing only basic real-time status display functions; and being able to remotely acquire and save disk status information, but still requiring manual judgment.

[0005] The existing technology has the following problems: 1. Incomplete detection due to limited monitoring metrics: Existing solutions only monitor a small number of general SMART parameters and use uniform, fixed thresholds for anomaly detection, failing to cover the complete health metric system required for SSD testing. Root cause: A lack of in-depth understanding of SSD-specific parameters and professional monitoring strategies leads to many silent anomalies (such as correctable errors, link errors, and recoverable abnormal states) going undetected, or expected anomalies being incorrectly reported.

[0006] 2. Insufficient adaptability due to poor manufacturer compatibility. Problem manifestations: Different manufacturers and generations of SSDs exhibit significant differences in anomaly behavior, monitoring parameters, and judgment criteria. Existing technologies cannot effectively adapt to this diversity. Root cause: The monitoring system lacks a configurable rule base and flexible adaptation mechanism, making it unable to set personalized monitoring strategies based on the characteristics of different SSD models, resulting in a low anomaly interception rate.

[0007] 3. Inadequate anomaly detection mechanisms lead to difficulties in problem localization. Problem manifestation: Existing systems typically only focus on the final test results, neglecting to monitor all metrics and log records during the testing process, making it difficult to detect and analyze silent faults. Root cause: Lack of robust multi-dimensional data correlation analysis capabilities and intelligent early warning mechanisms; problem localization relies excessively on manual experience, resulting in low efficiency and a high risk of errors.

[0008] With the rapid development of SSD technology and the continuous expansion of application scenarios, higher requirements are placed on test monitoring systems: Real-time requirements: 24 / 7 uninterrupted monitoring is required to promptly detect potential faults; Comprehensive requirements: coverage of multi-dimensional data such as SMART parameters, performance indicators, and system logs is required; Intelligent requirements: an intelligent early warning mechanism is required to reduce false alarm and false negative rates; Compatibility requirements: adaptability to the testing needs of SSD products from different manufacturers and platforms is required.

[0009] Based on the above analysis, the present invention aims to solve the following core technical problems: 1. How to automate the collection and intelligent judgment of key abnormal indicators during SSD testing; 2. How to improve the compatibility of the monitoring system with SSD products from different manufacturers and platforms; 3. How to design an effective multi-dimensional anomaly monitoring mechanism to ensure the accuracy of test fault judgment; 4. How to establish a sound anomaly data tracing mechanism to support rapid problem location and analysis. Summary of the Invention

[0010] The purpose of this invention is to overcome the shortcomings of the prior art and provide a multi-dimensional solid-state drive testing anomaly monitoring method and system.

[0011] The objective of this invention is achieved through the following technical solution: The first aspect of this invention provides a multi-dimensional solid-state drive (SSD) testing anomaly monitoring method, comprising the following steps: Rule base construction phase: Pre-build an extensible exception judgment rule base, and store exception judgment rules according to different test scenarios; Data acquisition and input phase: During the solid-state drive testing process, multi-dimensional monitoring data is collected in real time through the testing framework, and the multi-dimensional monitoring data is input into the anomaly judgment module. Scenario matching and rule selection phase: Automatically match the corresponding anomaly judgment rules based on the current test scenario; Multi-dimensional collaborative judgment stage: Parallel processing is adopted to judge the anomalies of the monitoring data of each dimension separately, and data correlation analysis is performed based on the logical conditions in the anomaly judgment rule base; Results generation and output phase: Integrate the judgment results from various dimensions, generate an anomaly report and output it to a specified file path for the test framework to read in order to achieve automated fault reporting.

[0012] Preferably, the test scenarios include basic function general tests, fault injection tests, performance tests, and power-down tests.

[0013] Preferably, the rule base construction phase further includes the following steps: Establish a default judgment template that covers a combination of various test parameters and test scenarios; set up a rule extension interface for users to add test scenarios and judgment parameters; and set modifiable threshold conditions and logical operators for each rule.

[0014] Preferably, the multi-dimensional monitoring data includes SMART parameters, disk logs, host logs, and performance data.

[0015] Preferably, in the data acquisition and input phase, for short-term test cases, data is collected once before and once after the test; for long-term test cases, data is collected once at the start of the test, and then collected at regular intervals every day thereafter; SMART parameters are read using ATA commands, and host logs and disk logs are collected using system log tools.

[0016] Preferably, when performing anomaly detection on SMART parameters, the following steps are included: The system compares the difference between two sets of SMART data; classifies and judges SMART parameters; and dynamically calculates write amplification and lifetime wear.

[0017] Preferably, it also includes a feedback optimization phase: calculating the anomaly interception rate based on historical judgment results; dynamically adjusting the threshold parameters in the anomaly judgment rule base based on the anomaly interception rate; and adding other anomaly patterns to the rule base to expand the coverage.

[0018] A second aspect of the present invention provides: a multi-dimensional solid-state drive (SSD) test anomaly monitoring system, used to implement any of the above-mentioned multi-dimensional SSD test anomaly monitoring methods, comprising: The rule base building module is used to pre-build an extensible exception judgment rule base. The exception judgment rule base stores exception judgment rules according to different test scenarios. The data acquisition and input module is used to collect multi-dimensional monitoring data in real time through the test framework during solid-state drive testing, and input the multi-dimensional monitoring data into the anomaly judgment module. The scenario matching and rule selection module is used to automatically match the corresponding anomaly judgment rules based on the current test scenario; The multi-dimensional collaborative judgment module is used to perform anomaly judgment on monitoring data of each dimension in parallel processing, and to perform data correlation analysis based on the logical conditions in the anomaly judgment rule base. The results generation and output module is used to integrate the judgment results from various dimensions, generate anomaly reports and output them to a specified file path for the test framework to read in order to achieve automated fault reporting.

[0019] A third aspect of the present invention provides: a computer-readable storage medium storing computer-executable instructions, wherein when the computer-executable instructions are loaded and executed by a processor, the above-described multi-dimensional solid-state drive test anomaly monitoring method is implemented.

[0020] The beneficial effects of this invention are: 1) This invention achieves full coverage of anomaly detection through multi-dimensional data fusion analysis (SMART parameters, disk logs, host logs, and performance data). The dynamic rule base supports scenario-based intelligent judgment, improving the accuracy of anomaly detection and effectively avoiding missed detection of silent faults.

[0021] 2) The configurable rule base adapts to SSD products from different manufacturers and platforms, supporting SATA / NVMe protocols. The modular architecture offers excellent scalability, allowing for rapid adaptation when adding new test scenarios and monitoring parameters, significantly improving the versatility of the technical solution.

[0022] 3) Enables 24 / 7 automated monitoring, reducing manual inspection workload by over 90%. The intelligent early warning mechanism shortens fault response time, supports batch device management, and increases the number of devices that test engineers can manage simultaneously. Attached Figure Description

[0023] Figure 1 This is a diagram illustrating the architecture of the anomaly detection principle. Figure 2 Flowcharts for various types of exception handling. Detailed Implementation

[0024] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments. 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.

[0025] First, some terms in this invention are explained: SSD (Solid State Drive): A storage device that uses flash memory chips as the storage medium.

[0026] Long-term stability test: This test verifies the reliability and durability of a product under continuous operating conditions.

[0027] SMART (Self-Monitoring, Analysis and Reporting Technology): This technology is used for monitoring the health status of storage devices. The data required by this technology can be read using the ATA command "SMARTRETURN STATUS".

[0028] WA (Write Amplification): The ratio of the actual amount of data written to the flash memory to the amount of data written to the host. A higher WA value indicates that the flash memory wears out faster.

[0029] Bad Block: A storage unit in flash memory that cannot store data normally. An increase in the number of bad blocks is an important precursor to SSD failure.

[0030] ECC (Error Correcting Code): Error correction codes are used to detect and correct errors that occur during data transmission or storage.

[0031] See Figures 1-2 The first aspect of this invention provides: a multi-dimensional solid-state drive (SSD) testing anomaly monitoring method, comprising the following steps: Rule base construction phase: Pre-build an extensible exception judgment rule base, and store exception judgment rules according to different test scenarios; Data acquisition and input phase: During the solid-state drive testing process, multi-dimensional monitoring data is collected in real time through the testing framework, and the multi-dimensional monitoring data is input into the anomaly judgment module. Scenario matching and rule selection phase: Automatically match the corresponding anomaly judgment rules based on the current test scenario; Multi-dimensional collaborative judgment stage: Parallel processing is adopted to judge the anomalies of the monitoring data of each dimension separately, and data correlation analysis is performed based on the logical conditions in the anomaly judgment rule base; Results generation and output phase: Integrate the judgment results from various dimensions, generate an anomaly report and output it to a specified file path for the test framework to read in order to achieve automated fault reporting.

[0032] In this embodiment, as Figure 1As shown, this invention employs an anomaly monitoring module compatible with the original test environment: Based on the user's input of parameters for each process (before, during, or after testing) into the product, it then performs judgments according to default or pre-defined rules. After the judgment is completed, the corresponding test results are output to a specified location. This can be appended to a newly created document or a document named according to the disk information, and the judgment results are read through the original test framework. Anomaly Monitoring Program (Deployed on various native testing frameworks): Input Module: This system includes default judgment templates; inputting them into the test project will enable default anomaly judgment. SMART Judgment Module: Based on changes in SMART data, this module checks for anomalies according to different scenarios (basic general, power failure, fault, performance) and prints and reports anomaly errors. Disk Log Judgment Module: Based on the input disk logs, this module checks for anomalies according to the default anomaly judgment rules for different scenarios (basic general, power failure, fault, performance) and prints and reports anomaly errors. Host Log Judgment Module: Based on the input host logs, this module checks for anomalies according to the default anomaly judgment rules for different scenarios (basic general, power failure, fault, performance) and prints and reports anomaly errors. Performance Judgment Module: Based on the input performance data, this module checks for anomalies according to the default performance anomaly judgment rules for different scenarios (basic general, power failure, fault, performance) and prints and reports anomaly errors.

[0033] In some embodiments, the test scenarios include basic function general testing, fault injection testing, performance testing, and power failure testing.

[0034] In some embodiments, the rule base construction phase further includes the following steps: Establish a default judgment template that covers a combination of various test parameters and test scenarios; set up a rule extension interface for users to add test scenarios and judgment parameters; and set modifiable threshold conditions and logical operators for each rule.

[0035] In some embodiments, the multi-dimensional monitoring data includes SMART parameters, disk logs, host logs, and performance data.

[0036] In some embodiments, during the data acquisition and input phase, for short-term test cases, data is collected once before and once after the test; for long-term test cases, data is collected once at the start of the test, and then collected at regular intervals every day thereafter; SMART parameters are read using ATA commands, and host logs and disk logs are collected using system log tools.

[0037] In some embodiments, when performing anomaly detection on SMART parameters, the following steps are included: The system compares the difference between two sets of SMART data; classifies and judges SMART parameters; and dynamically calculates write amplification and lifetime wear.

[0038] In some embodiments, a feedback optimization phase is also included: calculating the anomaly interception rate based on historical judgment results; dynamically adjusting the threshold parameters in the anomaly judgment rule base based on the anomaly interception rate; and adding other anomaly patterns to the rule base to expand the coverage.

[0039] In this embodiment, as Figure 2 As shown, the system inputs product information based on the default template, matching the default judgment logic. The default configuration can be modified and adapted according to actual usage. Default Template: Based on test judgment parameters: SMART, disk logs, host logs, and performance and test scenarios: basic function general tests, fault injection tests, performance tests, power failure tests, etc., the test content is arranged and combined, with a total of 16 default judgment contents. To ensure compatibility, additional content is reserved for addition. Test judgment parameters and test scenarios can be added according to the usage of various vendor platforms, and can also be combined with existing test judgment parameters and test scenarios.

[0040] 1. Smart Detection: Currently, a total of 117 smart items are compatible, including SATA and NVME. Two smart values ​​need to be entered for detection. If only one smart value is entered, the default smart value needs to be added. Existing detection logic can be matched to the actual disk's smart content; unmatched values ​​are not detected. Other content can also be added. This invention only demonstrates a portion of the smart items.

[0041] General SMART criteria: SMART count remains unchanged or increases: power-on time, amount of data written, amount of data read, etc.; SMART count remains unchanged or decreases: remaining lifetime, etc.; SMART count remains unchanged: read failure, write failure, erase failure, abnormal power-down count, normal power-down count, link error, newly added super bad block, etc.; SMART count does not consider: temperature, capacitor value, etc.; SMART calculation: WA calculation (host write increment / NAND write increment) exceeds the threshold and an error is reported if the lifetime calculation (platter PE wear count / platter nominal PE = 1 - remaining lifetime * 1%) is not equal.

[0042] Fault-based Smart Detection: Smart count remains unchanged or increases: Read fault, write fault, erase fault, etc., increase by 1, and each value can have an exception range set. For example, setting the exception range to 3-5 means that a read fault count increase of 3-5 will not report an error, otherwise an error will be reported; Smart count remains unchanged or decreases: Use the same logic. Existing judgment logic can be copied, for example: use the general Smart count unchanged or decrease judgment; Smart count remains unchanged: use the general Smart count unchanged except for read fault, write fault, and erase fault. Existing judgment logic can be copied and partially modified; Smart count is not judged: use the general Smart count without judgment; Smart calculation: use the general Smart calculation.

[0043] Performance-related smart condition checks: Uses the generic smart condition check approach. Existing condition templates can be copied. Power Loss SMART Detection: SMART counts can remain unchanged or increase: This includes abnormal power loss counts, normal power loss counts, and link error counts increasing by 1. Each value can have an abnormal range set and can be ANDed or ORed. For example, setting the link error count abnormal range to 0-5 and the abnormal power loss count to 9-10 means that an increase in the abnormal power loss count (9-10) and an increase in the link error count (0-5) will not report an error; all other values ​​will report an error. SMART counts can remain unchanged or decrease: This uses the general SMART count method. SMART counts can remain unchanged: This uses the general SMART count method, except for abnormal power loss counts, normal power loss counts, and link error counts. SMART counts can be ignored: This uses the general SMART count method without checking. SMART Calculation: This uses the general SMART calculation method; the WA count increase can exceed the threshold of 10. An abnormal range can be set; the default threshold is 6, and it can be set to 10.

[0044] 2. Disk Log Judgment: First, you need to set up the disk log collection method and corresponding log printing processes. Currently, over 300 processes are matched for printing, including over 50 alarm processes. Examples include: power failure processes, correctable error processes, front-end link anomalies, bad block replacement, etc.; and over 70 abnormal processes, such as: uncorrectable errors, disk hangs, abnormal disk status, etc. More abnormal processes can be added for printing, and the error type can be set to alarm or abnormal.

[0045] General disk log judgment: Judge all alarm processes and abnormal processes for errors, and add reporting anomalies if they occur.

[0046] Fault-related disk log judgment: The judgment method is the same as that for general disk logs. It judges all alarm processes and abnormal processes for errors, but constructed fault processes are not reported. For example, if a read fault is constructed and the read fault printing needs to be suppressed, the corresponding log printing of the read fault will not be reported.

[0047] Performance-related disk log judgment: The judgment method is the same as that for general disk logs.

[0048] Disk log judgment for power failure: The judgment of general disk logs is adopted, but power failure related processes are not reported, such as the power failure process and link error process are blocked.

[0049] 3. Host Log Judgment: First, you need to configure the host log collection method and corresponding log printing process for the test platform. Currently, it supports 20+ abnormal processes, such as IO errors, resets, disk kicks, and abnormal speed reductions. More abnormal processes can be added for logging.

[0050] General host log judgment: Determine if any abnormal process has reported an error.

[0051] Fault-related host log judgment: The general host log judgment is used, but the constructed fault process is not reported. For example, when constructing a read fault, the printing of IO errors and other errors reported by the host log needs to be suppressed.

[0052] Performance-related host log judgment: The judgment method for general host logs is used.

[0053] Power failure host log judgment: The judgment of general host logs is used, but the power failure process is not reported. For example, it is necessary to block the printing of host logs such as disk kick.

[0054] 4. Performance Assessment: Collect disk performance and latency data during testing using open-source tools on the testing platform. Input the performance and latency data and set error and exception thresholds. If no data is input or any exceptions are found, no assessment is performed. More performance assessments can be added.

[0055] General performance assessment: Latency less than a threshold. The threshold setting can be modified; for example, setting the threshold to 30 seconds will prevent errors from occurring if the latency is less than 30 seconds.

[0056] Fault-related performance assessment: The general performance assessment method is used.

[0057] Performance-related criteria: If the latency is less than the threshold, the performance can reach the set threshold. This threshold can be selected based on the model. Performance cannot drop to 0.

[0058] Power-down performance evaluation: The same general performance evaluation method is used.

[0059] Because this invention employs a rule base design for SSD anomaly detection in various scenarios, it can achieve precise monitoring of specific parameters for anomalies in different SSD scenarios, thus enabling the earlier detection of potential fault signs.

[0060] Because it enables multi-dimensional data fusion analysis, it can establish correlations between multi-dimensional parameters such as SMART, host logs, disk logs, and performance, thereby improving the coverage and accuracy of fault diagnosis.

[0061] Because it implements an independent judgment system, this anomaly judgment system is relatively independent, ensuring that it will not affect the existing testing platform and framework, thus improving ease of use.

[0062] Three examples are given below: Example 1: Typical deployment scenario.

[0063] Test scale: 15 PC Linux systems, 60 SATA SSDs, 2000+ test cases, including 30+ long-duration test cases that lasted more than 1 day.

[0064] Monitoring frequency: Except for long-term use cases, information is collected once before the start of each test case and once after the completion of the test, and then entered into the anomaly detection system; for long-term use cases, information is collected once at the start of the test, and then once a day thereafter, and then entered into the anomaly detection system.

[0065] Data retention: Determines where data will be output and named according to time; it can be stored indefinitely depending on the system's storage space.

[0066] System environment: Linux operating system, gigabit network environment.

[0067] Example 2: Fault detection case.

[0068] Scenario description: An unexpected increase in faults occurred during a read fault injection test on a certain SSD.

[0069] Monitoring system response process: 1. 10:00: Test the disk's smart item Uncorrectable Sector Count, which matches a UNC parameter value of 0 (normal), and the smart item Program Fail Count Chip, which matches a write failure parameter of 0 (normal). The host log and disk log are input into the anomaly monitoring system.

[0070] 2. 10:00~11:00: During the test, read faults are injected and the designed tests are performed, and performance data is collected through the framework.

[0071] 3. 11:00: Collect disk SMART data, host logs, disk logs, and performance data from the testing process again and input them into the anomaly monitoring system.

[0072] 4. 11:05: The anomaly monitoring system output its judgment results, finding that the disk UNC parameter was added normally, the host log reported IO errors normally, the disk log recorded that UNC was identified and handled correctly, and the performance dropped to 0 normally. However, the SMART record showed the addition of a write failure parameter, and the disk log printed write failures.

[0073] 5. 11:10: The original test framework obtains the judgment result from the anomaly monitoring system and reports the anomaly alarm via script, resulting in a test failure.

[0074] 6. Engineer's response: The alarm was received at 11:15. The anomaly was found by checking the collected data.

[0075] 7. Problem Analysis: By combining various log printouts from 10:00 to 11:00, the root cause of the problem can be quickly located.

[0076] Example 3: Long-term lifespan monitoring function.

[0077] Long-term WA monitoring process: Host Write Sector Count matches host write volume; TOTAL_WRITE_TO_FLASH matches the NAND write volume; Long-term anomaly monitoring: Smart: Uncorrectable sector count, PROGRAM_FAILS, ERASE_FAILS, WA, etc.

[0078] Host: Kick disk, reset, etc.

[0079] Disk log: anomaly reporting, etc.

[0080] Performance: latency monitoring, etc.

[0081] Get the smart data every day and input it into the anomaly detection module to calculate WA = (NAND write volume (later) - NAND write volume (previous)) / (host write volume (later) - host write volume (previous)).

[0082] Continuously monitor SMART changes daily and issue alerts when anomalies occur or WA exceeds the threshold; Monitor disk logs daily and issue alarms when abnormalities are printed. Monitor the host logs daily and issue an alert if any abnormalities are printed. Performance is monitored daily, and an alarm is issued when latency exceeds a threshold.

[0083] Below is an example of SMART information data parsing: SMART information can be obtained through the ATA command "SMART RETURN STATUS".

[0084] Standard SMART data format (12 bytes): Byte 0: Parameter ID; Bytes 1-2: Flags; Byte 3: Current value; Byte 4: Worst value; Bytes 5-9: Original value (critical monitoring data); Byte 10: Threshold; Byte 11: Reserved.

[0085] Key parameter monitoring logic: 1. Partial Smart: timestamp (TS); disk (DISK); SNSerial_Number (SN number); SV Sata_Version (SATA version); SS Sata_Speed ​​(SATA speed); 1. READ_ERROR_RATE data error rate; 5. REALLOCATED_SECTORS_COUNT: Number of remapped sectors; 9. POWER_ON_HOURS: Cumulative power-on time (hours); 12. POWER_CYCLE_COUNT: Power-on / off cycle count; 160 UNCORRECTABLE_SECTOR_COUNT: The actual number of UNCs read by the backend; 161 NUM_PURE_SPARE Number of reserved space blocks (total space - user space); 163 NUM_INITIAL_INVLID_BLOCK: Number of bad blocks counted after mass production; 164 TOTAL_ERASE_COUNT Total number of times the particles were erased; 165 MAX_ERASE_COUNT: The maximum number of erases for a single block; 166 MIN_ERASE_COUNT: Minimum number of erases for a single block; 167 AVG_ERASE_COUNT: Average number of erases per block; 170 GROWN_BAD_BLOCKS: Number of newly added bad blocks; 171 PROGRAM_FAILS Programming failure statistics; 172 ERASE_FAILS: Erase failure statistics; 175 CAPACITOR_LIFE Capacitor health status; 177 STATIC_WEARLEVELING_COUNT wearleaving increase (percentage); 184 End-to-End Errors; 187 UNCORRECTABLE_ERROR_COUNT: The number of UNC statistics with IO as the statistical granularity; 194 TEMPERATURE (Temperature in degrees Celsius); 195 HARDWARE_ECC_RECOVERED: Count of repairable and unrepairable ECCs; 196 REALLOCATION_EVENT_COUNT: The number of UNC statistics with IO as the statistical granularity; 197 CURRENT_PENDING_SECTOR_COUNT: Current unmapped sector count; 199 UDMA_CRC_ERROR CRC error count; 202 AVALIABLE_RESEVD_SPACE: Percentage of available reserved space; 232 PERCENTAGE_OF_LIFE_USED Remaining lifetime (percentage); 233 TOTAL_WRITE_TO_FLASH Total amount of data written to FLASH (32M); 234 TOTAL_READ_TO_FLASH Total amount of data read from FLASH (32M); 241 WRITE_SECTOR_COUNT Total amount of write data sent by the host (32M); 242 READ_SECTOR_COUNT Total amount of data uploaded and read by the host (32M); WA Write Amplification; EOF; 2. Partial host log printing check: cat dmesg_all.log | grep -E "BRCM Debug mfi stat 0x2d|I / O error|failed command|FAILED Result|hard resetting link|Power-on or device resetoccurred|softreset failed|Stopping disk|SCSI device is removed|link is slow to respond|limiting SATA link speed">>dmesg_monitor.log&.

[0086] 3. Partial disk log check: cat / var / log / disklog | grep -E "pb invalid| hdr error| SATA linkspeed">>disklog_monitor.log&.

[0087] 4. Partial performance checks: # Get current timestamp timestamp=$(date +%Y%m%d%H%M%S) # Run the host performance tool's performance results command to obtain data io_output=$($IO_COMMAND) # Extract data rows and convert them to CSV format, while adding timestamps. while IFS = read -r line; do if [ -n "$line" ]; then csv_line=$(echo "$timestamp,$line" | tr -s ' ' | tr ' '',') echo "$csv_line">>"$OUTPUT_FILE" fi done<<(echo "$io_output" | sed -n "${data_start},\$p").

[0088] A second aspect of the present invention provides: a multi-dimensional solid-state drive (SSD) test anomaly monitoring system, used to implement any of the above-mentioned multi-dimensional SSD test anomaly monitoring methods, comprising: The rule base building module is used to pre-build an extensible exception judgment rule base. The exception judgment rule base stores exception judgment rules according to different test scenarios. The data acquisition and input module is used to collect multi-dimensional monitoring data in real time through the test framework during solid-state drive testing, and input the multi-dimensional monitoring data into the anomaly judgment module. The scenario matching and rule selection module is used to automatically match the corresponding anomaly judgment rules based on the current test scenario; The multi-dimensional collaborative judgment module is used to perform anomaly judgment on monitoring data of each dimension in parallel processing, and to perform data correlation analysis based on the logical conditions in the anomaly judgment rule base. The results generation and output module is used to integrate the judgment results from various dimensions, generate anomaly reports and output them to a specified file path for the test framework to read in order to achieve automated fault reporting.

[0089] A third aspect of the present invention provides: a computer-readable storage medium storing computer-executable instructions, wherein when the computer-executable instructions are loaded and executed by a processor, the above-described multi-dimensional solid-state drive test anomaly monitoring method is implemented.

[0090] The above description is merely a preferred embodiment of the present invention. It should be understood that the present invention is not limited to the forms disclosed herein and should not be construed as excluding other embodiments. It can be used in various other combinations, modifications, and environments, and can be altered within the scope of the concept described herein through the above teachings or related technologies or knowledge. Modifications and variations made by those skilled in the art that do not depart from the spirit and scope of the present invention should be within the protection scope of the appended claims.

Claims

1. A multi-dimensional solid-state drive (SSD) test anomaly monitoring method, characterized in that: Includes the following steps: Rule base construction phase: Pre-build an extensible exception judgment rule base, and store exception judgment rules according to different test scenarios; Data acquisition and input phase: During the solid-state drive testing process, multi-dimensional monitoring data is collected in real time through the testing framework, and the multi-dimensional monitoring data is input into the anomaly judgment module. Scenario matching and rule selection phase: Automatically match the corresponding anomaly judgment rules based on the current test scenario; Multi-dimensional collaborative judgment stage: Parallel processing is adopted to judge the anomalies of the monitoring data of each dimension separately, and data correlation analysis is performed based on the logical conditions in the anomaly judgment rule base; Results generation and output phase: Integrate the judgment results from various dimensions, generate an anomaly report and output it to a specified file path for the test framework to read in order to achieve automated fault reporting.

2. The multi-dimensional solid-state drive test anomaly monitoring method according to claim 1, characterized in that: The test scenarios include basic function tests, fault injection tests, performance tests, and power-down tests.

3. The multi-dimensional solid-state drive test anomaly monitoring method according to claim 1, characterized in that: The rule base construction phase also includes the following steps: Establish a default judgment template that covers a combination of various test parameters and test scenarios; set up a rule extension interface for users to add test scenarios and judgment parameters; and set modifiable threshold conditions and logical operators for each rule.

4. The multi-dimensional solid-state drive test anomaly monitoring method according to claim 1, characterized in that: The multi-dimensional monitoring data includes SMART parameters, disk logs, host logs, and performance data.

5. The multi-dimensional solid-state drive test anomaly monitoring method according to claim 1, characterized in that: In the data acquisition and input phase, for short-term test cases, data is collected once before and once after the test; for long-term test cases, data is collected once at the start of the test, and then collected at regular intervals every day thereafter; SMART parameters are read using ATA commands, and host logs and disk logs are collected using system log tools.

6. The multi-dimensional solid-state drive test anomaly monitoring method according to claim 4, characterized in that: When performing anomaly detection on SMART parameters, the following steps are included: The system compares the difference between two sets of SMART data; classifies and judges SMART parameters; and dynamically calculates write amplification and lifetime wear.

7. The multi-dimensional solid-state drive test anomaly monitoring method according to any one of claims 1-6, characterized in that: It also includes a feedback optimization phase: calculating the anomaly interception rate based on historical judgment results; dynamically adjusting the threshold parameters in the anomaly judgment rule base based on the anomaly interception rate; and adding other anomaly patterns to the rule base to expand the coverage.

8. A multi-dimensional solid-state drive (SSD) test anomaly monitoring system, characterized in that: The method for monitoring anomalies in multi-dimensional solid-state drive testing as described in any one of claims 1-7 includes: The rule base building module is used to pre-build an extensible exception judgment rule base. The exception judgment rule base stores exception judgment rules according to different test scenarios. The data acquisition and input module is used to collect multi-dimensional monitoring data in real time through the test framework during solid-state drive testing, and input the multi-dimensional monitoring data into the anomaly judgment module. The scenario matching and rule selection module is used to automatically match the corresponding anomaly judgment rules based on the current test scenario; The multi-dimensional collaborative judgment module is used to perform anomaly judgment on monitoring data of each dimension in parallel processing, and to perform data correlation analysis based on the logical conditions in the anomaly judgment rule base. The results generation and output module is used to integrate the judgment results from various dimensions, generate anomaly reports and output them to a specified file path for the test framework to read in order to achieve automated fault reporting.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, which, when loaded and executed by a processor, implement the multi-dimensional solid-state drive test anomaly monitoring method as described in any one of claims 1-7.

Images