Fault diagnosis data labeling method and device

Abstract

The invention provides a fault diagnosis data annotation method and device, electronic equipment and a medium, belongs to the technical field of data annotation, and aims to solve the problem of low efficiency of manual data annotation in related technologies. The method comprises the steps that a work order processing record is acquired from a work order system, and the work order processing record comprises a log identification code used by a fault processing terminal for processing a work order and a fault label of a fault component; downloading a corresponding log packet from a log system according to the log identification code; performing standardization processing on the log data in the log packet to obtain standardized log data; and marking the standardized log data by using the fault label of the fault component to obtain a training sample for training a fault diagnosis model.

Description

Technical Field

[0001] The present disclosure relates to the technical field of data annotation, and in particular to a method and device for annotating fault diagnosis data. Background Art

[0002] Data labeling is an important part of AIOPS (Artificial Intelligence for IT Operations), which can process unprocessed log information and convert it into machine-readable data. For fault classification, manual methods are generally used to label logs according to the actual fault type. However, manual labeling of fault labels takes a lot of time, and there is a risk of error in manual labeling. Summary of the invention

[0003] In order to overcome the problems existing in the related art, the present disclosure provides a fault diagnosis data labeling method and device. The technical solution of the present disclosure is as follows:

[0004] According to a first aspect of an embodiment of the present disclosure, a fault diagnosis data labeling method is provided, comprising:

[0005] Acquire a work order processing record from the work order system, wherein the work order processing record includes: a log identification code used by the fault processing terminal to process the work order, and a fault label of the faulty component;

[0006] Download the corresponding log package from the log system according to the log identification code;

[0007] Standardize the log data in the log package to obtain standardized log data;

[0008] The standardized log data is labeled with the fault labels of the faulty components to obtain training samples for training the fault diagnosis model.

[0009] Optionally, after sending the training sample to the model for training, the method further includes:

[0010] Download another batch of log packages for testing from the log system;

[0011] Performing standardization processing on the log data in the log package for testing to obtain standardized log data;

[0012] Sending the log data to the model for inference;

[0013] By comparing the inference results with the information in the work order system, the accuracy of the model is optimized.

[0014] Optionally, after the model is launched, the method further includes:

[0015] Get real-time log packages;

[0016] Sending the log data of the real-time log package to the model for real-time reasoning after standardization;

[0017] By comparing the inference results with the information in the work order system in real time, the accuracy of the model can be checked and optimized in real time.

[0018] Optionally, before downloading the corresponding log package from the log system according to the log identification code, the method further includes:

[0019] In the case where the work order processing record is used to determine the faulty component based on the in-band log, the log packet is ignored;

[0020] If there is no clear record in the log package, or if the fault recorded in the log package is inconsistent with the result after the auxiliary test, the log package is ignored;

[0021] In the case where the log package is collected after on-site maintenance is completed and a cleanup action is performed, the log package is ignored.

[0022] Optionally, it also includes:

[0023] Filtering the fault label;

[0024] The filtering process of the fault label includes:

[0025] When the fault tag is a multi-fault tag associated with another fault tag, ignoring the fault tag;

[0026] In the case where the fault label is a non-associated multiple fault label, retaining the fault label;

[0027] In the case where there are multiple fault labels of the same category, one fault label is determined from the multiple fault labels to be reserved; wherein the fault labels of the same category are uniformly named;

[0028] The method of labeling the standardized log data with the fault label of the fault component to obtain a training sample for training the fault diagnosis model includes:

[0029] The standardized log data is labeled using the filtered fault labels.

[0030] Optionally, the log data in the log package is standardized to obtain standardized log data, including:

[0031] Preprocessing the log data in the log package to obtain preprocessed log data; the preprocessing includes: filtering and structural processing the error keywords by using regular matching;

[0032] The preprocessed log data is subjected to standardization processing to obtain standardized log data; the standardization processing includes: standardizing the fault type in the log data, standardizing the fault slot, and standardizing the error keywords in the log data;

[0033] The standardization of the fault slot includes:

[0034] For the fault slots of the same type but different formats in different log data, merging the fault slots by identifying the log data;

[0035] For multiple fault slots with inclusion relationships in the same log data, the fault slots are merged by removing the fault slots without clear slot data in the inclusion relationship and retaining the fault slots with clear slot data.

[0036] Optionally, preprocessing the log data in the log package to obtain preprocessed log data includes:

[0037] In the case where the log data structure and content in the log package are fixed, the error reporting keywords of the relevant specifications are summarized; the error reporting keywords are filtered by regular matching to obtain the error reporting keywords;

[0038] In the case where the log data structure in the log package is fixed but the content is not fixed, the log data in the log package is analyzed according to the log characteristics of the log package to obtain the filtered error keywords;

[0039] When the log data structure and content in the log package are not fixed, the error keyword is obtained by continuously covering it through error keyword matching.

[0040] Optionally, performing standardization processing on the preprocessed log data to obtain standardized log data further includes:

[0041] If the same component fails again after being repaired, the repair operation is added to the log data;

[0042] In the case where there are additional actions before a component fails, or in the case where there are additional actions after a component fails, the additional actions are supplemented in the log data.

[0043] Optionally, batch processing the log data in the log package through the window further includes:

[0044] When there are too many log packets, retain the log packets within the window;

[0045] When the log packages are insufficient, the log packages are copied and filled to ensure that there are enough log packages in the window.

[0046] According to a second aspect of an embodiment of the present disclosure, a fault diagnosis data labeling device is provided, comprising:

[0047] An acquisition module is used to acquire a work order processing record from a work order system, wherein the work order processing record includes: a log identification code used by a fault processing terminal to process the work order, and a fault label of a faulty component;

[0048] The download module is used to download the corresponding log package from the log system according to the log identification code;

[0049] A standardization module is used to standardize the log data in the log package to obtain standardized log data;

[0050] The labeling module is used to label the standardized log data with the fault labels of the faulty components to obtain training samples for training the fault diagnosis model.

[0051] According to a third aspect of an embodiment of the present disclosure, there is provided an electronic device, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the computer program is executed by the processor, the steps of the fault diagnosis data labeling method described in the first aspect are implemented.

[0052] According to a fourth aspect of an embodiment of the present disclosure, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps of the fault diagnosis data labeling method described in the first aspect are implemented.

[0053] According to a fifth aspect of an embodiment of the present disclosure, a computer program product is provided, including a computer program, and when the computer program is executed by a processor, the steps of the fault diagnosis data labeling method described in the first aspect are implemented.

[0054] The present invention can provide real fault data and related labels by extracting fault labels from the work order system, ensuring that the labeled basic data comes from the actual fault handling process, and obtaining related log packages through log identification codes to ensure that the data used matches the fault labels, thereby ensuring the relevance and integrity of the data; standardizing the log data can convert the data into a consistent format, reduce noise and variability in processing, and improve data quality; marking the standardized log data with fault labels can provide high-quality label data for training the fault diagnosis model, helping the model to learn and identify fault modes more accurately. BRIEF DESCRIPTION OF THE DRAWINGS

[0055] In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings required for use in the description of the embodiments of the present disclosure will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present disclosure. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0056] Figure 1 is a schematic diagram of the steps of a fault diagnosis data labeling method shown in an embodiment of the present disclosure;

[0057] Figure 2 is a schematic diagram of a fault diagnosis data annotation training system shown in an embodiment of the present disclosure;

[0058] Figure 3 is a schematic diagram of data annotation and model reasoning verification shown in an embodiment of the present disclosure;

[0059] Figure 4 is a schematic diagram of a SEL log shown in an embodiment of the present disclosure;

[0060] Figure 5 is a schematic diagram of an IDL log shown in an embodiment of the present disclosure;

[0061] Figure 6 is a schematic diagram of a Dmesg log shown in an embodiment of the present disclosure;

[0062] FIG. 7( a ) is a schematic diagram of a fault type standardization shown in an embodiment of the present disclosure;

[0063] FIG7( b ) is a schematic diagram of a fault type standardization shown in an embodiment of the present disclosure;

[0064] FIG7( c ) is a schematic diagram of a fault type standardization shown in an embodiment of the present disclosure;

[0065] FIG8( a ) is a schematic diagram of a fault keyword standardization shown in an embodiment of the present disclosure;

[0066] FIG8( b ) is a schematic diagram of a fault keyword standardization shown in an embodiment of the present disclosure;

[0067] FIG8( c ) is a schematic diagram of a fault keyword standardization shown in an embodiment of the present disclosure;

[0068] Fig. 9 is a schematic diagram of an error reproduction shown in an embodiment of the present disclosure;

[0069] Fig.10 is a schematic diagram showing an additional action before a fault in an embodiment of the present disclosure;

[0070] Fig.11 is a schematic diagram showing an additional action after a fault in an embodiment of the present disclosure;

[0071] FIG12( a ) is a schematic diagram of a slot merging method shown in an embodiment of the present disclosure;

[0072] FIG12( b ) is a schematic diagram of a slot merging method shown in an embodiment of the present disclosure;

[0073] FIG. 13( a ) is a schematic diagram showing a comparison of work order detail levels according to an embodiment of the present disclosure;

[0074] FIG13( b ) is a schematic diagram showing a comparison of work order detail levels according to an embodiment of the present disclosure;

[0075] Fig.14 is a schematic diagram of merging slots of the same log shown in an embodiment of the present disclosure;

[0076] Fig.15 is a block diagram of a fault diagnosis data labeling device shown in an embodiment of the present disclosure;

[0077] Fig.16 It is a schematic diagram of an electronic device shown in an embodiment of the present disclosure. DETAILED DESCRIPTION

[0078] The following will be combined with the drawings in the embodiments of the present disclosure to clearly and completely describe the technical solutions in the embodiments of the present disclosure. Obviously, the described embodiments are part of the embodiments of the present disclosure, rather than all of the embodiments. Based on the embodiments in the present disclosure, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present disclosure.

[0079] The terms "first", "second", etc. in the specification and claims of the present disclosure are used to distinguish similar objects, and are not used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable when appropriate, so that the embodiments of the present disclosure can be implemented in an order other than those illustrated or described herein, and the objects distinguished by "first", "second", etc. are generally of the same type, and the number of objects is not limited. For example, the first object can be one or more. In addition, "and / or" in the specification and claims represents at least one of the connected objects, and the character " / " generally indicates that the objects associated with each other are in an "or" relationship.

[0080] AIOPS data labeling is generally divided into two links. The first link is fault classification, which is to classify the fault types of the logs, standardize the classification according to the actual fault types, and label each classified fault with a corresponding label, such as memory failure, CPU failure, network card failure, etc. The higher the classification accuracy, the better the training effect of the AIOPS model. The second link is log standardization, which requires standardization of different types of logs. Different types of logs include logs in different formats such as SEL, IDL, Smart, etc. Different types of logs can be extracted, filtered, cleaned, and standardized in terms of log structure and log content. The better the standardization effect of different types of logs, the better the training effect of the AIOPS model.

[0081] In related technologies, fault classification is generally done manually, by labeling logs according to the actual fault type, while log standardization generally uses a keyword regular matching script, or clustering tools and models, to screen or classify key fault points and then perform standardization. This can lead to some problems. For example, manual labeling of fault labels takes a lot of time, and there is a risk of error in manual labeling. When standardizing logs, using regular or clustering methods can screen out fault points and format them in the required format for output, but it cannot effectively capture the contextual content, and the processing of different types of fault points may not be in place; in addition, the model trained by related technologies needs to be verified manually or semi-manually.

[0082] Figure 1 FIG. 1 is a schematic diagram of the steps of a fault diagnosis data labeling method shown in an embodiment of the present disclosure. Figure 1 As shown, the fault diagnosis data labeling method may specifically include the following steps:

[0083] Step S11: Obtain a work order processing record from the work order system, wherein the work order processing record includes: a log identification code used by the fault processing terminal to process the work order, and a fault label of the faulty component.

[0084] A work order system is a software system used to manage, track and resolve various service requests, maintenance tasks and fault reports. When a work order is generated when reporting a problem or requesting service, a work order can be generated; the work order can then be assigned to a handler; the work order system can track the progress of the work order; after the work order is resolved, the solution is recorded and the work order is closed. The work order system can ensure that all problems are handled in a timely manner, and the work order system can provide a detailed history for subsequent analysis and improvement.

[0085] The work order processing record refers to a detailed record of the processing process and results for each work order. Customers or technical support personnel can create a new work order in the work order system and describe the fault situation; the system generates a unique work order label and assigns a log identification code, which is used to identify the log related to the work order; in the detailed information of the work order, the log identification code will be recorded as the association identifier between the work order and the log data.

[0086] The work order processing record may also include a fault tag of the faulty component associated with the work order; the fault tag may identify and classify different types of faults.

[0087] Step S12: Download the corresponding log package from the log system according to the log identification code.

[0088] The log system is a system used to collect, store and manage log data generated by the system or application. The work order system and the log system are connected. The fault information recorded by the work order system can be associated with the log data in the log system, and the relevant log information can be queried in the log system through the log identification code.

[0089] The log package can be downloaded from the log system through the log identification code. The log package contains all log information related to the log identification code, which may include error information, system status, operation records, etc. The log package can record the diagnosis results and solutions of the fault.

[0090] Step S13: performing standardization processing on the log data in the log package to obtain standardized log data.

[0091] There can be logs from different sources, such as SEL logs, Sensor logs, Raid logs, etc.; logs from different sources may use different formats and naming methods. Some logs have fixed structures and contents, some have fixed structures but not fixed contents, and some have neither fixed structures nor contents. In addition, logs from different sources may have different levels of information detail for the same problem.

[0092] Therefore, for logs from different sources, the log data in the log package can be processed into a unified format in a standardized way, such as data with consistent structure and standardized fault content, to ensure the comparability and consistency of the data in subsequent analysis. In addition, during the model training process, standardized data can improve the model training effect.

[0093] Step S14: labeling the standardized log data with the fault labels of the faulty components to obtain training samples for training the fault diagnosis model.

[0094] Labeling training samples is the basis of model learning. By combining standardized data with fault labels, the model can better understand the characteristics of different fault types, thereby improving the accuracy of its classification and prediction. Labeling standardized log data with the fault labels of faulty components can create a high-quality training data set; enabling the model to learn the specific characteristics and patterns of faults.

[0095] By adopting the embodiments of the present disclosure, a large number of actual fault cases and log data of their processing processes can be efficiently collected by directly obtaining work order processing records from the work order system; the log data is marked with the fault label of the faulty component, ensuring the accuracy and consistency of the marking, and avoiding the subjectivity and errors that may be caused by manual marking; by automatically collecting and marking log data, the method can quickly generate a large number of samples for training fault diagnosis models, thereby helping the model to learn more and more comprehensive fault characteristics and patterns; with the continuous processing of new work orders and the continuous collection of log data, the method can also provide new training samples for the model, supporting the continuous iteration and improvement of the model; by automatically collecting and marking log data, the method reduces the need for manual participation, making the fault diagnosis process more intelligent and automated.

[0096] Among them, in an optional embodiment, after sending the training samples to the model for training, it also includes: downloading another batch of log packages for testing from the log system; standardizing the log data in the log packages for testing to obtain standardized log data; sending the log data to the model for reasoning; and optimizing the accuracy of the model by comparing the reasoning results with the information in the work order system.

[0097] After sending a batch of formatted log data marked with the fault labels of the faulty components to the model for training, it is also necessary to conduct certain tests on the performance of the model.

[0098] Another batch of test data sets is sent to the model, and the performance of the model is tested through the test data sets. Specifically, another batch of work order processing records can be obtained from the work order system. This batch of work order processing records is different from the work order processing records obtained in the training phase. Through the work order processing records, the corresponding log package is downloaded from the log system, and after the log data in the log package is standardized, the log data is input into the model to be tested, and the fault labels corresponding to the log data are inferred through the model, and the inference results are tracked through the real fault labels in the work order processing records to determine whether the inference results of the model to be tested meet expectations, and the loss value is obtained by comparing the fault labels in the work order processing records with the inferred fault labels, and the parameters of the model to be tested are adjusted based on the loss value.

[0099] In another case, the system environment and failure modes may change over time. Regularly acquiring new log data can ensure that model training and reasoning are based on the latest information, thereby improving the applicability and accuracy of the model. By inputting new standardized data into the model for reasoning, the performance of the model in actual applications can be verified. Comparing the reasoning results with the actual failure records in the work order system can evaluate the accuracy and reliability of the model. Comparing the reasoning results with the actual failure records can form a feedback mechanism. By analyzing the differences between the model's reasoning results and the actual situation, the deficiencies of the model can be identified, providing a basis for subsequent model optimization.

[0100] By using the embodiments of the present disclosure, the accuracy of the fault diagnosis model can be significantly improved, and false positives and false negatives can be reduced through comparison with actual fault labels and model optimization. The automated testing and optimization process can significantly reduce the time and cost of manual participation and improve the overall efficiency of fault diagnosis. A closed-loop feedback mechanism is established to promote the continuous improvement of model performance through continuous testing and optimization of the model.

[0101] Among them, in an optional embodiment, after the model is put into operation, it also includes: obtaining a real-time log package; sending the log data of the real-time log package to the model for real-time reasoning after standardization; and checking and optimizing the accuracy of the model in real time by comparing the reasoning results with the information in the work order system in real time.

[0102] Logs in the production environment are generated dynamically. The real-time monitoring function of the log system can be used to capture newly generated log packages. The captured real-time log packages can be stored in a specified buffer or message queue for subsequent processing. After the log data in the log package is standardized, the standardized data is input into the model for inference.

[0103] Receive the model's inference results on the log data in the log package, and query the corresponding actual fault information from the work order system based on the corresponding identifiers of the log data and the work order system. Compare the model's inference results with the actual fault information in the work order system to calculate the real-time accuracy. Check the model's accuracy in real time and trigger an alarm when the accuracy drops. Based on the comparison results and accuracy monitoring, optimize the model in real time, such as adjusting model parameters.

[0104] By adopting the embodiments of the present disclosure, the faults and abnormal conditions in the system can be captured in time through the real-time acquisition of log data. By inputting the log data into the model for reasoning, the fault type and location can be quickly identified, thereby speeding up the response time of fault handling. By comparing the reasoning results with the actual fault records in the work order system, instant feedback on the current system status can be formed, and the model can be continuously adjusted and optimized based on this to better adapt to changes in the production environment.

[0105] Figure 2 Schematic diagram of a fault diagnosis data annotation training system shown in an embodiment of the present disclosure. Figure 2 As shown, fault labels are obtained from the work order system, corresponding log packages are obtained from the log system, and data standardization is performed on the log packages; data standardization is performed on the log data through the fault labels, and the labeled data standardization log data is used as training data, as a training data set; the training data set is used for model training through model iteration, model training, and vectorization; another batch of log packages are obtained from the log system, the log data in this batch of log packages are data standardized, and used as inference data; the inference data is sent to the trained model for inference; that is, the inference result is compared with the corresponding information in the work order system to adjust the model.

[0106] Figure 3 Schematic diagram of data annotation and model reasoning verification shown in the embodiment of the present disclosure. Figure 3As shown, first, the monthly data of the work order system is exported, including the work order processing details and the log identification code; only when there is a log identification code, the corresponding log package will be downloaded, and if there is no log identification code, the work order will be ignored; the fault label obtained in the work order system is verified, specifically through the label acquisition verification module, which includes operations such as log attributes, on-site auxiliary actions, multi-label filtering, and multi-label deduplication; then it is necessary to determine whether the log is reasonable. If the log is reasonable, the corresponding log package is downloaded from the log system, and if the log is unreasonable, the corresponding log package is ignored; the log data in the log package is standardized, mainly through the data standardization module, including keyword regular matching, data standardization, fault context supplementation, and data aggregation; the standardized log and label data set after standardization are used as training data sets; the training data set is sent to the AI ​​model; reasoning is performed through the AI ​​model to obtain reasoning results; the reasoning results are compared with the actual labels, and the model is optimized based on the comparison results.

[0107] Among them, in an optional embodiment, before downloading the corresponding log package from the log system according to the log identification code, it also includes: when the work order processing record is based on the in-band log to judge the faulty component, ignoring the log package; when there is no clear record in the log package, or when the fault recorded in the log package is inconsistent with the result after the auxiliary test, ignoring the log package; when the log package is collected after the on-site maintenance is completed and the cleanup action is performed, ignoring the log package.

[0108] Data quality is the key to model training results. Therefore, in some cases, log identification codes are marked in the work order system, but the log packages corresponding to the log identification codes are ignored. This is because the log information in these ignored log packages is unreliable to some extent. If inappropriate log data is used for training, noise may be introduced, causing the model to learn wrong information, thereby affecting the performance of the model.

[0109] In-band logs can contain the real-time status and detailed fault information of the device, while work order logs generally only upload out-of-band logs. This inconsistency means that the logs may not fully reflect the actual fault conditions of the device, so using these logs for training may cause the model to learn incorrect information. Therefore, when it is detected that the work order processing record actually judges the faulty component based on the in-band log, the log package corresponding to the work order processing record is ignored.

[0110] During the process of engineers repairing the fault, the equipment may go down, so the information record may be incomplete. If the log does not clearly record the fault, or the recorded fault is inconsistent with the actual situation, the model may learn the wrong fault information, which will affect its performance in actual applications. Before downloading the log package, you can use the quick scanning algorithm to check whether the log package contains the necessary record information. If no clear fault record is found in the log package or key information is missing, the log package is marked as "ignorable". If auxiliary tests are performed and the fault information recorded in the comparison test results is inconsistent with the log package, the log data in the log package may be inaccurate or outdated, and it is marked as "ignorable".

[0111] During the maintenance process, engineers may perform cleanup operations, such as restarting the device, clearing the cache or logs, etc., which will cause the previous fault records to be cleared, so that the logs collected later cannot reflect the fault status before the maintenance. Therefore, you can check the collection time point and context information of the log package, especially whether it occurs after the on-site maintenance is completed and the cleanup action is performed immediately. If the log package is obtained after the on-site maintenance is completed and the cleanup action is performed, then the information in the log package no longer reflects the original fault situation, and the log package is marked as "ignorable".

[0112] By using the embodiments of the present disclosure, by confirming the validity of the log, it is possible to ensure that the data used for model training is of high quality. By identifying and excluding inappropriate log data, the noise in the training data can be reduced. By excluding inappropriate logs, computing resources and time can be saved, and unnecessary training and verification on invalid data can be avoided.

[0113] Among them, in an optional embodiment, it also includes: filtering the fault label; the filtering of the fault label includes: when the fault label is an associated multiple fault label, ignoring the fault label; when the fault label is an unassociated multiple fault label, retaining the fault label; when there are multiple fault labels of the same category, determining one fault label from the multiple fault labels to retain; wherein the fault labels of the same category are uniformly named; the use of the fault labels of the faulty components to label the standardized log data to obtain training samples for training the fault diagnosis model includes: labeling the standardized log data with the filtered fault labels.

[0114] In order to improve the quality of training data and the accuracy of the model, it is necessary to filter the fault labels of faulty components to obtain fault labels that can accurately and comprehensively reflect the fault information.

[0115] Some labels may have a mutual influence relationship. Including these labels at the same time may cause the model to be unable to accurately determine the root cause of the fault, causing confusion and interference to the model. Therefore, for correlated multiple fault labels, such fault labels can be ignored.

[0116] If there is no direct relationship between some multiple labels, retaining these labels can enrich the training data, enhance the generalization ability of the model, and help the model learn the characteristics of different types of faults. Therefore, for non-correlated multiple fault labels, such labels can be retained.

[0117] If there are multiple labels of the same type, multiple labels of the same type may cause the model to overfit. Therefore, by filtering and retaining only one label, the model input can be simplified, redundant information can be reduced, and the training efficiency and accuracy of the model can be improved. Therefore, for multiple labels of the same category, one of the fault labels can be selected to be retained and the remaining fault labels can be ignored to filter the fault labels. In addition, unified label naming can eliminate the confusion caused by inconsistent naming of the same fault type in different logs. By unifying the naming of labels of the same type, the neatness and consistency of the data set can be improved, thereby enhancing the learning effect of the model.

[0118] By adopting the embodiments of the present disclosure, by ignoring correlated multiple labels and reducing the interference of the model during the training process, the model can be more focused on identifying the characteristics of a single fault, thereby improving the accuracy of fault diagnosis. Retaining non-correlated multiple labels helps to enrich the training data so that the model can learn more fault characteristics and patterns. By filtering the same type of labels and retaining only one label, redundant information can be reduced, the complexity of the model can be reduced, and the risk of overfitting can be reduced. Unified label naming can eliminate confusion caused by inconsistent naming and ensure the neatness and consistency of the data set. Through label filtering processing, the complexity of subsequent data processing and analysis can be reduced, and the data preprocessing process can be simplified.

[0119] Among them, in an optional embodiment, the log data in the log package is standardized to obtain standardized log data, including: preprocessing the log data in the log package to obtain preprocessed log data; the preprocessing includes: filtering and structured processing of error keywords using regular matching; the preprocessed log data is standardized to obtain standardized log data; the standardized processing includes: standardizing the fault types in the log data, standardizing the fault slots, and standardizing the error keywords in the log data; the standardization of the fault slots includes: merging the fault slots of the same type but different formats in different log data by identifying the log data; for multiple fault slots with an inclusion relationship in the same log data, the fault slots are merged by removing the fault slots without clear slot data in the inclusion relationship and retaining the fault slots with clear slot data.

[0120] Collect raw log data from different log sources. The raw log data needs to cover all relevant systems and devices. Raw log data may contain noise, errors, or incomplete information. The log data in the log package can be preprocessed to clean and filter unnecessary data to improve the overall quality of the log data. In addition, the corresponding log package can be downloaded from the log system through the log identification code provided by the work order system, and log packages from different sources may be obtained. For example, SEL logs, Sensor logs, Audit logs, Smart logs and other logs. Logs from different sources have different formats and structures. Preprocessing can convert these data into a unified format to simplify subsequent data analysis and processing.

[0121] Log entries not relevant to fault detection can be identified and removed, as well as missing data items, which can be filled, deleted, or ignored as needed. Regular expressions can be designed to match specific fault patterns and error messages based on the structure and content of the logs. Ensure that these expressions capture all possible fault types. Multiple rounds of filtering can be performed based on different fault types and log formats to ensure that all relevant fault information is extracted.

[0122] After the log data is preprocessed, the log data can be further standardized. Standardization can convert the log data into a unified format, making the content more standardized and reducing the complexity of data processing. It can include standardizing the fault type in the log data, standardizing the fault slot, and standardizing the error keywords in the log data.

[0123] The fault types in the log data are standardized. Specifically, a set of standardization rules can be defined according to the actual fault types, and the fault types from different sources are unified into standard names. For example, "memory fault", "memory error", "Memory Failure" and the like are unified into "memory fault". A mapping relationship table of fault types is established to map synonyms or variants that may exist in different logs to a unified standard name. FIG7 is a schematic diagram of a fault type standardization shown in an embodiment of the present disclosure. FIG7(a) is a schematic diagram of a fault type standardization shown in an embodiment of the present disclosure, which is an IDL log, and the error type is Disk; FIG7(b) is a schematic diagram of a fault type standardization shown in an embodiment of the present disclosure, which is an SEL log, and the error type is Drive Slot; FIG7(c) is a schematic diagram of a fault type standardization shown in an embodiment of the present disclosure, which is a Raid card log, and the error type is Physical Drive; the same error type in logs from three different sources can be standardized into Disk.

[0124] Standardization of fault slots can be performed by defining a standard format for fault slots, and identifying slot information from different log sources on the same device when processing log data, and merging them. FIG. 12 is a schematic diagram of a slot merge shown in an embodiment of the present disclosure. For example, if the SEL log is represented as "DISK7_Status", as shown in FIG. 12(a), FIG. 12(a) is a schematic diagram of a slot merge shown in an embodiment of the present disclosure, and the IDL log is represented as "Front DISK7", as shown in FIG. 12(b), FIG. 12(b) is a schematic diagram of a slot merge shown in an embodiment of the present disclosure, then these two slot information are merged into a standard slot "Slot 7". In the standardization process, duplicate slot information is removed to ensure that each fault slot appears only once in the data set, thereby improving the accuracy of the data. In addition, for multiple fault slot data with a containment relationship in the same log data, these fault slots can be analyzed, and the fault slots with clear slot data are retained, and the fault slots without clear slot data are ignored, thereby achieving standardization of the fault slots. Fig.14 The diagram is a schematic diagram of merging slots of the same log shown in an embodiment of the present disclosure. Fig.14 As shown in the figure, there is a hard disk with an unclear slot and a clear hard disk, and the slot is a clear DISK4_Status. Therefore, the unclear slot data will be removed and only the error report of the clear memory slot will be retained.

[0125] Standardizing the error keywords in the log data can identify and extract keywords in the fault description and perform standardization. For example, "Correctable ECC Error", "An uncorrected error of Memory", etc. are unified as "Correctable ECC". Figure 8 is a schematic diagram of a fault keyword standardization shown in an embodiment of the present disclosure. As shown in Figure 8, for error keywords with consistent meanings, Figure 8 (a) is a schematic diagram of a fault keyword standardization shown in an embodiment of the present disclosure, Figure 8 (a) is a SEL log, and the SEL log defines this keyword as Correctable ECC; Figure 8 (b) is a schematic diagram of a fault keyword standardization shown in an embodiment of the present disclosure, Figure 8 (b) is an IDL log, and the IDL log in Figure 8 (b) defines this keyword as An corrected error of Memory; Figure 8 (c) is a schematic diagram of a fault keyword standardization shown in an embodiment of the present disclosure, Figure 8 (c) is Blackbox, and the Blackbox log in Figure 8 (c) defines this keyword as Correctable ECC Error logging limit reached; when this keyword is obtained from different sources, the keyword can be standardized as Correctable ECC.

[0126] By adopting the embodiments of the present disclosure, non-critical information or noise in the log, such as repeated and insignificant log entries, is filtered out through regular matching, which helps to reduce the amount of data to be processed subsequently and improve analysis efficiency. The original unstructured or semi-structured log data is converted into a structured data format, which is convenient for computer understanding and processing, and also convenient for subsequent data analysis and query. The naming of fault types in different logs is unified to avoid recognition errors caused by inconsistent naming and improve the accuracy of fault identification. The error keywords are standardized so that similar error messages can be uniformly identified and processed, which helps to quickly locate the problem. By merging fault slots of the same type but different formats, the data model is simplified, data redundancy is reduced, and the readability and maintainability of the data are improved. For fault slots containing multiple hierarchical relationships, the slots without clear data are removed and the key information is retained, making the log data more concise and clear, and improving the effectiveness and utilization of the data.

[0127] In addition, the level of detail of the logs from different sources for the same work order is inconsistent. Figure 13 is a schematic diagram of a work order detail comparison shown in an embodiment of the present disclosure. Figure 13(a) is a schematic diagram of a work order detail comparison shown in an embodiment of the present disclosure, which is the memory information recorded by the IDL log, and Figure 13(b) is a schematic diagram of a work order detail comparison shown in an embodiment of the present disclosure, which is the memory and hard disk information recorded by the sel log. The information in the IDL log will be more detailed than the information in the sel log, and the fault data of the memory of the IDL log and the hard disk of the SEL log are output.

[0128] Among them, in an optional embodiment, the log data in the log package is preprocessed to obtain preprocessed log data, including: when the log data structure and content in the log package are fixed, the various error reporting keywords of the relevant specifications are summarized; the error reporting keywords are filtered by regular matching to obtain the error reporting keywords; when the log data structure in the log package is fixed but the content is not fixed, the log data in the log package is analyzed according to the log characteristics of the log package to obtain the filtered error reporting keywords; when the log data structure in the log package is not fixed and the content is not fixed, continuous coverage is performed by error reporting keyword matching to obtain the error reporting keywords.

[0129] According to the system or application log specifications, clarify which keywords or phrases are considered error keywords. These specifications may be based on existing error codes, exception types, or system messages. For each error keyword, build a corresponding regular expression that can accurately match the corresponding error information in the log while minimizing the possibility of mismatches.

[0130] Logs from different sources can be divided into several types, such as logs with fixed structures and contents, logs with fixed structures but non-fixed contents, and logs with non-fixed structures and contents. Different preprocessing schemes can be adopted for different types of logs.

[0131] For logs with fixed structure and content, the characteristics of such logs are fixed log structure and fixed log errors, such as SEL logs, Sensor logs, Raid logs, etc., traverse each log in the log package, use the constructed regular expression to match the log content, extract the matched error keywords from the log, and further filter out non-critical information such as timestamps and log levels as needed. Figure 4 FIG. 1 is a schematic diagram of a SEL log shown in an embodiment of the present disclosure. Figure 4 As shown in the figure, Section 42 of the IPMI2.0 specification details all error types under the IPMI specification. Figure 4 This is the content corresponding to the CPU component.

[0132] For logs with fixed structures but not fixed contents, such as IDL logs, Audit logs, Smart logs, etc., there is no complete set of fault contents for such logs, but the error keywords can be obtained through specific analysis based on specific log characteristics, such as the fixed position and type of log fields. For example, based on log characteristics, an algorithm or script can be developed to dynamically identify error keywords in logs, and the dynamically identified error keywords can be used to filter logs and extract key information. Figure 5 FIG. 1 is a schematic diagram of an IDL log shown in an embodiment of the present disclosure. Figure 5 As shown in the figure, IDL log is an out-of-band log. This type of log has an alarm level, and the alarm feature log can be dynamically filtered according to the alarm level. For example Figure 5 The info mark indicates that this is an information-level error.

[0133] For logs with non-fixed structures and contents, such logs have the characteristics of diverse structures and contents. For example, Dmesg logs can be continuously covered by matching error keywords to obtain the error keywords. Continuous coverage includes two aspects: first, with the update of the system or application, new error types or error information may appear, so these new error keywords need to be added to the set; second, with the in-depth understanding of system behavior, previously unrecognized error patterns or features may be discovered, and this information also needs to be integrated into the error keyword set. This continuous coverage strategy helps ensure that the log processing system can comprehensively and accurately capture the error and abnormal information in the system. Figure 6 FIG. 1 is a schematic diagram of a Dmesg log shown in an embodiment of the present disclosure. Figure 6 As shown in the figure, the Dmesg log has an unfixed structure and content.

[0134] By using the embodiments of the present disclosure, logs containing error keywords can be quickly filtered out from a large number of logs through regular matching, thereby improving the efficiency of troubleshooting. Non-critical information in the log is removed, making the error information more prominent and convenient for subsequent analysis. Even if the log content is not fixed, the error information can be captured through dynamic recognition, which improves the flexibility of the processing system. For logs with non-fixed structure and content, more comprehensive error information can be obtained through continuous coverage.

[0135] Among them, in an optional embodiment, the preprocessed log data is standardized to obtain standardized log data, and it also includes: when the same component fails again after being repaired, the repair operation is added to the log data; when there are additional actions before a component fails, or when there are additional actions after a component fails, the additional actions are added to the log data.

[0136] In the actual process of manual log analysis, in addition to the error content itself, in many cases it is also necessary to pay attention to the context of the error, whether there are other related factors, whether the fault has been repaired, etc.

[0137] The system identifies component repair events recorded in the log data, which relies on specific keywords, timestamps, or event codes in the logs. The system determines whether the fault reoccurs after the repair based on the specific keywords. If it is confirmed that the component has reoccurred after the repair, the system traces back to the log entries of the repair operation and adds these entries to the log data of the reoccurrence of the fault in some way, such as comments, additional fields, etc. Fig. 9 FIG. 1 is a schematic diagram of an error reproduction shown in an embodiment of the present disclosure. Fig. 9 As shown, the status changes of the hard disk in slot DISK2 are described, including the detection, clearing and re-detection of the fault. Hard disk DISK2 failed twice in October and November 2021. If only the fault keyword filtering of Drive Fault is performed, it will only be judged as a single hard disk failure. Therefore, the action of replacing the hard disk is supplemented, such as Drive Present Deassert (hard disk unplugged) > Drive Present Assert (hard disk inserted), which can indicate that this is a case of fault reproduction.

[0138] In the case of additional actions before or after a component fails, the system needs to identify these actions and determine whether they are potentially related to the occurrence of the failure. If it is determined that there is a potential correlation, the log entries of these additional actions are added to the fault log data in an appropriate manner. Fig.10 FIG. 1 is a schematic diagram showing an additional action before a fault in an embodiment of the present disclosure. Fig.10 As shown in the figure, the server has memory UCE when it is restarted. Therefore, a pre-restart action can be added during data annotation. Fig.11 FIG. 1 is a schematic diagram showing an additional action after a fault in an embodiment of the present disclosure. Fig.11 As shown in the figure, the hard disk failed and there was an action to fix it. However, when analyzing the following text, we can see the action of shutting down the computer, so the fault was fixed by shutting down the computer, rather than fixing it automatically. Adding the shutdown action to the standardized data will make the training data more comprehensive.

[0139] Using the embodiments of the present disclosure, context completion can provide additional information for fault data, such as the system status, operation records, environmental factors, etc. when the fault occurred. This information helps to understand the cause and impact of the fault, so as to better perform fault analysis and diagnosis. By supplementing the context information, the type of fault and the cause of the fault can be more accurately identified. Faults often do not occur in isolation and may be related to other events or operations. Context completion can help analyze these complex relationships, identify potential related faults, and improve the efficiency of fault handling. In machine learning and data mining, rich context information can provide more features for the model, which helps to improve the learning effect and prediction accuracy of the model.

[0140] Among them, in an optional embodiment, batch processing of the log data in the log package is performed through a window, which also includes: when there are too many log packages, retaining the log packages in the window; when the log packages are insufficient, copying and filling the log packages to ensure that there are enough log packages in the window.

[0141] Determine the number of log packets, time span, or other related parameters that should be included in the window. Initialize the window to ensure that the window is in a ready state to receive and process incoming log packets.

[0142] When a new log packet is generated or arrives, the system captures it and prepares it for processing. The system checks the number of log packets in the current window to determine whether adjustments are needed.

[0143] If the number of log packets in the window exceeds the preset threshold, the system needs to take measures to handle the excess log packets. This can be: Evaluate the importance or priority of log packets. Determine which log packets are critical and which may be redundant based on the content, timestamp, or other attributes of the log packets; keep important log packets in the window for subsequent analysis or processing; for unimportant log packets, you can choose to discard them directly or archive them for long-term storage.

[0144] If the number of log packages in the window is insufficient, the system needs to ensure that there are enough log packages in the window by copying and filling. You can do this by: determining which log packages are suitable for copying based on the nature and processing requirements of the log packages; copying the selected log packages to the window until the preset number of log packages is reached. If it is still insufficient, you can consider using empty log packages or default log packages for filling.

[0145] By adopting the embodiments of the present disclosure, the number of separate processing times for a single log package can be reduced by processing log packages in batches in a windowed manner, thereby improving the overall processing efficiency. In the case of too many log packages, retaining some log packages can optimize the utilization of storage and computing resources. In the case of insufficient log packages, by copying and filling log packages, it can be ensured that there are always enough log packages in the window for subsequent processing and analysis, thereby maintaining the integrity and consistency of the data. The windowed processing method allows the window size and rules to be adjusted according to actual needs to adapt to different processing scenarios and changes in demand.

[0146] Among them, in an optional embodiment, when extracting and processing log data, more advanced natural language processing technology, such as deep learning models, can be introduced to more accurately identify and classify key information in logs. For example, a model based on BERT (Bidirectional Encoder Representations from Transformers, a pre-trained deep learning model) is used to automatically identify fault patterns in logs. BERT is a model based on the Transformers architecture that can capture deep semantic relationships of text data through pre-training of a large-scale corpus and fine-tuning of downstream tasks. For specific fault diagnosis tasks, fine-tuning can be performed on the basis of the pre-trained BERT model, and the model can be trained with a small amount of labeled data to identify specific fault modes or error codes. For automatic filtering and selection of fault labels, fault labels can be automatically identified and assigned by training a multi-class classifier. Association rule mining technology is used to discover potential relationships between fault labels. This method can help identify which label combinations often appear together, thereby guiding the selection and filtering of labels. For BERT, a large amount of historical log data can be used to pre-train the BERT model, and then fine-tuned for specific fault diagnosis tasks. The trained BERT model is used to extract feature vectors of log data and combined with other machine learning techniques for further analysis and classification.

[0147] Fig.15 is a block diagram of a fault diagnosis data labeling device shown in an embodiment of the present disclosure. Figure 4 As shown, the fault diagnosis data labeling device includes:

[0148] An acquisition module is used to acquire a work order processing record from a work order system, wherein the work order processing record includes: a log identification code used by a fault processing terminal to process the work order, and a fault label of a faulty component;

[0149] The download module is used to download the corresponding log package from the log system according to the log identification code;

[0150] A standardization module is used to standardize the log data in the log package to obtain standardized log data;

[0151] The labeling module is used to label the standardized log data with the fault labels of the faulty components to obtain training samples for training the fault diagnosis model.

[0152] Optionally, after sending the training samples to the model for training, the fault diagnosis data labeling device further includes:

[0153] Download module, used to download another batch of log packages for testing from the log system;

[0154] The standardization module is further used to perform standardization processing on the log data in the log package for testing to obtain standardized log data;

[0155] An inference module, used to send the log data to a model for inference;

[0156] The comparison module is used to optimize the accuracy of the model by comparing the inference results with the information in the work order system.

[0157] Optionally, after the model is online, the fault diagnosis data labeling device further includes:

[0158] Real-time acquisition module, used to obtain real-time log packages;

[0159] A real-time reasoning module, used for sending the log data of the real-time log package to the model for real-time reasoning after standardization;

[0160] The real-time comparison module is used to check and optimize the accuracy of the model in real time by comparing the inference results with the information in the work order system.

[0161] Optionally, before downloading the corresponding log package from the log system according to the log identification code, the fault diagnosis data labeling device further includes:

[0162] A first ignoring module, configured to ignore the log packet when the work order processing record is used to judge the faulty component according to the in-band log;

[0163] A second ignoring module is used to ignore the log package when there is no clear record in the log package, or when the fault recorded in the log package is inconsistent with the result after the auxiliary test;

[0164] The third ignoring module is used to ignore the log package when the log package is collected after the on-site maintenance is completed and the cleaning action is performed.

[0165] Optionally, the fault diagnosis data labeling device further includes:

[0166] A filtering module, used for filtering the fault labels;

[0167] The filtering module is specifically used to execute:

[0168] When the fault tag is a multi-fault tag associated with another fault tag, ignoring the fault tag;

[0169] In the case where the fault label is a non-associated multiple fault label, retaining the fault label;

[0170] In the case where there are multiple fault labels of the same category, one fault label is determined from the multiple fault labels to be reserved; wherein the fault labels of the same category are uniformly named;

[0171] The marking module is specifically used to execute: marking the standardized log data using the filtered fault labels.

[0172] Optionally, the standardization module is specifically used to execute:

[0173] Preprocessing the log data in the log package to obtain preprocessed log data; the preprocessing includes: filtering and structural processing the error keywords by using regular matching;

[0174] The preprocessed log data is subjected to standardization processing to obtain standardized log data; the standardization processing includes: standardizing the fault type in the log data, standardizing the fault slot, and standardizing the error keywords in the log data;

[0175] The standardization of the fault slot includes:

[0176] For the fault slots of the same type but different formats in different log data, merging the fault slots by identifying the log data;

[0177] For multiple fault slots with inclusion relationships in the same log data, the fault slots are merged by removing the fault slots without clear slot data in the inclusion relationship and retaining the fault slots with clear slot data.

[0178] Optionally, the standardization module is specifically used to execute:

[0179] In the case where the log data structure and content in the log package are fixed, the error reporting keywords of the relevant specifications are summarized; the error reporting keywords are filtered by regular matching to obtain the error reporting keywords;

[0180] In the case where the log data structure in the log package is fixed but the content is not fixed, the log data in the log package is analyzed according to the log characteristics of the log package to obtain the filtered error keywords;

[0181] When the log data structure and content in the log package are not fixed, the error keyword is obtained by continuously covering it through error keyword matching.

[0182] Optionally, the fault diagnosis data labeling device further includes:

[0183] A first completion module is used to complete the repair operation in the log data when the same component fails again after being repaired;

[0184] The second completion module is used to complete the additional actions in the log data when there are additional actions before a component fails or when there are additional actions after a component fails.

[0185] Optionally, the log data in the log package is batch processed through a window, and the fault diagnosis data labeling device further includes:

[0186] A retaining module, used for retaining the log packages within the window when there are too many log packages;

[0187] The filling module is used to ensure that the log packages in the window are sufficient by copying and filling the log packages when the log packages are insufficient.

[0188] It should be noted that the device embodiment is similar to the method embodiment, so the description is relatively simple, and the relevant parts can be referred to the method embodiment.

[0189] The present disclosure also provides an electronic device, referring to Fig.16 , Fig.16 Schematic diagram of an electronic device shown in an embodiment of the present disclosure. Fig.16 As shown, the electronic device 100 includes: a memory 110 and a processor 120. The memory 110 and the processor 120 are connected via a bus communication. A computer program is stored in the memory 110. The computer program can be run on the processor 120 to implement the steps in the fault diagnosis data labeling method disclosed in the embodiment of the present disclosure.

[0190] The embodiment of the present disclosure further provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps in the fault diagnosis data labeling method disclosed in the embodiment of the present disclosure are implemented.

[0191] The embodiments of the present disclosure further provide a computer program product, including a computer program. When the computer program is executed by a processor, the steps in the fault diagnosis data labeling method disclosed in the embodiments of the present disclosure are implemented.

[0192] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.

[0193] Those skilled in the art will appreciate that the embodiments of the present disclosure may be provided as methods, devices or computer program products. Therefore, the embodiments of the present disclosure may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the embodiments of the present disclosure may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0194] The embodiments of the present disclosure are described with reference to the flowcharts and / or block diagrams of the methods, apparatuses, electronic devices, and computer program products according to the embodiments of the present disclosure. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of the processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing terminal device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing terminal device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0195] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing terminal device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured product including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0196] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal device so that a series of operating steps are executed on the computer or other programmable terminal device to produce a computer-implemented process, thereby providing instructions for executing on the computer or other programmable terminal device to implement the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0197] Although some embodiments of the present disclosure have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiment and all changes and modifications that fall within the scope of the present disclosure.

[0198] The above is a detailed introduction to a fault diagnosis data labeling method, device, electronic device and storage medium provided by the present invention. Specific examples are used in this article to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core idea. At the same time, for general technical personnel in this field, according to the idea of ​​the present invention, there will be changes in the specific implementation method and application scope. In summary, the content of this specification should not be understood as a limitation on the present invention.

Claims

1. A fault diagnosis data labeling method, characterized in that: include: Acquire a work order processing record from the work order system, wherein the work order processing record includes: a log identification code used by the fault processing terminal to process the work order, and a fault label of the faulty component; Download the corresponding log package from the log system according to the log identification code; Standardize the log data in the log package to obtain standardized log data; The standardized log data is labeled with the fault labels of the faulty components to obtain training samples for training the fault diagnosis model.

2. The method according to claim 1, characterized in that After sending the training sample to the model for training, the method further includes: Download another batch of log packages for testing from the log system; Performing standardization processing on the log data in the log package for testing to obtain standardized log data; Sending the log data to the model for inference; By comparing the inference results with the information in the work order system, the accuracy of the model is optimized.

3. The method according to claim 2, characterized in that After the model is launched, it also includes: Get real-time log packages; Sending the log data of the real-time log package to the model for real-time reasoning after standardization; By comparing the inference results with the information in the work order system in real time, the accuracy of the model can be checked and optimized in real time.

4. The method according to claim 1, characterized in that Before downloading the corresponding log package from the log system according to the log identification code, it also includes: In the case where the work order processing record is used to determine the faulty component based on the in-band log, the log packet is ignored; If there is no clear record in the log package, or if the fault recorded in the log package is inconsistent with the result after the auxiliary test, the log package is ignored; In the case where the log package is collected after on-site maintenance is completed and a cleanup action is performed, the log package is ignored.

5. The method according to claim 1, characterized in that Also includes: Filtering the fault label; The filtering process of the fault label includes: When the fault tag is a multi-fault tag associated with another fault tag, ignoring the fault tag; In the case where the fault label is a non-associated multiple fault label, retaining the fault label; In the case where there are multiple fault labels of the same category, one fault label is determined from the multiple fault labels to be reserved; wherein the fault labels of the same category are uniformly named; The method of labeling the standardized log data with the fault label of the fault component to obtain a training sample for training the fault diagnosis model includes: The standardized log data is labeled using the filtered fault labels.

6. The method according to claim 1, characterized in that The log data in the log package is standardized to obtain standardized log data, including: Preprocessing the log data in the log package to obtain preprocessed log data; the preprocessing includes: filtering and structural processing the error keywords by using regular matching; The preprocessed log data is subjected to standardization processing to obtain standardized log data; the standardization processing includes: standardizing the fault type in the log data, standardizing the fault slot, and standardizing the error keywords in the log data; The standardization of the fault slot includes: For the fault slots of the same type but different formats in different log data, merging the fault slots by identifying the log data; For multiple fault slots with inclusion relationships in the same log data, the fault slots are merged by removing the fault slots without clear slot data in the inclusion relationship and retaining the fault slots with clear slot data.

7. The method according to claim 6, characterized in that Preprocessing the log data in the log package to obtain preprocessed log data includes: In the case where the log data structure and content in the log package are fixed, the error reporting keywords of the relevant specifications are summarized; the error reporting keywords are filtered by regular matching to obtain the error reporting keywords; In the case where the log data structure in the log package is fixed but the content is not fixed, the log data in the log package is analyzed according to the log characteristics of the log package to obtain the filtered error keywords; When the log data structure and content in the log package are not fixed, the error keyword is obtained by continuously covering it through error keyword matching.

8. The method according to claim 6, characterized in that The preprocessed log data is subjected to standardization processing to obtain standardized log data, further comprising: If the same component fails again after being repaired, the repair operation is added to the log data; In the case where there are additional actions before a component fails, or in the case where there are additional actions after a component fails, the additional actions are supplemented in the log data.

9. The method according to claim 1, characterized in that: Batch processing the log data in the log package through the window also includes: When there are too many log packets, retain the log packets within the window; When the log packages are insufficient, the log packages are copied and filled to ensure that there are enough log packages in the window.

10. A fault diagnosis data labeling device, characterized in that: include: An acquisition module is used to acquire a work order processing record from a work order system, wherein the work order processing record includes: a log identification code used by a fault processing terminal to process the work order, and a fault label of a faulty component; The download module is used to download the corresponding log package from the log system according to the log identification code; A standardization module is used to standardize the log data in the log package to obtain standardized log data; The labeling module is used to label the standardized log data with the fault labels of the faulty components to obtain training samples for training the fault diagnosis model.

Images