Fault log processing method and device, program product and medium

Abstract

The invention discloses a fault log processing method and device, a program product and a medium, and relates to the technical field of computers. The method comprises the steps of obtaining different types of fault logs, and performing standardization processing on the fault logs to generate standardized logs; analyzing a log stream in the standardized log to determine a fault component, and recording state change details of the fault component to generate log details corresponding to the standardized log; dividing the standardized logs according to a preset division rule to generate different types of classified logs, and analyzing and processing the different types of classified logs to obtain respective corresponding target summarized data; and performing fault diagnosis based on the log details and the target summarized data. According to the technical scheme, the fault diagnosis model can focus on diagnosis rule development or algorithm training, complex data processing does not need to be paid attention to, and data decoupling of the diagnosis model is achieved.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a fault log processing method, device, program product and medium. Background Art

[0002] As the core IT (Internet Technology) infrastructure, the stability of the server will directly affect the IT service quality of the data center. Once a server fails, customers require rapid fault diagnosis, accurate problem location, and business recovery to ensure business continuity. The server diagnosis model can quickly analyze and locate faults in server logs in an automated manner, improving the operation and maintenance efficiency of the server, and is becoming more and more popular in data centers.

[0003] The current diagnostic model generally matches fault keywords or fault rules directly based on the original server logs, and dynamically maintains the keyword library or rules as needed. It generally evolves and changes continuously in the form of a log stream. This method can only obtain the current status of the server, and cannot perceive the relationship between the component itself and other factors. For diagnostic solutions for some segmented scenarios, such as hard disk fault diagnosis, specific types of logs will be matched with rules and diagnosed to locate problems related to hard disk components. However, there are many server fault logs, and the data structure and content of various types of logs are quite different. Directly matching rules and locating faults for various types of data through diagnostic models will result in positioning interference, etc.; and relying solely on the error analysis of a single log cannot cover the full amount of related data required for diagnosis.

[0004] Therefore, how to provide a solution to the above technical problems is a problem that those skilled in the art need to solve at present. Summary of the invention

[0005] In view of this, the purpose of the present invention is to provide a fault log processing method, device, program product and medium, which can analyze the log stream of the server and summarize and classify multiple types of server logs, so that the diagnosis model can focus on the diagnosis rules or algorithm training without paying attention to the complicated server log processing. The specific scheme is as follows:

[0006] In a first aspect, the present application discloses a fault log processing method, comprising:

[0007] Obtain different types of fault logs and perform standardization on the fault logs to generate standardized logs;

[0008] Analyze the log stream in the standardized log to determine the faulty component, and record the status change details of the faulty component to generate log details corresponding to the standardized log;

[0009] The standardized logs are divided according to the preset division rules to generate different types of classified logs, and the different types of classified logs are analyzed and processed respectively to obtain the corresponding target summary data;

[0010] Perform troubleshooting based on log details and target summary data.

[0011] Optionally, different types of fault logs are obtained and standardized to generate standardized logs, including:

[0012] Obtain different types of fault logs and perform fuzzy queries on the fault logs based on the log names to obtain multiple log categories;

[0013] The structure of the fault log in each log category is identified and parsed to obtain the corresponding target parameters, and each line of data in the log stream corresponding to the fault log is standardized based on the target parameters to generate a standardized log under each log category.

[0014] Optionally, the target parameters include static parameters and dynamic parameters; the static parameters include component type and component slot, and the dynamic parameters include occurrence time, fault keyword, fault level, problem status, and component information;

[0015] The log stream in the standardized log is analyzed to determine the faulty component, and the status change details of the faulty component are recorded to generate log details corresponding to the standardized log, including:

[0016] The fault keywords are used to match the log stream in the standardized log to determine the faulty component, and the status change details of the faulty component are recorded according to the problem status to generate log details corresponding to the standardized log.

[0017] Optionally, record the status change details of the faulty component to generate log details corresponding to the standardized log, including:

[0018] Obtaining the state change of the faulty component itself and the state change of other factors associated with the faulty component respectively; wherein the state change of other factors is the state change of factors having a contextual relationship with the faulty component in the fault log;

[0019] The state change of the fault component itself is combined with the state changes of other factors to generate a composite state change, and the state change details of the faulty component are determined according to the composite state change to obtain log details corresponding to the standardized log.

[0020] Optionally, the standardized logs are divided according to preset division rules to generate different types of classified logs, including:

[0021] According to the fault information recorded in the standardized log, the standardized log is divided into out-of-band general log, storage specialist log and computing specialist log; among them, the out-of-band general log contains the fault information of each component, the storage specialist log contains the fault information of each device used for storage, and the computing specialist log contains the fault information of each device used for computing.

[0022] Optionally, out-of-band general logs include device fault diagnosis logs, system event logs, sensor logs, and black box logs.

[0023] Optionally, the out-of-band general logs are analyzed and processed to obtain corresponding target summary data, including:

[0024] Feeding the device fault diagnosis log into the summary data to determine first out-of-band universal summary data;

[0025] Compare the system event log with the first out-of-band general summary data to receive a target system event log in the system event log, and obtain second out-of-band general summary data; wherein the target system event log is a system event log that does not have the same component slot and problem status information after comparison with the first out-of-band general summary data;

[0026] Compare the black box log with the second out-of-band general summary data to receive a target black box log in the black box log, and obtain third out-of-band general summary data; wherein the target black box log is a black box log that does not have information having the same component slot and problem status after comparison with the second out-of-band general summary data;

[0027] Compare the sensor log with the third out-of-band general summary data to receive a target sensor log in the sensor log, and obtain fourth out-of-band general summary data; wherein the target sensor log is a sensor log that does not have information having the same component slot and problem status after comparison with the third out-of-band general summary data;

[0028] The fourth out-of-band general summary data is state-corrected according to the current state of the component recorded in the sensor log to obtain target summary data corresponding to the out-of-band general log.

[0029] Optionally, the storage specialist logs include: independent redundant disk array logs and self-monitoring, analysis and reporting technology logs, physical drive information logs and first message logs; the first message log is a log that records message information of each device used for storage.

[0030] Optionally, the storage specialist logs are analyzed and processed to obtain corresponding target summary data, including:

[0031] Sending the physical drive information log to the summary data to determine the first storage specialist summary data;

[0032] Compare the independent redundant disk array log with the first storage specialist summary data to receive a target independent redundant disk array log in the independent redundant disk array log to obtain the second storage specialist summary data; wherein the target independent redundant disk array log is an independent redundant disk array log that does not have the same component slot and problem status information after comparison with the first storage specialist summary data;

[0033] Compare the first message log with the second storage specialist summary data to receive the target first message log in the first message log to obtain the third storage specialist summary data; wherein the target first message log is a first message log that does not have information having the same component slot and problem status after comparison with the second storage specialist summary data;

[0034] Compare the self-monitoring, analysis and reporting technology log with the third storage specialist summary data to receive a target self-monitoring, analysis and reporting technology log in the self-monitoring, analysis and reporting technology log to obtain the fourth storage specialist summary data; wherein the target self-monitoring, analysis and reporting technology log is a self-monitoring, analysis and reporting technology log that does not have the same component slot and problem status information after comparison with the third storage specialist summary data;

[0035] The fourth storage specialist summary data is state-corrected according to the current state of the component recorded in the self-monitoring, analysis and reporting technical log to obtain the target summary data corresponding to the storage specialist log.

[0036] Optionally, the computing specialist log includes: an internal error log, a maintenance log, a process analysis log, and a second message log; the second message log is a log that records message information of each device used for computing.

[0037] Optionally, the computing specialist logs are analyzed and processed to obtain corresponding target summary data, including:

[0038] Feeding the second message log into the summary data to determine the first computing specialty summary data;

[0039] Compare the process analysis log with the first computing specialty summary data to receive a target process analysis log in the process analysis log, and obtain the second computing specialty summary data; wherein the target process analysis log is a process analysis log that does not have the same component slot and problem status information after comparison with the first computing specialty summary data;

[0040] Compare the internal error log with the second computing specialist summary data to receive a target internal error log in the internal error log to obtain third computing specialist summary data; wherein the target internal error log is an internal error log that does not have the same component slot and problem status information after comparison with the second computing specialist summary data;

[0041] Compare the maintenance log with the third computing specialty summary data to receive a target maintenance log in the maintenance log, and obtain fourth computing specialty summary data; wherein the target maintenance log is a maintenance log that does not have the same component slot and problem status information after comparison with the third computing specialty summary data;

[0042] The fourth computing specialist summary data is state-corrected according to the current state of the component recorded in the maintenance log to obtain target summary data corresponding to the computing specialist log.

[0043] Optionally, perform fault diagnosis based on log details and target summary data, including:

[0044] The first diagnostic rule and the second diagnostic rule are obtained respectively, and the first diagnostic rule and the second diagnostic rule are combined to obtain a target decision rule; wherein the first diagnostic rule is a diagnostic rule obtained by combing and solidifying the rules of the existing fault diagnosis instance, and the second diagnostic rule is a diagnostic rule that matches the fault data with the rules through an artificial intelligence algorithm;

[0045] Based on the log details and target summary data, the target decision rules are used to perform fault diagnosis and output the root cause of the faulty component.

[0046] In a second aspect, the present application discloses an electronic device, comprising:

[0047] Memory for storing computer programs;

[0048] The processor is used to load and execute a computer program to implement the aforementioned fault log processing method.

[0049] In a third aspect, the present application discloses a computer program product, including a computer program / instruction, which implements the steps of the aforementioned fault log processing method when executed by a processor.

[0050] In a fourth aspect, the present application discloses a computer-readable storage medium for storing a computer program; wherein the computer program implements the aforementioned fault log processing method when executed by a processor.

[0051] The present application provides a fault log processing method, including: obtaining different types of fault logs, and standardizing the fault logs to generate standardized logs; analyzing the log stream in the standardized log to determine the faulty component, and recording the status change details of the faulty component to generate log details corresponding to the standardized log; dividing the standardized log according to preset division rules to generate different types of classified logs, and analyzing and processing the different types of classified logs respectively to obtain their respective corresponding target summary data; and performing fault diagnosis based on the log details and the target summary data.

[0052] The beneficial technical effects of the present application are: by incorporating as many different types of fault logs into the analysis as possible, a standardized log with a standard structure is first generated; then the standardized log is subjected to log stream analysis, which is not limited to the screening of log point fault keywords, and can identify the state of the faulty components in the log based on the continuous change characteristics of the log, and the generated log details accurately reflect the true state of the component; further, the standardized log is classified according to the preset division rules, and the target summary data corresponding to each different type of classified log is obtained, so each target summary data is not limited to a single type of fault log; finally, the generated log details and target summary data can be called by the diagnostic model for fault diagnosis, thereby realizing data decoupling of the diagnostic model. In this way, the fault diagnosis model can focus on diagnostic rule development or algorithm training without having to pay attention to complex data processing.

[0053] In addition, the present application provides a fault log processing device, a program product, and a medium, which correspond to the above-mentioned fault log processing method and have the same effect as above. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying creative work.

[0055] Figure 1 A flow chart of a fault log processing method disclosed in this application;

[0056] Figure 2 A fault diagnosis schematic diagram disclosed in this application;

[0057] Figure 3 A flowchart of the implementation details of a fault log processing disclosed in this application;

[0058] Figure 4 A schematic diagram of data flow in a fault log disclosed in the present application;

[0059] Figure 5 A schematic diagram of a fault analysis process disclosed in this application;

[0060] Figure 6 A schematic diagram of data flow in a fault log disclosed in the present application;

[0061] Figure 7 A schematic diagram of a fault analysis process disclosed in this application;

[0062] Figure 8 A schematic diagram of data flow in a fault log disclosed in the present application;

[0063] Fig. 9 A schematic diagram of a fault analysis process disclosed in this application;

[0064] Fig.10 A schematic diagram of a platform diagnosis disclosed in this application;

[0065] Fig.11 A schematic diagram of a fault log processing record disclosed in this application;

[0066] Fig.12 This is a schematic diagram of an out-of-band general log aggregation process disclosed in this application;

[0067] Fig.13 A schematic diagram of a storage specialist log aggregation process disclosed in this application;

[0068] Fig.14 A schematic diagram of a computing specialist log summary process disclosed in this application;

[0069] Fig.15 A schematic diagram of a summary log disclosed in this application;

[0070] Fig.16 This is a schematic diagram of an out-of-band general practice data aggregation and processing disclosed in this application;

[0071] Fig.17 This is a schematic diagram of the out-of-band general practice data after aggregation and processing disclosed in this application;

[0072] Fig.18 This is a schematic diagram of a storage specialist data before aggregation and processing disclosed in this application;

[0073] Fig.19 This is a schematic diagram of a storage specialist data summary and processing disclosed in this application;

[0074] Fig. 20 A schematic diagram of an overall fault log processing flow disclosed in this application;

[0075] Fig.21 This is a schematic diagram of the structure of a fault log processing device disclosed in this application;

[0076] Fig. 22 This is a structural diagram of an electronic device disclosed in this application. DETAILED DESCRIPTION

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

[0078] At present, the server diagnosis model generally matches fault keywords or fault rules directly based on the original server log, and dynamically maintains the keyword library or rules as needed. For example, the server SEL (System Event Log) as a general server log records most server component errors. At present, many diagnostic solutions are based on SEL logs for server rule matching and diagnosis. However, the server fault log generally evolves and changes in the form of a log stream, and the status of the server components, thresholds, etc. involved in it is also a continuous change process. Simply filtering the corresponding fault status or keywords of a certain component or threshold can only obtain the current status, and cannot perceive the relationship between the component itself and other factors.

[0079] For diagnostic solutions for some niche scenarios, such as hard disk fault diagnosis, specific types of logs, such as Smart (Self-Monitoring Analysis and Reporting Technology) logs and Raid (Redundant Array of Independent Disks) logs, will be matched with rules and diagnosed to locate hard disk component-related problems. However, there are many server fault logs, and the data structure and content of various logs vary greatly. How to mine fault parameters in various non-standard data is a difficult point. Because various logs are interrelated or independent of each other, and the relationship is relatively complex, directly matching rules and locating faults for various data through diagnostic models will result in positioning interference, etc.; and relying solely on the error analysis of a single log cannot cover the full amount of related data required for diagnosis.

[0080] To this end, the present application provides a fault log processing solution, which enables the diagnostic model to focus on diagnostic rules or algorithm training without having to pay attention to the complex server log processing by analyzing the server's log stream and aggregating and classifying multiple types of server logs.

[0081] The embodiment of the present invention discloses a fault log processing method, see Figure 1 As shown, the method includes:

[0082] Step S11: acquiring different types of fault logs, and performing standardization processing on the fault logs to generate standardized logs.

[0083] The causes of server failures are complex, and the logs recording errors are also of various types. The corresponding log data for fault analysis and location are not limited to a single type of I fault log, such as IPMI (Intelligent Platform Management Interface), SMART, etc. Therefore, in the embodiments of the present application, all server fault-related logs are included in the analysis as much as possible and converted into standardized error data.

[0084] Specifically, different types of fault logs are obtained, and fuzzy queries are performed on the fault logs according to the log names to obtain multiple log categories; structural identification and analysis are performed on the fault logs in each log category to obtain corresponding target parameters, and each line of data in the log stream corresponding to the fault log is standardized based on the target parameters to generate standardized logs under each log category.

[0085] In the embodiment of the present application, after obtaining different types of fault logs, the fault logs are searched and classified according to the log names. Taking the SEL log as an example, a fuzzy query is generally performed based on common naming methods such as sel.log, SEL.log, SEL_xx.log, etc. to match the SEL log. The logs required for server diagnosis such as IPMI logs and RAID logs are obtained in the same way.

[0086] It is understandable that the types of fault logs under the same log category are the same. If no valid log is matched during the query process, an error will be reported accordingly. After the query, the log structure is identified and parsed according to the log category to obtain the corresponding target parameters. Among them, the target parameters include static parameters and dynamic parameters; static parameters include component type and component slot, and dynamic parameters include occurrence time, fault keywords, fault level, problem status, and component information. Furthermore, according to the location and structure of key information such as target parameters, each line of data in the log stream is standardized to obtain standardized logs under different log categories.

[0087] Step S12: Analyze the log stream in the standardized log to determine the faulty component, and record the status change details of the faulty component to generate log details corresponding to the standardized log.

[0088] In the embodiment of the present application, since the corresponding target parameters are obtained in the process of standardizing the fault log, the fault keywords can be used to match the log stream in the standardized log to determine the faulty component.

[0089] Furthermore, the server's fault logs, such as SEL, RAID and other logs, are generally recorded continuously in the form of log streams, and the corresponding component's own status and other factors also change continuously in a time-increasing manner. Therefore, in an embodiment of the present application, the problem status of the faulty component is recorded. Specifically, the status change details of the faulty component are recorded according to the problem status to generate log details corresponding to the standardized log. It can be seen that the present invention is not limited to the keyword screening of point-like faults in logs, but performs stream analysis on the log based on the continuous change characteristics of the log, identifies the continuous changes in the component's own status in the log and the association and influence of other factors on the component status, and accurately reflects the true status of the component.

[0090] Step S13: dividing the standardized logs according to preset division rules to generate different types of classified logs, and analyzing and processing the different types of classified logs respectively to obtain the corresponding target summary data.

[0091] After standardizing various logs and analyzing the log stream, there is another problem: multiple logs may record the fault point, and the fault data recorded in different logs, such as slots and states, are different. If direct diagnosis is not distinguished, it will lead to problems such as duplicate data diagnosis. In order for the subsequent diagnosis model to make a correct diagnosis, the logs need to be integrated, deduplicated, and classified.

[0092] In this process, the standardized logs obtained after processing different types of fault logs are divided to generate different types of classified logs. Then, each type of classified log is analyzed and processed to remove duplicate data and obtain the final summary data.

[0093] In a specific implementation, different types of classified logs are generated, including out-of-band general logs, storage specialist logs, and computing specialist logs; wherein, the characteristic of the out-of-band general log is that it contains fault information of each component, and the error report is usually simple and direct, which is suitable for direct judgment of simple faults; the characteristic of the storage specialist log is that it contains fault information of each device used for storage (such as RAID card, hard disk, etc.), which can be used to judge complex problems such as multiple hard disks and links, as well as pre-inspection of potential faults; the characteristic of the computing specialist log is that it contains fault information of complex problems of each device used for computing (such as CPU, memory, PCIE, etc.), which can be used to judge difficult problems of CPU and memory components.

[0094] Step S14: Perform fault diagnosis based on the log details and target summary data.

[0095] Finally, fault diagnosis is performed based on the log details and target summary data, and the root cause of the fault is output. It is understandable that by analyzing the log stream of the server and parsing out the log details of the continuous changes and multi-dimensional states of the components, accurate data can be provided for the diagnostic model to accurately determine the fault. After aggregating and classifying the various logs of the server to form standardized target summary data, since they all record the corresponding log details, when performing fault diagnosis, accurate and highly available classification data can be used for the diagnostic model to call, allowing the diagnostic model or algorithm model to focus on the diagnostic rules or algorithm training without having to pay attention to the complex server log data processing, thereby achieving data decoupling of the diagnostic model.

[0096] Specifically, when using the fault model for fault diagnosis: respectively obtain the first diagnostic rule and the second diagnostic rule, and combine the first diagnostic rule and the second diagnostic rule to obtain the target decision rule; based on the log details and the target summary data, use the target decision rule to perform fault diagnosis, and output the root cause of the fault of the faulty component.

[0097] Among them, the first diagnostic rule is the diagnostic rule obtained by combing and solidifying the rules of existing fault diagnosis instances. It has large-scale and systematic analysis capabilities. Generally, the higher the quality of the data given, the more accurate the analysis conclusion; the second diagnostic rule is the diagnostic rule that matches the fault data with rules through artificial intelligence (AI) algorithms. It usually involves feature engineering (word vector conversion word2vector, missing value equalization processing), model training (Xgboost model), and the use of standardized classification data for training and prediction. Compared with the first diagnostic rule, the algorithm diagnosis corresponding to the second diagnostic rule has higher requirements for data quality. The more accurate the data, the more accurate the training and prediction effects.

[0098] Furthermore, the first diagnostic rule and the second diagnostic rule are summarized to form a target decision rule, and then the target summary data with attached log details is analyzed using the target decision rule to output the root cause, thereby realizing intelligent decision-making for fault diagnosis.

[0099] like Figure 2 The figure shows an exemplary method of using a diagnostic model to perform fault diagnosis to output the root cause of the fault. Among them, expert rule diagnosis corresponds to the first diagnostic rule, and AI algorithm diagnosis corresponds to the second diagnostic rule. Expert rule diagnosis sorts out and solidifies typical diagnostic examples based on experience, and AI algorithm diagnosis trains the algorithm model based on massive training data. By summarizing the results of expert rule diagnosis and AI algorithm diagnosis, the out-of-band general data obtained by classification, the stored specialist data, and the specialist data are calculated and the root cause is output. Since how to use the diagnostic model is not within the patent point of the present invention, it is mainly to complete the process. Therefore, the more detailed processing process can refer to the processing process of the existing diagnostic model, and the present invention will not repeat it.

[0100] The present application provides a fault log processing method, including: obtaining different types of fault logs, and standardizing the fault logs to generate standardized logs; analyzing the log stream in the standardized log to determine the faulty component, and recording the status change details of the faulty component to generate log details corresponding to the standardized log; dividing the standardized log according to preset division rules to generate different types of classified logs, and analyzing and processing the different types of classified logs respectively to obtain their respective corresponding target summary data; and performing fault diagnosis based on the log details and the target summary data.

[0101] The beneficial technical effects of the present application are: by incorporating as many different types of fault logs into the analysis as possible, a standardized log with a standard structure is first generated; then the standardized log is subjected to log stream analysis, which is not limited to the screening of log point fault keywords, and can identify the state of the faulty components in the log based on the continuous change characteristics of the log, and the generated log details accurately reflect the true state of the component; further, the standardized log is classified according to the preset division rules, and the target summary data corresponding to each different type of classified log is obtained, so each target summary data is not limited to a single type of fault log; finally, the generated log details and target summary data can be called by the diagnostic model for fault diagnosis, thereby realizing data decoupling of the diagnostic model. In this way, the fault diagnosis model can focus on diagnostic rule development or algorithm training without having to pay attention to complex data processing.

[0102] Based on the above embodiment, this embodiment will specifically explain S12 in the above embodiment. The server fault logs such as SEL, RAID and other logs are generally recorded continuously in the form of log streams, and the corresponding component status and other factors also change continuously in a time-increasing manner. Therefore, the process of recording the status change details of the faulty component to generate log details corresponding to the standardized log may include the following steps:

[0103] Obtaining the state change of the faulty component itself and the state change of other factors associated with the faulty component respectively; wherein the state change of other factors is the state change of factors having a contextual relationship with the faulty component in the fault log;

[0104] The state change of the fault component itself is combined with the state changes of other factors to generate a composite state change, and the state change details of the faulty component are determined according to the composite state change to obtain log details corresponding to the standardized log.

[0105] In the embodiment of the present application, when a fault is triggered, the target parameters are initialized. According to the above content, the target parameters include static parameters and dynamic parameters. The status change details of the faulty component are recorded, and the core point is the problem status change.

[0106] In a specific implementation, regarding the record of the component's own state changes: illustratively, common single-point or multi-point states include: Issue Assert, indicating that a problem has occurred; Issue Deassert, indicating that the problem has been resolved; Present Assert, indicating that a component has been inserted; Present Deassert, indicating that a component has been unplugged; Issue Assert>IssueDeassert, indicating that a problem has occurred and resolved itself; Present Assert>Issue Deassert, indicating the plugging and unplugging of a component.

[0107] By combining the above state changes, the current state can be determined. Exemplarily, the current state may include:

[0108] (1) Problem insertion: Only the problem is inserted, indicating that there is a problem at the moment;

[0109] (2) Problem self-repair: There is a problem and it is self-repaired. This scenario can be ignored in the inspection scenario.

[0110] (3) Problem manually repaired: There is a problem and it has been manually repaired. This status helps the subsequent diagnosis module to determine whether there are multiple components or noise.

[0111] (4) Unstable problem: The unstable state helps the diagnostic module to determine difficult problems such as hard disk links;

[0112] (5) Fault Recurrence: After the problem is manually repaired and occurs again, this problem helps the diagnostic module to determine problems such as CPU problems and hard disk links.

[0113] Fault points are generally not isolated or point-like, but have a contextual relationship, so in addition to the state change of the component itself, the context will also be considered. Therefore, in another specific implementation, regarding the state change records of other factors of the component, the server log focuses on whether there are factors of automatic intervention and human intervention. Automatic intervention: usually manifested in that the system repairs the problem through self-intervention, such as OS (Operating System, operating system) restart, BMC (Baseboard Management Controller, baseboard management controller) restart, etc. Human intervention: usually manifested in that the problem is repaired with the help of human intervention, generally determined by a combination of composite states, typically several state change combinations. The following are several exemplary state changes of human intervention:

[0114] (1) System shutdown > BMC restart > system startup, which generally means that the server has been powered off and on manually. This state is mostly applicable to memory, CPU, network card, etc. that require power-off operations;

[0115] (2) System shutdown > chassis cover open > chassis cover closed > system startup. This generally means that the server is turned on and off without powering off. This state is mostly applicable to operations such as hard disks that do not require powering off.

[0116] (3) System powered on > Chassis cover opened > Chassis cover closed > System powered on. This generally means that the fault point is visually checked and confirmed. This state is generally applicable to the replacement of special components such as fans.

[0117] Finally, the component's own changes and other factors are combined to form a complete and composite component state change, which can truly reflect the actual state change of the component. The following are several composite state changes provided as examples:

[0118] (1) Component-induced downtime: Problem insertion > Automatic intervention > Problem resolution, indicating that the problem is corrected by restarting the system. This problem affects the business and needs to be repaired.

[0119] (2) Component manual repair: Problem insertion > Human intervention > Problem resolution, indicating that the problem was corrected through manual repair, and generally the problem was solved;

[0120] (3) Component problem reproduction: Problem insertion > Human intervention > Problem resolution > Problem occurrence, indicating that the error was fixed through human intervention. This generally indicates that the human judgment was wrong. This problem often manifests as a difficult and complex problem that has caused multiple visits and requires special attention.

[0121] The state change details of the faulty component are determined according to the composite state change to obtain the log details corresponding to the standardized log. That is, the log details record the change details of the component itself and other factors. It can be understood that the state change of the component itself can include problem insertion, problem resolution, in-place insertion, in-place resolution, etc.; other factor changes can include server restart, power on, power off, chassis opening, model shutdown, BMC restart, BMC version change, etc.

[0122] It can be seen that this embodiment is not limited to the keyword screening of log point faults, but needs to perform flow analysis on the log based on the continuous change characteristics of the log, identify the continuous change of the component's own state in the log and the association and influence of other factors on the component state, and accurately reflect the real state of the component.

[0123] like Figure 3 Shown is an overall implementation detail flowchart provided exemplarily according to the above embodiment. For the fault diagnosis model, a log stream analysis and processing module and a data classification module are added. The log stream analysis and processing module performs log stream analysis on the server log, and summarizes and standardizes more than a dozen server-related fault logs, and then classifies them through the data classification module to form accurate and standardized classified summary data. Let the fault diagnosis model or AI algorithm model focus on diagnostic rule development or algorithm training without paying attention to complex data processing. For more specific processing procedures, please refer to the corresponding content disclosed in the aforementioned embodiments, which will not be repeated here.

[0124] Exemplarily, the following three log implementation cases are used to illustrate the component's own status change, and other factors such as server power on and off, chassis startup and merging to assist in determining the component status change.

[0125] like Figure 4 The following is a data flow diagram of a fault log that determines the status of a component through its own status change. The specific processing process is as follows:

[0126] 1. According to the fault keyword matching, it is found that the hard disk slot front Mylar 0 has a fault at 2024-09-25 04:25:24 (keyword Front DISK0 Hard Disk Drive Detected Fault Assert), and the status of DISK0 is initialized to fault;

[0127] 2. The status of hard disk DISK0 changed. DISK0 was unplugged at 2024-10-10 20:48:06 (keyword FrontDISK0 Hard Disk Drive Presence Deassert);

[0128] 3. The status of hard disk DISK0 changes. DISK0 is reinserted at 2024-10-10 20:49:42 (keyword FrontDISK0 Hard Disk Drive Presence Assert);

[0129] 4. The status of hard disk DISK0 changed. The problem of DISK0 at 2024-10-10 20:49:58 was fixed (keyword FrontDISK0 Hard Disk Drive Detected Fault Deassert);

[0130] In summary, the DISK0 status has changed 4 times, from hard disk failure > hard disk unplugged > hard disk plugged in > hard disk normal. Based on this status change, it can be concluded that although hard disk 0 has failed, it has been repaired and is currently in normal status. The process of analyzing this component log is as follows: Figure 5 shown.

[0131] like Figure 6 The following is a data flow diagram of another fault log that determines the status of a component by changing its own status. The specific processing process is as follows:

[0132] 1. According to the fault keyword matching, it is checked that DISK5 has a fault at 2023-04-22 10:39:04 (keyword Front DISK5 Hard Disk Drive Detected Fault Assert), and the status of DISK5 is initialized to fault;

[0133] 2. The status of hard disk DISK5 changed. DISK5 was unplugged at 2024-04-23 11:36:13 (keyword FrontDISK5 Hard Disk Drive Presence Deassert);

[0134] 3. The status of hard disk DISK5 changed. DISK5 was reinserted at 2024-04-23 11:38:42 (keyword FrontDISK5 Hard Disk Drive Presence Assert);

[0135] 4. The status of hard disk DISK5 changed. The problem of DISK5 was fixed at 2024-04-23 11:39:04 (keyword FrontDISK5 Hard Disk Drive Detected Fault Deassert);

[0136] 5. The status of hard disk DISK5 changed. DISK5 had a fault at 2024-10-21 07:17:55 (keyword FrontDISK5 Hard Disk Drive Detected Fault Assert);

[0137] In summary, the status bit of DISK5 records 5 status transitions: hard disk failure > hard disk unplugged > hard disk plugged in > hard disk normal > problem recurrence. Based on this status transition, it can be concluded that hard disk 5 has a problem recurrence, not a simple failure. This type of problem usually means a complex problem with multiple on-site work orders and requires special attention. The process of analyzing the log for this component is as follows: Figure 7 As shown. It can be seen that before the present invention is used, only the hard disk DISK5 fault can be diagnosed for this log. However, after the present invention is used, the hard disk DISK5 fault can be identified and the fault can be restored after repair. The restored state of the hard disk here is of great help in analyzing the hard disk problem.

[0138] like Figure 8 The figure shows a data flow diagram in a fault log that determines the status of a component through changes in its own status and other factors. The specific processing process is:

[0139] 1. According to the fault keyword matching, it is checked that the memory slot CPU0_C3D0 has a fault at 2024-10-27 10:26:53 (CPU0_C3D0 Uncorrectable ECC Assert), and the memory CPU0_C3D0 status is initialized to fault;

[0140] 2. Other related status changes: the operating system was shut down at 2024-10-27 13:18:55 (keyword: OSGraceful Shutdown);

[0141] 3. The memory CPU0_C3D status changed. The memory CPU0_C3D0 fault was resolved at 2024-10-27 13:18:56 (keyword CPU0_C3D0 Uncorrectable ECC Deassert);

[0142] 4. Other related status changes: the server was shut down (ACPI_PWRoff) at 2024-10-31 13:18:58;

[0143] In summary, the status of memory CPU0_C3D0 is recorded as fault occurrence > system downtime > memory fault resolution > server shutdown. The process of analyzing the log of this component is as follows: Fig. 9 It is worth noting that the memory fault correction and system shutdown occur at the same time (2 seconds apart). With this factor, the current state of the memory is a fault and causes a downtime, rather than a fault correction.

[0144] like Fig.10 The figure shows an exemplary diagnosis screenshot generated after the present invention is applied to the diagnosis model and the diagnosis model is applied to various operation and maintenance platforms or service tools. Fig.11 The following is a schematic diagram of the log sources corresponding to the diagnosis results.

[0145] Based on the above embodiment, this embodiment will specifically explain S13 in the above embodiment. Among them, when the classified log obtained by division is an out-of-band general log, in a first specific implementation, the out-of-band general log may include a device fault diagnosis log, a system event log, a sensor log, and a black box log. The process of analyzing and processing the out-of-band general log to obtain the corresponding target summary data may include the following steps:

[0146] Step 1: Send the device fault diagnosis log to the summary data to determine the first out-of-band general summary data;

[0147] Step 2: Compare the system event log with the first out-of-band general summary data to receive a target system event log in the system event log and obtain second out-of-band general summary data; wherein the target system event log is a system event log that does not have the same component slot and problem status information after comparison with the first out-of-band general summary data;

[0148] Step 3: Compare the black box log with the second out-of-band general summary data to receive the target black box log in the black box log and obtain the third out-of-band general summary data; wherein the target black box log is a black box log that does not have the same component slot and problem status information after comparison with the second out-of-band general summary data;

[0149] Step 4: Compare the sensor log with the third out-of-band general summary data to receive the target sensor log in the sensor log, and obtain the fourth out-of-band general summary data; wherein the target sensor log is a sensor log that does not have the same component slot and problem status information after comparison with the third out-of-band general summary data;

[0150] Step 5: Perform state correction on the fourth out-of-band general summary data according to the current state of the component recorded in the sensor log to obtain target summary data corresponding to the out-of-band general log.

[0151] It should be noted that, in a specific implementation, the device fault diagnosis log may be an IDL log. The IDL log is a server diagnostic log specific to a certain type of server. This log records the event history based on the IPMI sensor and corresponds to the system event log (SEL) to provide more comprehensive information. Each log contains processing suggestions and operation steps. Users can access these logs through the BMC Web interface and download or clear them as needed. The system event log (SEL) records server hardware status, errors, and alarm events, including hardware failures, system startup and shutdown, sensor status, etc. It is very important for server fault diagnosis and maintenance. The sensor log (Sensor) records the real-time data of the internal sensors of the server, such as temperature, voltage, etc., which is used to monitor the health status and performance of the server. The black box log (Blackbox) records the operation information of the server in the case of power failure, including power status, system configuration, etc., which helps to analyze the cause of the problem when restoring the system after power failure.

[0152] The following will be combined Fig.12 The above embodiment is described in detail. Traverse the standardized log. First, send the standardized data after parsing the equipment fault diagnosis log into the summary data; then check the SEL log standardized data. If the slot or the type in the same state is not included in the summary data, then receive and add this data to the summary data, otherwise discard this data; then check the Blackbox log standardized data. If the slot or the type in the same state is not included in the summary data, then receive and add this data to the summary data, otherwise discard this data and then check; then check the sensor log standardized data. If the slot or the type in the same state is not included in the summary data, then receive and add this data to the summary data, otherwise discard this data and then check. It can be understood that since the component recorded in the sensor log is the current state, the summary data is corrected accordingly according to the current state of this component in the sensor log.

[0153] In a second specific implementation, when the classified logs obtained by division are storage specialist logs, the storage specialist logs may include independent redundant disk array logs, self-monitoring, analysis and reporting technology logs, physical drive information logs and first message logs; the first message log is a log recording message information of each device used for storage. The process of analyzing and processing the storage specialist logs to obtain the corresponding target summary data may include the following steps:

[0154] Step 1: Send the physical drive information log to the summary data to determine the first storage specialist summary data;

[0155] Step 2: Compare the independent redundant disk array log with the first storage specialist summary data to receive a target independent redundant disk array log in the independent redundant disk array log to obtain the second storage specialist summary data; wherein the target independent redundant disk array log is an independent redundant disk array log that does not have the same component slot and problem status information after comparison with the first storage specialist summary data;

[0156] Step 3: Compare the first message log with the second storage specialist summary data to receive the target first message log in the first message log to obtain the third storage specialist summary data; wherein the target first message log is a first message log that does not have information having the same component slot and problem status after comparison with the second storage specialist summary data;

[0157] Step 4: Compare the self-monitoring, analysis and reporting technology log with the third storage specialist summary data to receive the target self-monitoring, analysis and reporting technology log in the self-monitoring, analysis and reporting technology log to obtain the fourth storage specialist summary data; wherein the target self-monitoring, analysis and reporting technology log is a self-monitoring, analysis and reporting technology log that does not have the same component slot and problem status information after comparison with the third storage specialist summary data;

[0158] Step 5: Perform state correction on the fourth storage specialist summary data according to the current state of the component recorded in the self-monitoring, analysis and reporting technical log to obtain the target summary data corresponding to the storage specialist log.

[0159] It should be noted that the independent redundant disk array log (RAID) records data changes, events and operations in the RAID system, such as data writing, modification, deletion and other operations, to ensure data consistency and integrity. The self-monitoring, analysis and reporting technology log (SMART) records the health status information of the device, including key warning information such as available space, temperature threshold, reliability degradation, read-only status and volatile memory device failure. The SMART log also records data read and write operations and host commands, which helps to analyze the operating status and potential failures of the device. The physical drive information log (Physical Drive Information, PdInfo) provides detailed information about physical devices (such as hard disks), including the version of the hard disk, RAID group and hard disk information. These logs are usually used to help administrators diagnose hardware failures or optimize storage configurations. The first message log (Message log) usually records various messages in the system. The first message log of this embodiment is mainly a log about the RAID card and hard disk error part.

[0160] The following will be combined Fig.13 The above embodiment is described in detail. Traverse the standardized log. First, send the standardized data after the PdInfo log is parsed into the summary data; then check the RAID log standardized data. If the slot or the type in the same state is not included in the summary data, then receive and add this data to the summary data, otherwise discard this data; then check the Message log standardized data. If the slot or the type in the same state is not included in the summary data, then receive and add this data to the summary data, otherwise discard this data and then check; then check the Smart log standardized data. If the slot or the type in the same state is not included in the summary data, then receive and add this data to the summary data, otherwise discard this data and then check. It can be understood that since the component recorded by Smart is the current state, the summary data is corrected accordingly according to the current state of this component in the Smart log.

[0161] In a third specific implementation, when the classified log obtained by division is a computing specialist log, the computing specialist log may include an internal error log, a maintenance log, a process analysis log, and a second message log; the second message log is a log recording message information of each device used for computing. The process of analyzing and processing the computing specialist log to obtain the corresponding target summary data may include the following steps:

[0162] Step 1: feeding the second message log into the summary data to determine the first computing specialty summary data;

[0163] Step 2: Compare the process analysis log with the first computing specialty summary data to receive the target process analysis log in the process analysis log and obtain the second computing specialty summary data; wherein the target process analysis log is a process analysis log that does not have the same component slot and problem status information after comparison with the first computing specialty summary data;

[0164] Step 3: Compare the internal error log with the second computing specialist summary data to receive the target internal error log in the internal error log and obtain the third computing specialist summary data; wherein the target internal error log is an internal error log that does not have the same component slot and problem status information after comparison with the second computing specialist summary data;

[0165] Step 4: Compare the maintenance log with the third computing specialty summary data to receive the target maintenance log in the maintenance log and obtain the fourth computing specialty summary data; wherein the target maintenance log is a maintenance log that does not have the same component slot and problem status information after comparison with the third computing specialty summary data;

[0166] Step 5: Perform state correction on the fourth computing specialist summary data according to the current state of the component recorded in the maintenance log to obtain the target summary data corresponding to the computing specialist log.

[0167] It should be pointed out that the internal error log (Internal Error, IERR) records the error information that occurs during the operation of the system. This type of log is mainly used for troubleshooting and repair, helping system administrators identify and solve problems in operation. The maintenance log (Maintenance) is mainly used to record operations and events related to system maintenance, and may also include information such as the maintenance plan, execution status, and start and end time of the equipment. The process analysis log (AnalyProcess) usually refers to a log that records process activities, such as user login, application running, system service startup, etc. This type of log helps to monitor and analyze the operating status of the system. The second message log (Message log) usually records various messages in the system. The second message log of this embodiment is mainly a log related to the CPU, memory, and PCIE error report part.

[0168] The following will be combined Fig.14 The above embodiment is described in detail. Traverse the standardized log. First, send the standardized data after parsing the second message log into the summary data; then check the standardized data of the AnalyProcess log. If the slot or the type in the same state is not included in the summary data, then receive and add this data to the summary data, otherwise discard this data; then check the standardized data of the IERR log. If the slot or the type in the same state is not included in the summary data, then receive and add this data to the summary data, otherwise discard this data and then check; then check the standardized data of the Maintenance log. If the slot or the type in the same state is not included in the summary data, then receive and add this data to the summary data, otherwise discard this data and then check. It can be understood that since the component recorded in the Maintenance log is the current state, the summary data is corrected accordingly according to the current state of this component in the Maintenance log.

[0169] The following is an example of how to classify logs. Fig.15 As shown in the figure, the sample includes four types of standardized logs: IDL, SEL, PdInfo, and RAID. Fig.15 When generating corresponding summary data from out-of-band common data in Fig.16The processing process is as follows: the memory CPU0_C0D0 data of IDL is recorded; the memory CPU0_C0D0 data of SEL is discarded; the hard disk DISK32 data of SEL is recorded; the hard disk DISK32 data of SDR is discarded, but the DISK32 status will be corrected to the current problem. The final processed data is as follows Fig.17 As shown. Fig.15 When generating corresponding summary data from the stored specialist data, the processing Fig.18 The processing process is as follows: the hard disk slot 8 data of PdInfo is recorded; the hard disk slot 8 of the Raid card is discarded. The final processed data is as follows Fig.19 shown.

[0170] It can be seen that before using the present invention, sending multiple problems to the diagnostic model will cause the diagnostic model to mistakenly think that there are multiple hard disk and multiple memory problems, causing diagnostic confusion. After using the present invention, through classification and filtering, the diagnostic model can clearly determine that the DISK32 single hard disk is faulty.

[0171] It is worth noting that the above-mentioned processing procedures for out-of-band general logs, storage specialist logs, and computing specialist logs are described in a sequential processing manner. Similarly, parallel processing and multi-threading technology can also be used to process the fault logs of the current classification to further improve the efficiency of log processing. In the process of parallel processing, fault switching and load balancing functions can be provided to achieve parallel logging between multiple processors, thereby improving the processing speed. In addition, in a feasible implementation method, incomplete or erroneous log data can also be processed through automatic recovery and cleanup strategies in parallel job scheduling. For example, a monitoring and debugging tool can be developed to perform troubleshooting and performance optimization based on monitoring indicators. The data cleanup strategy can remove the impact of abnormal behavior and avoid abnormal data from polluting the log quality.

[0172] like Fig. 20The figure shows a schematic diagram of an overall implementation process provided in combination with the above-mentioned embodiments. After the logs are collected, the logs are integrated, decompressed and classified to obtain different log classifications (such as out-of-band structured data such as equipment fault diagnosis and system event logs; out-of-band unstructured data such as black boxes and registers; in-band structured data such as GPUs and RAIDs; and in-band unstructured data such as Messages and Smarts). Through fuzzy query, see if the log of the current log type can be matched. If no valid data is matched, remind and record it. After the fault log is standardized, the abnormal change flow of the component status is recorded for the problem status of the dynamic parameters in the target parameters. Among them, the more specific working process of the problem status change can refer to the corresponding content disclosed in the above-mentioned embodiments, which will not be repeated here. Next, the standardized data is integrated, deduplicated and classified to obtain out-of-band general data, computing specialist data, storage specialist data, power supply specialist data, GPU specialist data, etc. Finally, a fault decision is made based on the summary data obtained after classification to find out the root cause of the fault.

[0173] Correspondingly, the present application also discloses a fault log processing device, see Fig.21 As shown, the device comprises:

[0174] The standardization processing module 11 is used to obtain different types of fault logs and perform standardization processing on the fault logs to generate standardized logs;

[0175] A stream analysis module 12 is used to analyze the log stream in the standardized log to determine the faulty component, and record the status change details of the faulty component to generate log details corresponding to the standardized log;

[0176] The data classification module 13 is used to divide the standardized log according to the preset division rules to generate different types of classified logs, and analyze and process the different types of classified logs respectively to obtain the corresponding target summary data;

[0177] The fault diagnosis module 14 is used to perform fault diagnosis based on the log details and target summary data.

[0178] Among them, for more specific working processes of the above-mentioned modules, please refer to the corresponding contents disclosed in the aforementioned embodiments, which will not be repeated here.

[0179] It can be seen that the above scheme of this embodiment includes: obtaining different types of fault logs, and standardizing the fault logs to generate standardized logs; analyzing the log stream in the standardized log to determine the faulty component, and recording the status change details of the faulty component to generate log details corresponding to the standardized log; dividing the standardized log according to preset division rules to generate different types of classified logs, and analyzing and processing the different types of classified logs respectively to obtain their corresponding target summary data; and performing fault diagnosis based on the log details and the target summary data.

[0180] The beneficial technical effects of the present application are: by incorporating as many different types of fault logs into the analysis as possible, a standardized log with a standard structure is first generated; then the standardized log is subjected to log stream analysis, which is not limited to the screening of log point fault keywords, and can identify the state of the faulty components in the log based on the continuous change characteristics of the log, and the generated log details accurately reflect the true state of the component; further, the standardized log is classified according to the preset division rules, and the target summary data corresponding to each different type of classified log is obtained, so each target summary data is not limited to a single type of fault log; finally, the generated log details and target summary data can be called by the diagnostic model for fault diagnosis, thereby realizing data decoupling of the diagnostic model. In this way, the fault diagnosis model can focus on diagnostic rule development or algorithm training without having to pay attention to complex data processing.

[0181] Furthermore, the present application also discloses an electronic device. Fig. 22 This is a structural diagram of an electronic device 20 according to an exemplary embodiment, and the content in the diagram cannot be considered as any limitation on the scope of use of the present application.

[0182] Fig. 22 A schematic diagram of the structure of an electronic device 20 provided in an embodiment of the present application. The electronic device 20 may specifically include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 is used to store a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the fault log processing method disclosed in any of the aforementioned embodiments. In addition, the electronic device 20 in this embodiment may specifically be a server.

[0183] In this embodiment, the power supply 23 is used to provide working voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and the external device, and the communication protocol it follows is any communication protocol that can be applied to the technical solution of the present application, and is not specifically limited here; the input and output interface 25 is used to obtain external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs and is not specifically limited here.

[0184] In addition, the memory 22 as a carrier for resource storage may be a read-only memory, a random access memory, a disk or an optical disk, etc. The resources stored thereon may include an operating system 221, a computer program 222 and data 223, etc. The data 223 may include various data. The storage method may be temporary storage or permanent storage.

[0185] The operating system 221 is used to manage and control the hardware devices and computer program 222 on the electronic device 20, which can be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program that can be used to complete the fault log processing method performed by the electronic device 20 disclosed in any of the aforementioned embodiments, the computer program 222 can further include a computer program that can be used to complete other specific tasks.

[0186] Furthermore, the embodiment of the present application also discloses a computer-readable storage medium, wherein the computer-readable storage medium mentioned here includes a random access memory (Random Access Memory, RAM), a memory, a read-only memory (Read-Only Memory, ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a magnetic disk or an optical disk, or any other form of storage medium known in the technical field. Among them, when the computer program is executed by the processor, the aforementioned fault log processing method is implemented. For the specific steps of the method, reference can be made to the corresponding contents disclosed in the aforementioned embodiments, which will not be repeated here.

[0187] Furthermore, an embodiment of the present application also provides a computer program product, including a computer program / instruction, which implements any one of the above-mentioned fault log processing methods when executed by a processor.

[0188] In this specification, each embodiment is described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part.

[0189] The steps of the fault log processing method or algorithm described in the embodiments disclosed herein can be directly implemented by hardware, a software module executed by a processor, or a combination of the two. The software module can be placed in a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the technical field.

[0190] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the presence of other identical elements in the process, method, article or device including the elements.

[0191] The above is a detailed introduction to a fault log processing method, device, program product and 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 log processing method, characterized in that: include: Acquire different types of fault logs, and perform standardization processing on the fault logs to generate standardized logs; Analyze the log stream in the standardized log to determine the faulty component, and record the status change details of the faulty component to generate log details corresponding to the standardized log; Dividing the standardized log according to a preset division rule to generate different types of classified logs, and analyzing and processing the different types of classified logs respectively to obtain corresponding target summary data; Fault diagnosis is performed based on the log details and the target summary data.

2. The fault log processing method according to claim 1, characterized in that: The acquiring of different types of fault logs and performing standardization processing on the fault logs to generate standardized logs includes: Obtaining different types of fault logs, and performing fuzzy query on the fault logs according to the log names to obtain multiple log categories; Structural identification and parsing are performed on the fault logs in each of the log categories to obtain corresponding target parameters, and each line of data in the log stream corresponding to the fault log is standardized based on the target parameters to generate a standardized log under each of the log categories.

3. The fault log processing method according to claim 2, characterized in that: The target parameters include static parameters and dynamic parameters; the static parameters include component type and component slot, and the dynamic parameters include occurrence time, fault keywords, fault level, problem status, and component information; The step of analyzing the log stream in the standardized log to determine the faulty component and recording the status change details of the faulty component to generate log details corresponding to the standardized log includes: The fault keyword is used to perform matching in the log stream in the standardized log to determine the faulty component, and the status change details of the faulty component are recorded according to the problem status to generate log details corresponding to the standardized log.

4. The fault log processing method according to claim 1, characterized in that: The recording of the status change details of the faulty component to generate log details corresponding to the standardized log includes: Respectively obtaining the state change of the faulty component itself and the state change of other factors associated with the faulty component; wherein the state change of other factors is the state change of factors having a contextual relationship with the faulty component in the fault log; The self-state change is combined with the state changes of other factors to generate a composite state change, and the state change details of the faulty component are determined according to the composite state change to obtain log details corresponding to the standardized log.

5. The fault log processing method according to claim 1, characterized in that: The step of dividing the standardized log according to a preset division rule to generate different types of classified logs includes: According to the fault information recorded in the standardized log, the standardized log is divided into an out-of-band general log, a storage specialist log and a computing specialist log; wherein the out-of-band general log contains the fault information of each component, the storage specialist log contains the fault information of each device used for storage, and the computing specialist log contains the fault information of each device used for computing.

6. The fault log processing method according to claim 5, characterized in that: The out-of-band general logs include device fault diagnosis logs, system event logs, sensor logs, and black box logs.

7. The fault log processing method according to claim 6, characterized in that: The out-of-band general log is analyzed and processed to obtain corresponding target summary data, including: Feeding the device fault diagnosis log into summary data to determine first out-of-band general summary data; Compare the system event log with the first out-of-band general summary data to receive a target system event log in the system event log and obtain second out-of-band general summary data; wherein the target system event log is a system event log that does not have the same component slot and problem status information after comparison with the first out-of-band general summary data; Comparing the black box log with the second out-of-band general summary data to receive a target black box log in the black box log, and obtaining third out-of-band general summary data; wherein the target black box log is a black box log that does not have the same component slot and problem status information after comparison with the second out-of-band general summary data; Comparing the sensor log with the third out-of-band general summary data to receive a target sensor log in the sensor log, and obtaining fourth out-of-band general summary data; wherein the target sensor log is a sensor log that does not have the same component slot and problem status information after comparison with the third out-of-band general summary data; The fourth out-of-band general summary data is state-corrected according to the current state of the component recorded in the sensor log to obtain target summary data corresponding to the out-of-band general log.

8. The fault log processing method according to claim 5, characterized in that: The storage specialist logs include: independent redundant disk array logs, self-monitoring, analysis and reporting technology logs, physical drive information logs and first message logs; the first message log is a log that records message information of each device used for storage.

9. The fault log processing method according to claim 8, characterized in that: The stored specialist logs are analyzed and processed to obtain corresponding target summary data, including: Sending the physical drive information log to summary data to determine first storage specialty summary data; Compare the independent redundant array of disks log with the first storage specialist summary data to receive a target independent redundant array of disks log in the independent redundant array of disks log to obtain second storage specialist summary data; wherein the target independent redundant array of disks log is an independent redundant array of disks log that does not have the same component slot and problem status information after comparison with the first storage specialist summary data; Compare the first message log with the second storage specialist summary data to receive the target first message log in the first message log to obtain the third storage specialist summary data; wherein the target first message log is a first message log that does not have the same component slot and problem status information after comparison with the second storage specialist summary data; Compare the self-monitoring, analysis and reporting technology log with the third storage specialist summary data to receive a target self-monitoring, analysis and reporting technology log in the self-monitoring, analysis and reporting technology log to obtain fourth storage specialist summary data; wherein the target self-monitoring, analysis and reporting technology log is a self-monitoring, analysis and reporting technology log that does not have the same component slot and problem status information after comparison with the third storage specialist summary data; The fourth storage specialist summary data is state-corrected according to the current state of the component recorded in the self-monitoring, analysis and reporting technical log to obtain target summary data corresponding to the storage specialist log.

10. The fault log processing method according to claim 5, characterized in that: The computing specialist log includes: an internal error log, a maintenance log, a process analysis log and a second message log; the second message log is a log that records message information of each device used for computing.

11. The fault log processing method according to claim 10, characterized in that: Analyze and process the computing specialist log to obtain corresponding target summary data, including: feeding the second message log into summary data to determine first computing specialty summary data; Compare the process analysis log with the first computing specialty summary data to receive a target process analysis log in the process analysis log, and obtain second computing specialty summary data; wherein the target process analysis log is a process analysis log that does not have the same component slot and problem status information after comparison with the first computing specialty summary data; Compare the internal error log with the second computing specialty summary data to receive a target internal error log in the internal error log to obtain third computing specialty summary data; wherein the target internal error log is an internal error log that does not have the same component slot and problem status information after comparison with the second computing specialty summary data; Comparing the maintenance log with the third computing specialty summary data to receive a target maintenance log in the maintenance log, and obtaining fourth computing specialty summary data; wherein the target maintenance log is a maintenance log that does not have the same component slot and problem status information after comparison with the third computing specialty summary data; The fourth computing specialist summary data is state-corrected according to the current state of the component recorded in the maintenance log to obtain target summary data corresponding to the computing specialist log.

12. The fault log processing method according to any one of claims 1 to 11, characterized in that: The performing fault diagnosis based on the log details and the target summary data includes: A first diagnostic rule and a second diagnostic rule are obtained respectively, and the first diagnostic rule and the second diagnostic rule are combined to obtain a target decision rule; wherein the first diagnostic rule is a diagnostic rule obtained by combing and solidifying the rules of an existing fault diagnosis instance, and the second diagnostic rule is a diagnostic rule obtained by matching the fault data with rules through an artificial intelligence algorithm; Based on the log details and the target summary data, the target decision rule is used to perform fault diagnosis, and the root cause of the fault of the faulty component is output.

13. An electronic device, characterized in that: include: Memory for storing computer programs; A processor, used to load and execute the computer program to implement the fault log processing method according to any one of claims 1 to 12.

14. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instructions are executed by a processor, the steps of the fault log processing method according to any one of claims 1 to 12 are implemented.

15. A computer-readable storage medium, characterized in that: Used to store computer programs; wherein the computer program, when executed by a processor, implements the fault log processing method according to any one of claims 1 to 12.

Images