Processing method and electronic device

Abstract

The application discloses a processing method and an electronic device. The method comprises the following steps: in response to a first fault event occurring on the electronic device, collecting data of the electronic device to obtain target data of multiple data types; performing feature extraction on the target data of each data type respectively to obtain fault features corresponding to the first fault event; the fault features comprise fault identification and fault processing information of the first fault event; and adding the fault features as search data into a fault feature library; wherein, the search data in the fault feature library can be used to match a second fault event occurring on the electronic device to obtain fault processing information matched with the second fault event.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more particularly to a processing method and an electronic device. Background Technology

[0002] Currently, when electronic equipment malfunctions, the troubleshooting process and handling records are often scattered or even missing. When the same or similar malfunctions recur, operators still need to repeatedly perform independent fault location and analysis, resulting in low efficiency. Summary of the Invention

[0003] In view of the above, this application provides a processing method and an electronic device, as follows:

[0004] A processing method includes:

[0005] In response to a first fault event occurring on the electronic device, data is acquired from the electronic device to obtain target data of multiple data types;

[0006] Feature extraction is performed on the target data of each data type to obtain the fault features corresponding to the first fault event; the fault features include the fault identifier and fault handling information of the first fault event;

[0007] The fault characteristics are added to the fault characteristic database as retrieval data.

[0008] The retrieval data in the fault feature database can be used to match a second fault event occurring on the electronic device to obtain fault handling information that matches the second fault event.

[0009] An electronic device, comprising:

[0010] A memory used to store computer programs and the data generated by the execution of said computer programs;

[0011] A processor is configured to execute the computer program to: in response to a first fault event occurring on the electronic device, acquire data from the electronic device to obtain target data of multiple data types; extract features from the target data of each data type to obtain fault features corresponding to the first fault event; the fault features include a fault identifier and fault handling information of the first fault event; and add the fault features as retrieval data to a fault feature database.

[0012] The retrieval data in the fault feature database can be used to match a second fault event occurring on the electronic device to obtain fault handling information that matches the second fault event. Attached Figure Description

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

[0014] Figure 1 A flowchart illustrating a processing method provided in Embodiment 1 of this application;

[0015] Figure 2 A flowchart of a processing method provided in Embodiment 2 of this application;

[0016] Figure 3 A flowchart of a processing method provided in Embodiment 3 of this application;

[0017] Figure 4 A flowchart of a processing method provided in Embodiment 4 of this application;

[0018] Figure 5 A flowchart of a processing method provided in Embodiment 5 of this application;

[0019] Figure 6 This is a schematic diagram of the structure of a processing device provided in Embodiment Six of this application;

[0020] Figure 7 This is another structural schematic diagram of a processing device provided in Embodiment Six of this application;

[0021] Figure 8 This is a schematic diagram of the structure of an electronic device provided in Embodiment 7 of this application;

[0022] Figure 9 This is a flowchart illustrating the process of constructing a fault feature library using a pre-deployed system architecture in a server testing scenario applicable to this application;

[0023] Figure 10 This is a flowchart illustrating the construction of multimodal fault fingerprints applicable to server testing scenarios in this application. Detailed Implementation

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

[0025] refer to Figure 1This is a flowchart illustrating the implementation of a processing method provided in Embodiment 1 of this application. This method is applicable to electronic devices capable of data processing, such as servers, industrial control hosts, computer terminals, and other hardware devices with automated testing and operation capabilities. The technical solution in this embodiment is primarily used to improve the accuracy of fault handling in electronic devices.

[0026] Specifically, the method in this embodiment may include the following steps:

[0027] Step 101: In response to a first fault event occurring on the electronic device, data is acquired from the electronic device to obtain target data of multiple data types.

[0028] The data types can include at least several of the following: text type, key-value pair type, image type, enumeration type, and time-series numeric type.

[0029] It should be noted that the first failure event can be an abnormal event triggered by the electronic device during R&D testing, production testing, or actual operation. For example, during R&D testing, the electronic device triggers the first failure event when the automated test case fails to execute.

[0030] Specifically, in this embodiment, the operating status of the electronic device can be monitored in real time. When the first fault event is detected, data acquisition operations of multiple data types are automatically initiated, thereby obtaining target data of multiple data types. These target data can contain full-dimensional information of the electronic device when the first fault event occurs.

[0031] For example, the target data of multiple data types may include, but is not limited to: text log data of electronic devices, system configuration information of electronic devices, screenshots of electronic devices, indicator status data of at least one indicator light deployed in electronic devices, and sensing data collected by at least one sensor deployed in electronic devices at multiple times.

[0032] The data includes: text logs (such as system operation logs and baseboard management controller (BMC) logs); system configuration information (such as hardware and software configuration data, including hardware model and firmware version); screenshots (captured at the moment of the first failure event, such as startup screens or blue screen errors); indicator light status data (showing the on / off status of various indicator lights deployed in the electronic device, such as hard drive and network card indicators); and sensor data (including processor temperature, operating voltage, and fan speed data collected by at least one sensor such as a temperature sensor deployed in the electronic device).

[0033] Step 102: Extract features from the target data of each data type to obtain the fault features corresponding to the first fault event.

[0034] The fault characteristics include the fault identifier and fault handling information of the first fault event.

[0035] It should be noted that in this embodiment, different feature extraction methods can be used for target data of different data types, so that the fault features obtained can contain the data features of target data of each data type.

[0036] In one implementation, after extracting features from target data of different data types, this embodiment combines the data features corresponding to the target data of all data types to obtain the fault features corresponding to the first fault event.

[0037] Among them, the fault characteristics corresponding to the first fault event can uniquely represent the first fault event. Specifically, in the fault characteristics corresponding to the first fault event, the fault identifier of the first fault event is used as a fingerprint to uniquely represent the first fault event (i.e., obtained from the data characteristics corresponding to each data type). The fault handling information can include the cause of the fault, the fault investigation process, and the corresponding fault repair and handling plan, which is used to suggest how to deal with the first fault event. For example, the fault handling information can suggest to engineers: power off and restart, uninstall software, replace hard drive, etc.

[0038] It should be noted that fault handling information can be added to the fault features by engineers. Alternatively, in this embodiment, the historical operating data of the electronic device can be parsed to obtain the fault investigation process and corresponding fault repair and handling plan made by the engineer after the first fault event occurs on the electronic device. The cause of the first fault event can also be parsed from the historical operating data. Finally, this fault handling information can be automatically added to the fault features.

[0039] Furthermore, in this embodiment, the parsed fault handling information can be provided to engineers for confirmation to ensure the accuracy of the fault handling information.

[0040] Step 103: Add the fault features as retrieval data to the fault feature database.

[0041] The search data in the fault feature database can be used to match a second fault event occurring on the electronic device to obtain fault handling information matching the second fault event. The second fault event refers to an abnormal event subsequently triggered by the electronic device.

[0042] It should be noted that, after a long period of accumulation, the fault feature database can contain fault features corresponding to various fault events. As a result, the fault feature database can provide a large amount of retrieval data for subsequent data retrieval when a second fault event occurs in the electronic device. That is, it retrieves the fault features that match the corresponding fault features of the second fault event, and then provides the fault handling information corresponding to the retrieved fault features as the fault handling information matched with the second fault event to the engineer, so as to facilitate the engineer to handle the fault.

[0043] Specifically, the fault features corresponding to the first fault event may include not only fault identifiers and fault handling information, but also target data corresponding to the first fault event. In other words, in this embodiment, the target data collected on the electronic device when the first fault event occurs may be stored as raw data in the fault feature library for subsequent fault event backtracking.

[0044] In addition, the fault characteristics corresponding to the first fault event may also include a fault fingerprint identifier (identity, ID) and a fault timestamp. The fault fingerprint ID is used to uniquely represent the corresponding first fault event. In this embodiment, a unique fault fingerprint ID can be generated for the first fault event using a hash algorithm or other methods. The fault timestamp can be the time data recorded on the electronic device when the first fault event occurs.

[0045] For example, taking an electronic device as a server, when a first fault event occurs during server operation, where the boot card fails to enter the operating system at the Basic Input Output System Power On Self Test (BIOS POST) interface, the server collects target data of multiple data types, such as BMC system event logs, server hardware configuration information, screenshots of the video graphics array (VGA) display during the POST phase, and sensor data collected by various sensors on the motherboard. Then, feature extraction is performed on these target data to obtain corresponding fault features. These features include a fault identifier that uniquely represents the boot card's inability to enter the operating system at the BIOS POST interface, as well as fault handling information added by engineers for this fault event, such as the cause of the fault, the troubleshooting process, and the corresponding fault repair and handling plan. After adding this fault feature to the fault feature database, if the server experiences the same boot card failure again, the fault handling information corresponding to this event in the fault feature database can be provided to engineers as reference information for troubleshooting.

[0046] As can be seen from the above technical solutions, in the processing method provided in Embodiment 1 of this application, after the occurrence of the first fault event, by collecting target data of the electronic device in multiple data types and performing feature extraction, the fault features corresponding to the first fault event can be obtained, which include fault identification and fault handling information. After the fault features are added to the fault feature library as retrieval data, the retrieval data in the fault feature library can be used to match the second fault event that occurred on the electronic device and thereby match the fault handling information of the second fault event, so as to facilitate the handling of the fault that occurred on the electronic device. As can be seen, in this embodiment, a fault feature library is constructed using fault features obtained from target data of multiple data types each time an electronic device malfunctions. When a new fault event occurs, the retrieved data in the fault feature library can be used for fault event matching, reusing the fault handling information corresponding to the real fault event and providing it to engineers. Unlike artificial intelligence models that only infer fault prompts based on the device's operating status, this embodiment is not limited to shallow data on the device's operating status. It can comprehensively reconstruct the real fault scene when the fault event occurs from multiple data types, avoiding the information loss problem caused by a single type of data participating in reasoning at the data source level. Moreover, the retrieved data in the fault feature library is constructed based on real fault events, which is closer to the actual fault scenario and can effectively improve the accuracy of the obtained fault handling information.

[0047] refer to Figure 2 This is a flowchart illustrating the implementation of a processing method provided in Embodiment 2 of this application. This method is applicable to electronic devices capable of data processing, such as servers, industrial control hosts, computer terminals, and other hardware devices with automated testing and operation capabilities. The technical solution in this embodiment is primarily used to improve the accuracy of fault handling in electronic devices.

[0048] Specifically, the method in this embodiment may include the following steps:

[0049] Step 201: In response to a first fault event occurring on the electronic device, data is acquired from the electronic device to obtain target data of multiple data types.

[0050] It should be noted that the specific implementation method of step 201 can refer to the implementation method of step 101 in the previous text, and will not be described in detail here.

[0051] Step 202: Extract features from the target data of each data type to obtain the data features corresponding to the target data of each data type.

[0052] It should be noted that different data types can have their features extracted using different feature extraction methods, but the features corresponding to different data types are in the same format. For example, the features extracted from different data types, such as text log data and screenshots, are in JavaScript Object Notation (JSON) format.

[0053] Step 203: Determine the feature weights corresponding to the target data for each data type based on the current business type being processed by the electronic device.

[0054] The current business type processed by the electronic device represents the current processing scenario of the electronic device, such as a scenario of testing the system firmware version, a scenario of testing the sensor hardware, a scenario of testing the application software, a scenario of testing the processor load, etc.

[0055] It should be noted that the dominant factors causing failures may differ when electronic devices process different types of services. Based on this, in this embodiment, the feature weights corresponding to each data type can be determined according to the type of service currently being processed by the electronic device.

[0056] In practice, the feature weights for the same data type may be the same or different under different business types. Each business type corresponds to a weight combination (which contains the feature weights corresponding to all data types). The weight combination corresponding to a business type can be preset, or it can be continuously updated as the electronic device operates. For example, as the usage time of the electronic device increases, under a certain business type, the feature weight corresponding to the text type will gradually decrease, while the feature weight corresponding to the image type will gradually increase.

[0057] Based on this, this embodiment can identify the current business type being processed by the electronic device by detecting information such as process keywords, and determine the corresponding weight combination accordingly, thereby obtaining the feature weight corresponding to each data type under the current business type. The feature weight corresponding to each data type is a value between 0 and 1, and the sum of the feature weights corresponding to all data types is 1.

[0058] Step 204: According to the feature weights, combine the data features corresponding to the target data of each data type to obtain the fault features corresponding to the first fault event.

[0059] Specifically, in this embodiment, the data features corresponding to the target data of each data type can be weighted according to the feature weights and then concatenated to obtain the fault features corresponding to the first fault event.

[0060] For example, in this embodiment, the fault characteristics can be obtained using formula (1):

[0061] v_f=w1×e_text+w2×e_config+w3×e_sensor+w4×e_image (1)

[0062] Where v_f represents the fault feature, e_text represents the data feature corresponding to the text type target data, e_config represents the data feature corresponding to the key-value pair type target data, e_sensor represents the data feature corresponding to the time-series numerical type target data, e_image represents the data feature corresponding to the image type target data, and w1, w2, w3, and w4 represent the feature weights corresponding to the text type, key-value pair type, time-series numerical type, and image type, respectively.

[0063] It should be noted that the fault identifier in the fault characteristics can be a feature representation in a unified vector form after combining data features. Based on this, the fault characteristics corresponding to the first fault event integrate the feature representations of various data types under the current business type, so that the fault characteristics corresponding to the first fault event can fit the distribution pattern of the causes leading to the first fault event.

[0064] Step 205: Add the fault features as retrieval data to the fault feature library.

[0065] The search data in the fault feature database can be used to match a second fault event occurring on the electronic device to obtain fault handling information that matches the second fault event.

[0066] It should be noted that the specific implementation method of step 205 can refer to the implementation method of step 103 in the previous text, and will not be described in detail here.

[0067] For example, taking an electronic device as a server, when the server experiences its first failure event—getting stuck at the BIOS POST screen and unable to enter the operating system—during server operation, the server collects target data of multiple data types, such as BMC system event logs, server hardware configuration information, screenshots of the VGA display during the POST phase, and sensor data collected by various sensors on the motherboard. Then, feature extraction is performed on each of these target data types to obtain their respective data features, such as the data features corresponding to the BMC system event logs, server hardware configuration information, screenshots of the VGA display during the POST phase, and sensor data collected by various sensors on the motherboard. Then, according to the feature weights corresponding to text type, key-value pair type, image type, and time-series numerical type (determined based on the server's current boot process), such as 0.1, 0.3, 0.2, and 0.4, the data features corresponding to these data types are combined, such as by weighting and concatenating, to obtain the failure feature corresponding to the event of getting stuck at the BIOS POST screen and unable to enter the operating system. After adding this failure feature to the failure feature database, if the server experiences another failure at the BIOS POST screen... If a POST request fails to access the operating system, the corresponding fault handling information from the fault feature database can be provided to the engineer as a reference for troubleshooting.

[0068] As can be seen, in the processing method provided in Embodiment 2 of this application, feature weights are assigned to each data type according to the current service type of the electronic device. Based on these feature weights, the data features corresponding to the target data of different data types are combined. The resulting fault features can adapt to different processing scenarios, avoid the feature representation deviation caused by fixed weights, and make the obtained fault features more accurately match the actual fault causes. In turn, when a new fault event occurs, the corresponding fault handling information can be matched more accurately, thereby improving the reliability and accuracy of fault handling.

[0069] refer to Figure 3 This is a flowchart illustrating the implementation of a processing method provided in Embodiment 3 of this application. This method is applicable to electronic devices capable of data processing, such as servers, industrial control hosts, computer terminals, and other hardware devices with automated testing and operation capabilities. The technical solution in this embodiment is primarily used to improve the accuracy of fault handling in electronic devices.

[0070] Specifically, the method in this embodiment may include the following steps:

[0071] Step 301: In response to a first fault event occurring on the electronic device, data is acquired from the electronic device to obtain target data of multiple data types.

[0072] It should be noted that the specific implementation method of step 301 can refer to the implementation method of step 201 in the previous text, and will not be described in detail here.

[0073] Step 302: Determine the processing method corresponding to the target data according to the data type of the target data.

[0074] Different data types correspond to different processing methods, namely the feature extraction methods mentioned above.

[0075] It should be noted that the data type of the target data can be categorized according to its data carrier (i.e., data source), such as logs, screenshots, system configurations, indicator lights, sensors, etc. Alternatively, the data type of the target data can also be categorized according to its data structure, such as text structure, image structure, time-series structure, enumeration structure, etc.

[0076] Specifically, the target data of different data types includes at least several of the following: text log data of electronic devices; system configuration information of electronic devices; screenshots of electronic devices; indicator status data of at least one indicator light deployed in electronic devices; and sensor data collected at multiple times by at least one sensor deployed in electronic devices.

[0077] Among them, the target data of different data types have significant differences in several factors such as data structure, data carrier and noise distribution. Based on this, this embodiment sets different standardized processing methods for each data type to realize the classification and adaptation processing of heterogeneous data.

[0078] For example, text type corresponds to the processing method of semantic feature extraction, key-value pair type corresponds to the processing method of structural association feature extraction, image type corresponds to the processing method of visual space extraction, enumeration type corresponds to the processing method of state representation feature extraction, time series numerical type corresponds to the processing method of time series statistical feature extraction, and so on.

[0079] Step 303: According to the processing method corresponding to the target data, perform data format conversion on the target data to obtain the data characteristics corresponding to the target data of each data type.

[0080] Specifically, in this embodiment, the data features corresponding to the target data of each data type can be obtained through at least the following:

[0081] For text types, in this embodiment, semantic features can be extracted from the target data of the text type to obtain the data features corresponding to the target data of the text type.

[0082] For example, in this embodiment, regular expressions can be used to denoise text log data of text type, and a named entity recognition (NER) model can be used to remove non-key variables such as timestamps and process IDs, and extract core semantic features such as error codes, exception keywords, and driver module names, so as to convert text log data into structured text features and obtain data features corresponding to text type.

[0083] For key-value pair types, in this embodiment, structural association features can be extracted from the target data of the key-value pair type to obtain the data features corresponding to the target data of the key-value pair type.

[0084] For example, in this embodiment, system configuration information of key-value pair type can be parsed into structured key-value pairs consisting of key and value data pairs, where the key and value form structural association features, thereby obtaining the data features corresponding to the key-value pair type.

[0085] For image types, in this embodiment, visual spatial features can be extracted from the target of the image type to obtain the data features corresponding to the target data of the image type.

[0086] For example, in this embodiment, optical character recognition (OCR) technology can be used to perform character recognition and visual abstraction on blue screen codes, BIOS POST codes, etc. in the screenshot, convert the screenshot into an image feature representation, thereby obtaining the data features corresponding to the image type.

[0087] For enumeration types, in this embodiment, state representation features can be extracted from the target data of the enumeration type to obtain the data features corresponding to the target data of the enumeration type.

[0088] For example, in this embodiment, computer vision methods can be used to identify the indicator status data of fault indicator lights of a specific color on the device panel, so as to extract the status representation features and obtain the data features corresponding to the enumeration type.

[0089] For time-series numerical data, this embodiment can perform time-series statistical feature extraction on the target data of the time-series numerical data type to obtain the data features corresponding to the target data of the time-series numerical data type.

[0090] For example, in this embodiment, discrete time-series data in time-series numerical sensor data can be cleaned, normalized, and have time-series statistical features extracted to obtain the data features corresponding to the time-series numerical type.

[0091] As can be seen, this embodiment uses different processing methods for different data types to complete the transformation from multimodal raw target data to standardized data features.

[0092] Step 304: Determine the feature weights corresponding to the target data for each data type based on the current business type being processed by the electronic device.

[0093] It should be noted that the specific implementation method of step 304 can refer to the implementation method of step 203 in the previous text, and will not be described in detail here.

[0094] Step 305: According to the feature weights, combine the data features corresponding to the target data of each data type to obtain the fault features corresponding to the first fault event.

[0095] It should be noted that the specific implementation method of step 305 can refer to the implementation method of step 204 in the previous text, and will not be described in detail here.

[0096] Step 306: Add the fault features as retrieval data to the fault feature database.

[0097] The search data in the fault feature database can be used to match a second fault event occurring on the electronic device to obtain fault handling information that matches the second fault event.

[0098] It should be noted that the specific implementation method of step 306 can refer to the implementation method of step 205 in the previous text, and will not be described in detail here.

[0099] For example, taking an electronic device as a server, during server operation, a boot-up issue occurs that gets stuck in the BIOS. When the first failure event occurs—the inability to boot into the operating system via the POST interface—the server collects target data of multiple data types, such as BMC system event logs, server hardware configuration information, screenshots of the VGA display during the POST phase, and sensor data collected by various motherboard sensors. These target data are then processed according to their respective data format conversion methods to obtain the data features corresponding to each data type. For example, semantic feature extraction is performed on the text-type BMC system event logs; structural association feature extraction is performed on the key-value pair-type server hardware configuration information; visual spatial feature extraction is performed on the image-type VGA display screenshots during the POST phase; semantic feature extraction is also performed on the image-type VGA display screenshots during the POST phase; and time-series statistical feature extraction is performed on the time-series numerical data collected by various motherboard sensors. Different data types require different processing methods, thus obtaining the data features corresponding to various data types. Then, according to the feature weights corresponding to text, key-value pair, image, and time-series numerical types, the data features corresponding to these data types are combined (e.g., weighted and concatenated) to obtain the boot-stuck BIOS state. The fault characteristics corresponding to the event that cannot enter the operating system through the POST interface are added to the fault characteristic database. If the server is stuck at the BIOS POST interface and cannot enter the operating system again, the fault handling information corresponding to the event in the fault characteristic database can be provided to the engineers as reference information for troubleshooting by matching the fault characteristics.

[0100] As can be seen, in the processing method provided in Embodiment 3 of this application, by matching exclusive processing methods according to data type differences and completing unified data format conversion, it can adapt to the characteristics of multi-source heterogeneous fault data. This can avoid the distortion of feature extraction or loss of effective information caused by using the same processing method, making the extracted data features more accurate and providing accurate data support for subsequent configuration of feature weights according to business type and generation of fault features.

[0101] refer to Figure 4 This is a flowchart illustrating the implementation of a processing method provided in Embodiment 4 of this application. This method is applicable to electronic devices capable of data processing, such as servers, industrial control hosts, computer terminals, and other hardware devices with automated testing and operation capabilities. The technical solution in this embodiment is primarily used to improve the accuracy of fault handling in electronic devices.

[0102] Specifically, the method in this embodiment may include the following steps:

[0103] Step 401: In response to a first fault event occurring on the electronic device, data is acquired from the electronic device to obtain target data of multiple data types.

[0104] It should be noted that the specific implementation method of step 401 can refer to the implementation method of step 101 in the previous text, and will not be described in detail here.

[0105] Step 402: Extract features from the target data of each data type to obtain the fault features corresponding to the first fault event.

[0106] The fault characteristics include the fault identifier and fault handling information of the first fault event.

[0107] It should be noted that the specific implementation method of step 402 can refer to the implementation method of step 102 in the previous text, and will not be described in detail here.

[0108] Step 403: Add the fault features as retrieval data to the fault feature database.

[0109] The search data in the fault feature database can be used to match a second fault event occurring on the electronic device to obtain fault handling information matching the second fault event. The second fault event refers to an abnormal event subsequently triggered by the electronic device.

[0110] It should be noted that the specific implementation method of step 403 can refer to the implementation method of step 103 in the previous text, and will not be described in detail here.

[0111] Step 404: Obtain real-time data of multiple data types corresponding to the second fault event.

[0112] In this embodiment, the method for obtaining real-time data can refer to the method for obtaining target data corresponding to the first fault event. Specifically, in response to a second fault event occurring on the electronic device, this embodiment can initiate data acquisition operations for multiple data types, thereby obtaining real-time data of multiple data types. This real-time data can contain full-dimensional information about the electronic device at the time the second fault event occurs.

[0113] For example, real-time data of multiple data types may include, but are not limited to: text log data of electronic devices, system configuration information of electronic devices, screenshots of electronic devices, indicator status data of at least one indicator deployed in an electronic device, and sensing data collected by at least one sensor deployed in an electronic device at multiple times.

[0114] It should be noted that, in this embodiment, when collecting real-time data corresponding to the second fault event, data collection can be performed according to the data type of the target data corresponding to historical fault events in the fault feature database. That is, the data type involved in the real-time data is consistent with the data type involved in the target data. For example, if the target data has text and image types, this embodiment collects real-time data corresponding to each of the text and image types for the second fault event. Similarly, if the target data has text, image, and key-value pair types, this embodiment collects real-time data corresponding to each of the text, image, and key-value pair types for the second fault event.

[0115] Step 405: Extract features from the real-time data of each data type to obtain the fault features corresponding to the second fault event.

[0116] The fault characteristics corresponding to the second fault event may include the fault identifier of the second fault.

[0117] Specifically, in this embodiment, features can be extracted for real-time data of different data types, and then the data features corresponding to real-time data of all data types can be combined to obtain the fault features corresponding to the second fault event.

[0118] For example, in this embodiment, features can be extracted from the real-time data of each data type to obtain the data features corresponding to the real-time data of each data type. After determining the feature weights corresponding to the real-time data of each data type according to the service type processed when the electronic device experiences the second fault event, the data features corresponding to the real-time data of each data type are combined according to the feature weights to obtain the fault features corresponding to the second fault event.

[0119] Among these, the fault features corresponding to the second fault event can uniquely characterize the second fault event. Specifically, in the fault features corresponding to the second fault event, the fault identifier of the second fault event is used as a fingerprint to uniquely characterize the second fault event. The fault features corresponding to the second fault event do not yet contain fault handling information.

[0120] Step 406: In the fault feature library, retrieve the target fault event that meets the preset conditions with the fault identifier of the second fault event.

[0121] The fault feature library includes fault features corresponding to multiple historical fault events. Each fault feature includes a fault identifier and corresponding fault handling information. Based on this, in this embodiment, the fault identifier of the second fault event can be compared with the fault identifiers in the existing fault features in the fault feature library. According to the comparison result, the historical fault event to which the fault feature whose comparison result meets the preset conditions belongs is taken as the target fault event.

[0122] In one implementation, a preset condition can be that the comparison result represents the Kth highest similarity between the target fault event and the second fault event in the fault feature library, sorted from largest to smallest, where K is a positive integer greater than or equal to 1. For example, in the fault feature library, after comparing fault features and sorting the similarity between each historical fault event and the second fault event from largest to smallest, the historical fault event ranked first is the target fault event.

[0123] In another implementation, the preset condition can be: the comparison result indicates that the event similarity between the target fault event and the second fault event is greater than or equal to a similarity threshold. For example, if the comparison result between the fault identifier of historical fault event 1 retrieved in the fault feature library and the fault identifier in the fault features corresponding to the second fault event meets the preset condition, that is, it indicates that the event similarity between historical fault event 1 and the second fault event is greater than or equal to a similarity threshold such as 90%, then historical fault event 1 is determined as the target fault event.

[0124] Furthermore, the event similarity between the target fault event and the second fault event can be: the cosine similarity between the fault identifier of the target fault event and the fault identifier of the second fault event.

[0125] Specifically, in this embodiment, the cosine similarity between the fault identifier of the second fault event and the fault identifier of each historical fault event in the fault feature library can be directly calculated and used as the event similarity. The historical fault events in the fault feature library are sorted in descending order of event similarity, and the top K historical fault events are determined as the target fault events, or the historical fault events with a cosine similarity greater than or equal to the similarity threshold are determined as the target fault events.

[0126] Alternatively, the event similarity between the target fault event and the second fault event can be: a similarity obtained by combining the cosine similarity between the data features of the target fault event and the second fault event across various data types, according to the corresponding feature weights. Here, the data features across each data type are the features used to obtain the corresponding fault features.

[0127] Specifically, in this embodiment, data features for each data type can be extracted from the fault features of historical fault events in the fault feature library (obtained by feature extraction from real-time data of the corresponding data type). Then, for each data type, cosine similarity is calculated between the data features of that data type and the data features of the second fault event in the same data type, obtaining the similarity component corresponding to each data type. Then, according to the feature weights corresponding to each data type determined by the service type processed when the electronic device experiences the second fault event, the similarity components corresponding to each data type are weighted and summed to obtain the event similarity between the target fault event and the second fault event. Finally, the historical fault events in the fault feature library are sorted in descending order of event similarity, and the top K historical fault events are determined as the target fault events, or historical fault events with a cosine similarity greater than or equal to the similarity threshold are determined as the target fault events.

[0128] For example, in this embodiment, the cosine similarity between the data features of the historical fault event and the second fault event in the text type is calculated as the text similarity component; the cosine similarity between the data features of the historical fault event and the second fault event in the key-value pair type is calculated as the key-value pair similarity component; the cosine similarity between the data features of the historical fault event and the second fault event in the time-series numerical type is calculated as the time-series numerical similarity component; and the cosine similarity between the data features of the historical fault event and the second fault event in the image type is calculated as the image similarity component. Then, according to the feature weights corresponding to the text type, key-value pair type, time-series numerical type, and image type, the text similarity component, key-value pair similarity component, time-series numerical similarity component, and image similarity component are weighted and summed to obtain the event similarity between the historical fault event and the second fault event.

[0129] In another implementation, the preset condition can be: the comparison result indicates that the event correlation coefficient between the target fault event and the second fault event is greater than or equal to the correlation threshold.

[0130] The event correlation coefficient can be the correlation coefficient between the fault identifier of the target fault event and the fault identifier of the second fault event, such as the Pearson correlation coefficient or the Spearman rank coefficient. The event correlation coefficient characterizes the degree of correlation between two fault identifiers, and its value ranges from -1 to 1. The closer the event correlation coefficient is to 1, the stronger the correlation between the two fault identifiers. For example, during server operation, if fault event 1 leads to fault event 2, then the event correlation coefficient between fault event 1 and fault event 2 will be relatively high.

[0131] Specifically, in this embodiment, the correlation coefficient between the fault identifier of the second fault event and the fault identifier of each historical fault event in the fault feature library can be directly calculated using a correlation coefficient algorithm such as the Pearson correlation coefficient algorithm or the Spearman rank correlation coefficient algorithm. This correlation coefficient is then used as the event correlation coefficient. The historical fault events in the fault feature library are sorted in descending order of the event correlation coefficient. The top K historical fault events are identified as target fault events, or historical fault events with an event correlation coefficient greater than or equal to the correlation threshold are identified as target fault events.

[0132] Alternatively, in this embodiment, data features for each data type can be extracted from the fault features of historical fault events in the fault feature library (obtained by feature extraction from real-time data of the corresponding data type). Then, for each data type, the correlation coefficient is calculated between the data features of that data type and the data features of the second fault event in the same data type, obtaining the coefficient component corresponding to each data type. Then, according to the feature weights corresponding to each data type determined by the service type processed when the electronic device experiences the second fault event, the coefficient components corresponding to each data type are weighted and summed to obtain the event correlation coefficient between the target fault event and the second fault event. Finally, the historical fault events in the fault feature library are sorted in descending order of event correlation coefficient, and the top K historical fault events are determined as the target fault events, or historical fault events with event correlation coefficients greater than or equal to the correlation threshold are determined as the target fault events.

[0133] Step 407: Obtain fault handling information for the target fault event.

[0134] Furthermore, in this embodiment, fault handling information can be directly pushed to the engineer's operation and maintenance terminal, providing the engineer with standardized fault handling references.

[0135] For example, taking an electronic device as a server, when a first fault event occurs during server operation, where the system gets stuck at the BIOS POST screen and cannot enter the operating system, the server collects target data of multiple data types, such as BMC system event logs, server hardware configuration information, screenshots of the VGA display during the POST phase, and sensor data collected by various motherboard sensors. Then, feature extraction is performed on these target data to obtain corresponding fault features. These features include a fault identifier that uniquely identifies the system getting stuck at the BIOS POST screen and unable to enter the operating system, as well as fault handling information added by engineers corresponding to this fault event, such as the cause of the fault, the troubleshooting process, and the corresponding fault repair and handling plan. After adding this fault feature to the fault feature database, if the server experiences a second fault event where the system gets stuck at the BIOS POST screen and cannot enter the operating system again, the server collects real-time data of multiple data types, such as BMC system event logs, server hardware configuration information, screenshots of the VGA display during the POST phase, and sensor data collected by various motherboard sensors. Then, feature extraction is performed on these real-time data to obtain corresponding fault features, including a fault identifier that uniquely identifies the current system getting stuck at the BIOS POST screen. The system identifies faults where the POST interface fails to boot into the operating system. Then, it searches the fault feature database for fault events that match these real-time data and satisfy similarity criteria based on cosine similarity and / or association criteria based on correlation coefficients. For example, it not only identifies fault events in the fault feature database where the system is stuck at the BIOS POST interface and cannot boot into the operating system (high cosine similarity) as target fault events, but also identifies another fault event causing this (high correlation coefficient) as a target fault event. The fault handling information corresponding to these retrieved fault events is then used as fault handling information for newly occurring fault events where the system is stuck at the BIOS POST interface and cannot boot into the operating system. This information is then recommended to engineers so they can refer to this information for troubleshooting, such as troubleshooting the issue of the system being stuck at the BIOS POST interface and the faults causing this issue.

[0136] As can be seen, in the processing method provided in Embodiment 4 of this application, by collecting real-time data of the second fault event, extracting fault features, and performing feature retrieval in the fault feature library, all fault events with high similarity and high correlation with the second fault event can be screened from the fault feature library. Then, the fault handling information of the target fault event is recommended to the engineer as the fault handling information of the second fault event for reference. In this process, the identification of new faults and the accurate recommendation of fault handling information can be realized quickly and comprehensively, thereby improving the accuracy of fault handling.

[0137] refer to Figure 5 This is a flowchart illustrating the implementation of a processing method provided in Embodiment 5 of this application. This method is applicable to electronic devices capable of data processing, such as servers, industrial control hosts, computer terminals, and other hardware devices with automated testing and operation capabilities. The technical solution in this embodiment is primarily used to improve the accuracy of fault handling in electronic devices.

[0138] Specifically, the method in this embodiment may include the following steps:

[0139] Step 501: In response to a first fault event occurring on the electronic device, the target intelligent agent is used to collect data from the electronic device to obtain the target data of multiple data types;

[0140] In this embodiment, the target intelligent agent is associated with the data type. Specifically, in this embodiment, a target intelligent agent corresponding to each data type can be deployed in the electronic device to collect data of the corresponding data type. For example, the target intelligent agent can be an independent service process, command-line tool, or microservice unit that is independently deployed according to the data type and performs the task of collecting target data of the corresponding data type. The target intelligent agent corresponding to each data type is bound to the corresponding data type and can execute the task of collecting the corresponding target data in parallel.

[0141] It should be noted that the target agents corresponding to different data types can be independent agents, or the target agents corresponding to different data types can be sub-agents deployed in the same agent.

[0142] For example, taking the data type of the target data as categorized by its data source, this embodiment can deploy different target agents on the electronic device for different data sources. Target agents can include: a log collection agent for collecting text log data, a configuration collection agent for collecting system configuration information, a screenshot collection agent for collecting screenshots, a sensor collection agent for collecting sensor data, and a status collection agent for collecting indicator light status data, etc.

[0143] Step 502: Extract features from the target data of each data type to obtain the fault features corresponding to the first fault event.

[0144] The fault characteristics include the fault identifier and fault handling information of the first fault event.

[0145] It should be noted that the specific implementation method of step 502 can refer to the implementation method of step 102 in the previous text, and will not be described in detail here.

[0146] Step 503: Add the fault features as retrieval data to the fault feature database.

[0147] The search data in the fault feature database can be used to match a second fault event occurring on the electronic device to obtain fault handling information matching the second fault event. The second fault event refers to an abnormal event subsequently triggered by the electronic device.

[0148] It should be noted that the specific implementation method of step 503 can refer to the implementation method of step 103 in the previous text, and will not be described in detail here.

[0149] For example, taking an electronic device as a server, when the server experiences its first failure event—getting stuck at the BIOS POST screen and unable to enter the operating system—the server uses deployed target agents corresponding to various data types to collect target data of the corresponding data types. For instance, log collection agents, configuration collection agents, screenshot collection agents, and sensor collection agents collect target data of their respective data types, such as BMC system event logs, server hardware configuration information, screenshots of the VGA display during the POST phase, and sensor data collected by various sensors on the motherboard. Then, feature extraction is performed on these target data to obtain corresponding failure features. These features include a unique fault identifier that identifies the failure to enter the operating system from the BIOS POST screen, as well as fault handling information added by engineers for this failure event, such as the cause of the failure, the troubleshooting process, and the corresponding fault repair and handling plan. After adding this fault feature to the fault feature database, if the server experiences the same failure event again, the fault handling information corresponding to that event in the fault feature database can be provided to engineers as reference information for troubleshooting.

[0150] As can be seen, in the processing method provided in Embodiment 5 of this application, target intelligent agents that are associated one-to-one with data types are assigned to collect target data of corresponding data types, thereby realizing automated parallel data collection after the occurrence of the first fault event. Thus, by relying on the parallel work of multiple intelligent agents, the time spent on collecting target data can be shortened, and more accurate and comprehensive data support can be provided for subsequent fault feature extraction, fault feature storage and fault feature matching.

[0151] refer to Figure 6This is a schematic diagram of a processing device provided in Embodiment Six of this application. This processing device can be deployed in electronic devices capable of data processing, such as servers, industrial control hosts, computer terminals, and other hardware devices with automated testing and operation capabilities. The technical solution in this embodiment is mainly used to improve the accuracy of fault handling in electronic devices.

[0152] Specifically, the apparatus in this embodiment may include the following units:

[0153] The data acquisition unit 601 is used to acquire data from the electronic device in response to a first fault event occurring on the electronic device, so as to obtain target data of multiple data types;

[0154] The feature extraction unit 602 is used to extract features from the target data of each data type to obtain the fault features corresponding to the first fault event; the fault features include the fault identifier and fault handling information of the first fault event.

[0155] The feature adding unit 603 is used to add the fault features as retrieval data to the fault feature library;

[0156] The retrieval data in the fault feature database can be used to match a second fault event occurring on the electronic device to obtain fault handling information that matches the second fault event.

[0157] As can be seen from the above technical solutions, in the processing device provided in Embodiment Six of this application, after a first fault event occurs, by collecting target data of multiple data types from the electronic device and performing feature extraction, the fault features corresponding to the first fault event can be obtained, which include fault identifiers and fault handling information. After the fault features are added to the fault feature library as retrieval data, the retrieval data in the fault feature library can be used to match the second fault event that occurs on the electronic device and thereby match the fault handling information of the second fault event, so as to facilitate the handling of the fault that occurs on the electronic device. As can be seen, in this embodiment, a fault feature library is constructed using fault features obtained from target data of multiple data types each time an electronic device malfunctions. When a new fault event occurs, the retrieved data in the fault feature library can be used for fault event matching, reusing the fault handling information corresponding to the real fault event and providing it to engineers. Unlike artificial intelligence models that only infer fault prompts based on the device's operating status, this embodiment is not limited to shallow data on the device's operating status. It can comprehensively reconstruct the real fault scene when the fault event occurs from multiple data types, avoiding the information loss problem caused by a single type of data participating in reasoning at the data source level. Moreover, the retrieved data in the fault feature library is constructed based on real fault events, which is closer to the actual fault scenario and can effectively improve the accuracy of the obtained fault handling information.

[0158] In one implementation, the feature extraction unit 602 is specifically used to: extract features from the target data of each data type to obtain data features corresponding to the target data of each data type; determine the feature weights corresponding to the target data of each data type according to the current service type processed by the electronic device; and combine the data features corresponding to the target data of each data type according to the feature weights to obtain the fault features corresponding to the first fault event.

[0159] The same data type has different feature weights under different business types.

[0160] Specifically, when the feature extraction unit 602 extracts features from the target data of each data type to obtain the data features corresponding to the target data of each data type, it is specifically used to: determine the processing method corresponding to the target data according to the data type of the target data; different data types correspond to different processing methods; and perform data format conversion on the target data according to the processing method corresponding to the target data to obtain the data features corresponding to the target data of each data type.

[0161] The target data of the plurality of data types includes at least several of the following:

[0162] The electronic device's text log data; the electronic device's system configuration information; the electronic device's screenshots; the indicator status data of at least one indicator light deployed in the electronic device; and the sensor data collected by at least one sensor deployed in the electronic device at multiple times.

[0163] When the feature extraction unit 602 performs data format conversion on the target data according to the processing method corresponding to the target data to obtain the data features corresponding to the target data, it may include at least one of the following:

[0164] Semantic feature extraction is performed on target data of text type to obtain the data features corresponding to the target data of the text type.

[0165] Structural association features are extracted from key-value pair type target data to obtain the data features corresponding to the key-value pair type target data;

[0166] Visual spatial features are extracted from the target of the image type to obtain the data features corresponding to the target data of the image type;

[0167] State representation features are extracted from the target data of the enumeration type to obtain the data features corresponding to the target data of the enumeration type.

[0168] Time series statistical features are extracted from the target data of the time series numerical type to obtain the data features corresponding to the target data of the time series numerical type.

[0169] In one implementation, the data acquisition unit 601 is further configured to: obtain real-time data of multiple data types corresponding to the second fault event;

[0170] The feature extraction unit 602 is also used to: extract features from the real-time data of each data type to obtain the fault features corresponding to the second fault event;

[0171] Based on this, the device in this embodiment may further include the following units, such as... Figure 7 As shown:

[0172] The fault retrieval unit 604 is used to retrieve, from the fault feature database, a target fault event whose fault identifier matches a preset condition of the second fault event; and to obtain fault handling information of the target fault event.

[0173] The preset conditions include: the event similarity between the target fault event and the second fault event is greater than or equal to a similarity threshold; wherein the event similarity is: the cosine similarity between the fault identifier of the target fault event and the fault identifier of the second fault event; or, the event similarity is: the similarity obtained by combining the cosine similarity between the data features of the target fault event and the second fault event on various data types according to the corresponding feature weights; wherein the data features on each data type are features used to obtain the corresponding fault features.

[0174] In one implementation, the data acquisition unit 601 is specifically used to: in response to a first fault event occurring on the electronic device, use a target intelligent agent to acquire data from the electronic device to obtain target data of multiple data types; wherein the target intelligent agent is associated with the data types.

[0175] It should be noted that the specific implementation of each unit in this embodiment can be referred to the corresponding content above, and will not be described in detail here.

[0176] refer to Figure 8 This is a schematic diagram of the structure of an electronic device provided in Embodiment 7 of this application. The electronic device may include the following structure:

[0177] Memory 801 is used to store computer programs and data generated by the execution of said computer programs;

[0178] The processor 802 is configured to execute the computer program to: in response to a first fault event occurring on the electronic device, acquire data from the electronic device to obtain target data of multiple data types; extract features from the target data of each data type to obtain fault features corresponding to the first fault event; the fault features include a fault identifier and fault handling information of the first fault event; and add the fault features as retrieval data to a fault feature database.

[0179] The retrieval data in the fault feature database can be used to match a second fault event occurring on the electronic device to obtain fault handling information that matches the second fault event.

[0180] As can be seen from the above technical solutions, in the electronic device provided in Embodiment 7 of this application, after a first fault event occurs, by collecting target data of multiple data types from the electronic device and performing feature extraction, the fault features corresponding to the first fault event can be obtained, which include fault identification and fault handling information. After the fault features are added to the fault feature library as retrieval data, the retrieval data in the fault feature library can be used to match the second fault event that occurs on the electronic device and thereby match the fault handling information of the second fault event, so as to facilitate the handling of the fault that occurs on the electronic device. As can be seen, in this embodiment, a fault feature library is constructed using fault features obtained from target data of multiple data types each time an electronic device malfunctions. When a new fault event occurs, the retrieved data in the fault feature library can be used for fault event matching, reusing the fault handling information corresponding to the real fault event and providing it to engineers. Unlike artificial intelligence models that only infer fault prompts based on the device's operating status, this embodiment is not limited to shallow data on the device's operating status. It can comprehensively reconstruct the real fault scene when the fault event occurs from multiple data types, avoiding the information loss problem caused by a single type of data participating in reasoning at the data source level. Moreover, the retrieved data in the fault feature library is constructed based on real fault events, which is closer to the actual fault scenario and can effectively improve the accuracy of the obtained fault handling information.

[0181] Taking server R&D and production testing as an example, the technical solution of this application is illustrated below:

[0182] This application constructs a multimodal fingerprint (i.e., fault characteristics) based on server faults, through a three-step process of "data acquisition - feature extraction - fingerprint integration," specifically including:

[0183] 1. Multi-source data targeted acquisition: For server testing scenarios, it automatically captures four types of target data: "text log data (system / BMC log), system configuration information (hardware model / firmware version), screenshots (POST code / blue screen), and sensor data (temperature / voltage / fan speed)," covering all dimensions of information from "software-hardware-visual" when a fault occurs.

[0184] 2. Feature Structuring Processing: Customized processing is performed on each type of target data. Specifically: text log data is processed using regular expressions and NER models to remove noise and extract error codes / call stacks, resulting in data features corresponding to text-type target data; system configuration information is parsed into JSON-formatted structured key-value pairs, resulting in data features corresponding to key-value pair-type target data; screenshots can be identified using OCR and template matching to obtain visual features corresponding to image-type target data; sensor data can have statistical features (such as mean / peak value) calculated to obtain data features corresponding to the data type, including data features corresponding to time-series numerical target data.

[0185] 3. Unified Fault Fingerprint Generation: The processed multimodal data features are fused to obtain a standardized JSON format fault feature, also known as a fault fingerprint, which includes the following: fingerprint ID, fault timestamp, target data, fault identifier composed of data features of each modality, fault handling information, etc., to achieve unique identification and structured storage of fault status.

[0186] refer to Figure 9 The flowchart below illustrates the process of constructing a fault feature library using a pre-deployed system architecture. This system architecture may include a data acquisition and scheduling module, a multimodal data acquisition layer, a feature processing and fingerprint synthesis module, and a fingerprint generation and storage module. Based on this system architecture, the process of constructing the fault feature library in this application is as follows:

[0187] (1) Data acquisition and scheduling module:

[0188] This module is used to listen for trigger events on the test platform. It is triggered when a test case fails (the first failure event). In addition, this module sends collection control commands to four collection agents (i.e., the target intelligent agents mentioned above) in parallel.

[0189] (2) Multimodal data acquisition layer:

[0190] It consists of four independent data collection agents, each responsible for collecting raw data in four different modalities (data types), i.e., the target data mentioned earlier. Among them:

[0191] The log collection agent is used to collect plain text log data such as system logs (journalctl), BMC logs, unified extensible firmware interface (UEFI) logs, BMC system event logs (SEL) logs, intelligent platform management interface (IPMI) logs, serial port output logs, and operating system (OS) startup logs.

[0192] Configure the data collection agent to collect system configuration information such as hardware model, firmware version, central processing unit (CPU) / random access memory (RAM) / peripheral component interconnect express (PCIe) topology, redundant array of independent disks (RAID) configuration, legacy boot mode, and preboot execution environment (PXE) status by executing scripts (such as lspci and dmidecode).

[0193] The screenshot capture agent is used to capture screen images of the moment of failure by calling the Internet Protocol-based keyboard, video, mouse (IP-KVM) or BMC interface. For example, screenshots of the video graphics array (VGA) output during the BIOS POST process or the screen of the XClarity Controller (XCC) / keyboard video mouse (KVM) are used to capture graphical error messages.

[0194] Sensor Acquisition Agent: Collects timing data such as processor temperature, power consumption, voltage, fan speed, and power supply current through commands from the Intelligent Platform Management Interface (IPMI), with a sampling frequency of no less than 1Hz.

[0195] (3) Feature processing and fingerprint synthesis module:

[0196] This module receives raw data and performs processing such as cleaning and feature extraction to obtain data features of the corresponding data type. This module can be implemented using the following units:

[0197] The text feature extraction unit uses regular expressions and the NER model to filter noise such as timestamps and memory addresses from text log data, and extracts semantic features such as error codes and key warnings. For example, the text feature extraction unit can employ a two-stage semantic cleansing process to achieve the structuring and standardization of text log data, as follows:

[0198] Level 1: Construct a general log noise rule base (such as timestamps, hexadecimal addresses, process PIDs, etc.) to automatically identify and replace them with standardized placeholders (such as TIMESTAMP, HEXADDR, PID), eliminating the interference of variable fields on subsequent matching.

[0199] The second stage involves key entity extraction based on the NER model. Using a language model, the system first fine-tunes the data through log corpora, then extracts entities from the logs: "Faulty device: DIMM, PCie; Error type: Error, DIMM FAILED; Operation action: XCC Update; Status code: 0x07". The final output is cleaned and standardized data features.

[0200] The configuration feature extraction unit is used to parse the collected system configuration information into structured key-value pairs to obtain structural association features composed of keys and values.

[0201] The image feature extraction unit is used to identify error codes in screen images using OCR and to identify the status of device indicator lights using a computer vision library, thereby obtaining status representation features.

[0202] The numerical feature extraction unit is used to standardize sensor data and other data to obtain time-series statistical features.

[0203] (4) Fingerprint generation and storage module:

[0204] This module is used to perform weighted fusion processing on the processed multimodal data features to form a unified and structured fault feature (such as JSON format), which can also be called a multimodal fault fingerprint, and to persistently store it in the fault feature library.

[0205] refer to Figure 10 The flowchart for constructing multimodal fault fingerprints in this application is shown below, with detailed steps:

[0206] 1) Trigger: The test case fails to execute, generating a clear event signal.

[0207] 2) Parallel acquisition: After receiving the trigger signal of the first fault event, the data acquisition and scheduling module synchronously and in parallel calls four data acquisition agents to obtain: text log data, system configuration information, screenshots and sensor data, respectively, thus completing the acquisition of target data of four modes related to server faults.

[0208] 3) Feature Processing: Regular expressions and the NER model were used on the text log data to remove non-critical variables such as timestamps and process IDs, extracting core semantic features such as error codes, exception keywords, and driver module names. System configuration information was parsed into key-value pair structural association features. OCR technology was used to identify visual spatial features such as blue screen codes and BIOS POST codes in screenshots. Computer vision methods were used to identify fault indicator lights of specific colors on device panels to obtain status representation features. Sensor data was cleaned and normalized to obtain time-series statistical features. This completed the transformation from multimodal raw data to standardized data features.

[0209] 4) Fingerprint generation and storage: All the data features processed above are weighted and fused to obtain fault features, which are then stored in the fault feature database as fault fingerprints.

[0210] It should be noted that the software modules capable of performing the above data processing functions can be deployed on servers or management nodes in this application, without the need for additional specific hardware. The data acquisition and scheduling module can be a resident process or a microservice. Each acquisition agent can be an independent command-line tool or sub-service, receiving acquisition control commands and returning the acquired target data through inter-process communication or remote procedure calls. The feature processing and fingerprint synthesis module can be a service that can call relevant algorithm libraries to perform feature extraction and feature combination, outputting fault characteristics.

[0211] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to the method section.

[0212] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0213] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0214] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A processing method, comprising: In response to a first fault event occurring on the electronic device, data is acquired from the electronic device to obtain target data of multiple data types; Feature extraction is performed on the target data of each data type to obtain the fault features corresponding to the first fault event; the fault features include the fault identifier and fault handling information of the first fault event; The fault characteristics are added to the fault characteristic database as retrieval data. The retrieval data in the fault feature database can be used to match a second fault event occurring on the electronic device to obtain fault handling information that matches the second fault event.

2. The method according to claim 1, wherein feature extraction is performed on the target data of each data type to obtain the fault features corresponding to the first fault event, including: Feature extraction is performed on the target data of each data type to obtain the data features corresponding to the target data of each data type; Based on the current service type processed by the electronic device, determine the feature weights corresponding to the target data for each data type; According to the aforementioned feature weights, the data features corresponding to the target data of each data type are combined to obtain the fault features corresponding to the first fault event.

3. According to the method of claim 2, the feature weights of the same data type are different under different business types.

4. The method according to claim 2, wherein feature extraction is performed on the target data of each data type to obtain the data features corresponding to the target data of each data type, including: Determine the processing method corresponding to the target data according to the data type of the target data; Different data types correspond to different processing methods; According to the processing method corresponding to the target data, the target data is converted into a data format to obtain the data features corresponding to the target data of each data type.

5. The method according to claim 4, wherein the target data of the plurality of data types includes at least a number of the following: The text log data of the electronic device; The system configuration information of the electronic device; A screenshot of the electronic device; Indicator status data of at least one indicator light deployed in the electronic device; Sensing data collected at multiple times by at least one sensor deployed in the electronic device.

6. The method according to claim 4, wherein the target data is converted into a data format according to the processing method corresponding to the target data to obtain the data features corresponding to the target data, including at least one of the following: Semantic feature extraction is performed on target data of text type to obtain the data features corresponding to the target data of the text type. Structural association features are extracted from key-value pair type target data to obtain the data features corresponding to the key-value pair type target data; Visual spatial features are extracted from the target of the image type to obtain the data features corresponding to the target data of the image type; State representation features are extracted from the target data of the enumeration type to obtain the data features corresponding to the target data of the enumeration type. Time series statistical features are extracted from the target data of the time series numerical type to obtain the data features corresponding to the target data of the time series numerical type.

7. The method according to claim 1, further comprising: Obtain real-time data of multiple data types corresponding to the second fault event; Feature extraction is performed on the real-time data of each data type to obtain the fault features corresponding to the second fault event; In the fault feature database, a target fault event that meets the preset conditions with the fault identifier of the second fault event is retrieved; Obtain fault handling information for the target fault event.

8. The method according to claim 7, wherein the preset conditions include: The event similarity between the target fault event and the second fault event is greater than or equal to the similarity threshold; Wherein, the event similarity is: the cosine similarity between the fault identifier of the target fault event and the fault identifier of the second fault event; Alternatively, the event similarity can be: a similarity obtained by combining the cosine similarity between the target fault event and the second fault event in each data type according to the corresponding feature weights; The data features of each data type are features used to obtain the corresponding fault features.

9. The method according to claim 1, wherein in response to a first fault event occurring on the electronic device, data acquisition is performed on the electronic device to obtain target data of multiple data types, including: In response to a first fault event occurring on the electronic device, the target intelligent agent is used to collect data from the electronic device to obtain target data of multiple data types; The target intelligent agent is associated with the data type.

10. An electronic device, comprising: A memory used to store computer programs and the data generated by the execution of said computer programs; A processor is configured to execute the computer program to: in response to a first fault event occurring on the electronic device, acquire data from the electronic device to obtain target data of multiple data types; Feature extraction is performed on the target data of each data type to obtain the fault features corresponding to the first fault event; the fault features include the fault identifier and fault handling information of the first fault event; The fault characteristics are added to the fault characteristic database as retrieval data. The retrieval data in the fault feature database can be used to match a second fault event occurring on the electronic device to obtain fault handling information that matches the second fault event.

Images