Downtime fault analysis

Abstract

Provided in the embodiments of the present application are downtime fault analysis methods and apparatus, an electronic device, and a storage medium. A downtime fault analysis method comprises: acquiring downtime state information of a downtime server, the downtime state information being used for describing running state information of the downtime server when a downtime fault occurs; performing feature extraction on the downtime state information to obtain a downtime feature of the downtime server; acquiring feature rules and a corresponding relationship between the feature rules and fault root causes; and determining a target feature rule matched with the downtime feature, and, on the basis of the corresponding relationship, determining a target fault root cause corresponding to the target feature rule as a downtime root cause of the downtime server. The embodiments of the present application can improve the analysis efficiency and accuracy for downtime fault analysis.

Description

Downtime Fault Analysis Technology Field

[0001] The embodiments of the present application relate to the field of computer technology, and in particular to a method, device, electronic device, and a related invention for analyzing a computer downtime.

[0002] Server downtime can have serious consequences. For example, cloud computing technology is gaining popularity due to its advantages such as high security, scalability, and rapid deployment. Cloud computing platforms include server clusters consisting of a large number of physical servers, on which virtual machines can be deployed to provide computing services to different users. When physical servers or virtual machines in a cloud computing platform experience downtime, users experience a poor user experience, which in turn affects user retention. When downtime occurs, root cause analysis is crucial to ensure prompt repair.

[0003] In related technologies, downtime failure analysis is usually performed manually by experienced experts, which is time-consuming, costly, and difficult to guarantee accuracy.

[0004] Therefore, there is an urgent need for an efficient and accurate downtime fault analysis solution.

[0005] In view of this, an embodiment of the present application provides a downtime fault analysis method, comprising: obtaining downtime status information of a downtime server; the downtime status information is used to describe the operating status information of the downtime server when the downtime fault occurs; performing feature extraction on the downtime status information to obtain downtime features of the downtime server; obtaining feature rules and a correspondence between the feature rules and root causes of the fault; determining a target feature rule that matches the downtime feature, and based on the correspondence, determining a target root cause corresponding to the target feature rule as the root cause of the downtime of the downtime server.

[0006] According to a second aspect of an embodiment of the present application, another downtime fault analysis method is provided, comprising: receiving a downtime fault analysis request; the downtime fault analysis request including a process memory image file obtained through a host machine in a cloud computing platform; the process memory image file being generated when a target virtual machine located in the host machine experiences a downtime fault; parsing the process memory image file to obtain downtime status information; performing feature extraction on the downtime status information to obtain a downtime feature; determining a target feature rule matched by the downtime feature from preset feature rules, and determining a downtime root cause of the target virtual machine based on a correspondence between the feature rule and the root cause of the fault; and returning an analysis result, wherein the analysis result includes the downtime root cause of the target virtual machine.

[0007] According to a third aspect of an embodiment of the present application, another method for analyzing a downtime failure is provided, comprising: receiving a downtime failure analysis request sent by a host machine in a cloud computing platform; the downtime failure analysis request including a process memory image file generated by the host machine at a historical stage when a downtime failure occurred; parsing the process memory image file to obtain downtime status information; performing feature extraction on the downtime status information to obtain a downtime feature; determining a target feature rule matched by the downtime feature from preset feature rules, and determining a historical root cause of the downtime of the host machine based on a correspondence between the feature rule and the root cause of the failure; and returning an analysis result to the host machine, the analysis result including the historical root cause of the downtime.

[0008] According to a fourth aspect of the embodiment of the present application, a downtime fault analysis device is provided, comprising: an information acquisition module, configured to acquire downtime status information of a downtime server; the downtime status information is used to describe The system includes: a running status information of the downtime server when the downtime failure occurs; a feature extraction module for extracting features from the downtime status information to obtain downtime features of the downtime server; a correspondence acquisition module for obtaining feature rules and the correspondence between the feature rules and the root cause of the failure; and a root cause determination module for determining a target feature rule that matches the downtime feature, and based on the correspondence, determining a target root cause corresponding to the target feature rule as the root cause of the downtime of the downtime server.

[0009] According to a fifth aspect of an embodiment of the present application, an electronic device is provided, comprising: a processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other via the communication bus; the memory is used to store at least one executable instruction, wherein the executable instruction enables the processor to perform an operation corresponding to the method described in any one of the first to third aspects.

[0010] According to a sixth aspect of the embodiments of the present application, a computer storage medium is provided, on which a computer program is stored. When the program is executed by a processor, the method according to any one of the first to third aspects is implemented.

[0011] The downtime fault analysis solution provided in the embodiment of the present application, after obtaining the downtime status information of the downtime server, performs feature extraction on the downtime status information to obtain the downtime characteristics of the downtime server; in addition, it also obtains pre-established feature rules and the correspondence between the feature rules and the root cause of the fault; then, it determines the target feature rule that matches the downtime characteristics, and then obtains the root cause of the downtime of the downtime server based on the above correspondence. The embodiment of the present application adopts a regularized matching method to automatically classify the downtime faults of the downtime server, thereby determining the root cause of the downtime. Compared with manual analysis methods, the analysis efficiency and accuracy of downtime fault analysis are improved.

[0012] To more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments described in the embodiments of the present application. Those skilled in the art can also obtain other drawings based on these drawings.

[0013] FIG1 is a flowchart of a method for analyzing a downtime failure according to a first embodiment of the present application;

[0014] FIG2 is a schematic diagram of the analysis process corresponding to the embodiment shown in FIG1 ;

[0015] FIG3 is a schematic diagram showing a comparison of the scopes of different classifications;

[0016] FIG4 is a flow chart of fault root cause classification based on stack matching rules;

[0017] FIG5 is a flow chart of the similarity classification method;

[0018] FIG6 is a flow chart of fault root cause classification based on feature matching rules;

[0019] Figure 7 is a schematic diagram of the root cause classification process based on a combination of stack matching rules and feature matching rules;

[0020] FIG8 is a schematic diagram of the process of obtaining downtime status information;

[0021] FIG9 is a schematic diagram of a process for analyzing and obtaining a downtime status file in a Linux operating system;

[0022] FIG10 is a schematic diagram of a process for analyzing and obtaining a downtime status file in a Windows operating system;

[0023] FIG11 is a flowchart of a method for analyzing a downtime failure according to the second embodiment of the present application;

[0024] FIG12 is a flowchart of the steps of a method for analyzing a downtime failure according to the third embodiment of the present application;

[0025] FIG13 is a structural block diagram of a downtime fault analysis device according to a fourth embodiment of the present application;

[0026] FIG14 is a structural block diagram of a downtime fault analysis device according to Embodiment 5 of the present application;

[0027] FIG15 is a structural block diagram of a downtime fault analysis device according to a sixth embodiment of the present application;

[0028] FIG16 is a schematic diagram of the structure of an electronic device according to the seventh embodiment of the present application.

[0029] To help those skilled in the art better understand the technical solutions in the embodiments of the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the accompanying drawings. Obviously, the described embodiments are only a portion of the embodiments of the present application, and are not intended to be exhaustive. All other embodiments derived by those skilled in the art based on the embodiments of the present application should fall within the scope of protection of the embodiments of the present application.

[0030] Example 1.

[0031] 1 is a flowchart illustrating a method for analyzing a system downtime according to a first embodiment of the present application. Specifically, the method for analyzing a system downtime provided in this embodiment includes steps 102 to 108.

[0032] Step 102, obtain the downtime status information of the downtime server; the downtime status information is used to describe the running status information of the downtime server when the downtime failure occurs.

[0033] Specifically, the downtime server in this application can be any server for which downtime fault analysis is to be performed. For example, it can be a conventional server or a server in a cloud computing platform. Furthermore, in the case of a cloud computing platform, the downtime server in this step can be a physical host machine or a virtual machine (cloud server instance) deployed in the physical host machine.

[0034] The embodiments of the present application do not limit the specific method used to obtain the downtime status information of the downtime server. For example, when a downtime failure occurs, the downtime server may automatically generate a file representing the process execution status (such as a dump file). Therefore, the downtime status information can be obtained by obtaining the file and performing preprocessing operations (such as content parsing, redundant information removal, format conversion, etc.) on the file. In addition, in some special scenarios, the above file may not be generated. In this case, the kernel log information generated by the downtime server when the failure occurs can be obtained, and the downtime status information in this step can be obtained based on the kernel log information.

[0035] Step 104: Extract features from the downtime status information to obtain downtime features of the downtime server.

[0036] Specifically, downtime status information typically contains a wide range of content, some of which is related to the downtime failure, while some is not. In this step, feature extraction from the downtime status information can be performed by filtering information from the downtime status information, or in other words, by refining the information. The resulting downtime features can be information in the downtime status information that is related to the downtime failure.

[0037] The crash characteristics in the embodiments of the present application can be set based on actual conditions or expert experience. Furthermore, to improve the accuracy of fault analysis results, feature extraction can be performed on crash status information from multiple different dimensions to obtain a variety of different crash characteristics. For example, feature extraction can be performed not only from the stack information dimension to obtain stack information, but also from the perspective of installed modules (such as third-party software) to obtain information about installed modules on the crashed server and / or information about key modules that may have a significant impact on the crash (or, in other words, are associated with the crash failure). Of course, feature extraction can also be performed from the function call dimension to obtain function call feature information of the crashed server, and so on. In the embodiments of the present application, the specific method of feature extraction and the specific content of the crash characteristics obtained are not limited and can be customized based on actual conditions.

[0038] Step 106: Acquire characteristic rules and the corresponding relationship between the characteristic rules and the root cause of the fault.

[0039] Specifically, the characteristic rules obtained in this step refer to the rules satisfied by the characteristics or characteristic combinations. Before performing downtime fault analysis, one or more characteristic rules can be pre-generated, and for each characteristic rule, a corresponding root cause of the fault is generated.

[0040] In practical applications, the definition of feature rules can be based on a variety of factors, such as expert experience, known patterns, and historical data. Furthermore, during application, the defined feature rules can be continuously optimized and updated to improve the accuracy and reliability of root cause location.

[0041] The corresponding relationship between the characteristic rules and the root causes of the faults obtained in the embodiment of the present application means that when the characteristics of the downtime server (such as the downtime characteristics mentioned above) meet a certain characteristic rule, the downtime cause of the downtime server can be The root cause of the fault is determined to be the fault root cause corresponding to the above-mentioned feature rule. For example, assuming that the downtime characteristics of the downtime server extracted in step 104 include feature A and feature B, the corresponding relationship between a feature rule and the root cause of the fault can indicate that when the downtime characteristics meet the feature rule that feature A has a value of a and feature B has a value of b, the downtime cause of the downtime server can be determined to be root cause 1.

[0042] Step 108: Determine the target feature rule that matches the downtime feature, and based on the corresponding relationship, determine the target fault root cause corresponding to the target feature rule as the downtime root cause of the downtime server.

[0043] Specifically, in the embodiments of the present application, the specific matching method employed when matching the downtime characteristics with the characteristic rules obtained in step 106 is not limited and can be customized based on actual circumstances. For example, to improve the accuracy of the matching results, a complete matching method can be employed to determine the target characteristic rule. That is, when the downtime characteristics and the target characteristic rule are exactly the same, they are determined to be a match. For another example, to improve the flexibility of the matching process, a similarity matching method can be employed to determine the target characteristic rule. That is, when the similarity between the downtime characteristics and the target characteristic rule is high, they are determined to be a match. And so on.

[0044] As can be seen from steps 106 and 108 above, this embodiment of the present application utilizes a rule-based (feature-based) downtime fault classification algorithm to classify downtime status information to determine the root cause category of the downtime server's fault. See FIG2 , which is a schematic diagram of the analysis flow corresponding to the embodiment shown in FIG1 . The process of the downtime fault analysis method according to the above embodiment of the present application will be described below with reference to FIG2 .

[0045] Specifically, the fault analysis process is as follows: obtaining downtime status information of a downtime server, which can serve as an input condition for a downtime fault classification algorithm according to an embodiment of the present application; performing downtime fault classification based on the downtime status information, specifically: extracting features from the downtime status information to obtain downtime features of the downtime server; performing downtime fault classification based on the matching between the features and feature rules, that is, determining a target feature rule matched by the downtime feature, and based on the correspondence between the feature rule and the root cause of the fault, determining the target root cause corresponding to the target feature rule as the root cause of the downtime of the downtime server; and outputting the determined root cause.

[0046] The downtime fault analysis solution provided in the embodiments of the present application, after obtaining downtime status information of a downtime server, performs feature extraction on the downtime status information to obtain the downtime characteristics of the downtime server. Furthermore, pre-established feature rules and the correspondence between the feature rules and the root cause of the fault are obtained. The target feature rule that matches the downtime characteristics is then determined, and the root cause of the downtime of the downtime server is determined based on the correspondence. The embodiments of the present application utilize a rule-based matching approach to automatically classify downtime faults of the downtime server and thereby determine the root cause of the downtime. Compared to manual analysis, this improves the efficiency and accuracy of downtime fault analysis.

[0047] The downtime fault analysis method of this embodiment can be executed by any appropriate electronic device with data processing capabilities, including but not limited to: a server and a PC.

[0048] Optionally, in some embodiments, the downtime characteristics include at least: installed module information, key module information, and key stack information of the downtime server; performing feature extraction on the downtime status information to obtain the downtime characteristics of the downtime server includes: determining, through keyword search, the location of the installed module information of the downtime server and the location of the key stack information in the downtime status information; obtaining the installed module information of the downtime server from the downtime status information according to the location of the installed module information; and obtaining the key stack information from the downtime status information according to the location of the key stack information.

[0049] Specifically, the above-mentioned key module information may be information of a module (such as third-party software, etc.) associated with the downtime failure, that is, the module that causes the server downtime failure.

[0050] Key stack information can be information describing the system code execution location and function call path at the time of a system crash. Specifically, during system code execution, stack information can be generated to record the current code execution location and function call path. Those skilled in the art will appreciate that different code segments may be executed and different functions may be called at different times. Therefore, multiple stack information may be generated over time. To accurately analyze a system crash, in embodiments of the present application, key stack information corresponding to the time of the crash can be extracted from the crash status information for subsequent analysis.

[0051] The key stack information may be complete stack information, or partial data in the complete stack, for example, data of the last three layers of the stack, data of the last five layers of the stack, etc. The specific content of the key stack information is not limited in the embodiments of the present application.

[0052] Furthermore, different operating systems may have different crash characteristics. When extracting crash characteristics, a certain number of features can be selected from a variety of features based on information such as the operating system type, experience, and historical patterns as crash characteristics. For example, Table 1 below shows crash characteristics corresponding to different operating systems selected based on experience. Table 1

[0053] The following subsystem provides an example of the process of feature extraction to obtain downtime features.

[0054] For the Linux operating system, the feature extraction process can be as follows: 1. Searching for Panicinfo information, i.e., key information of the panic line, from the crash status information (which can be a text file); 2. When the crash status information contains multiple stacks, the location of the key stack that has a greater impact on the crash can be located using the Panicinfo information and the CallTrace keyword; 3. Preprocessing the key stack, including removing irrelevant information such as useless function lines and function lines with ?, and parsing the complete stack from the key stack, including the five layers of data after the stack and the stack after the stack. 3. Locate and parse the last called function information from the multiple lines before and after the key stack using the "Rip" keyword; 5. Parse the key module information from the key stack or Rip line; 6. Locate and obtain the installed module list information using the "Modules Linked in" keyword.

[0055] For the Windows operating system, the feature extraction process can be as follows: 1. When there are multiple stacks in the crash status information, the position of the key stack is located by the "KeBugCheckEx" keyword; 2. The key stack is preprocessed, including removing irrelevant information such as useless function lines, and parsing the complete stack, the last three layers of the stack, and other information from the key stack; 3. From the key stack, the key module Module > Rsp, bugCheckCode and other information are parsed; 4. The "Im" keyword is used to locate and obtain the installed module list information of InstallModules.

[0056] Optionally, in some embodiments, the downtime fault analysis method may further include: obtaining system characteristics of the downtime server; the system characteristics characterizing characteristics of the operating system of the downtime server;

[0057] Determining the target feature rules matched by the downtime feature, including: determining the target feature rules satisfied by the downtime feature and the operating system feature.

[0058] Specifically, in the embodiment of the present application, the specific content of the system characteristics is not limited. For example, it may include at least one of the following: system type (such as Windows > Linux, etc.), distribution version (such as Windows 10 > Ubuntu 20.04, etc.), system name and kernel version, etc.

[0059] As mentioned above, different operating systems may have different crash characteristics. Therefore, before performing feature extraction, the system characteristics can be obtained first, and then the corresponding crash characteristics can be adaptively extracted based on the different system characteristics.

[0060] Furthermore, in step 108, when using a feature-rule-based downtime fault classification algorithm to classify downtime status information and determine the root cause category to which the downtime server's root cause belongs, incorporating system features helps improve the accuracy of the classification results, and therefore the accuracy of the fault analysis results. When system features are obtained, feature rules can refer to rules satisfied by system features, downtime features, between system features and downtime features, between system features, or between downtime features. Accordingly, during rule matching, a target feature rule can be determined that matches both the downtime features and the system features, and the target root cause corresponding to the target feature rule can be determined as the root cause of the downtime of the downtime server.

[0061] With respect to the above step 106, two different methods may be used to obtain the characteristic rules and the corresponding relationship between the characteristic rules and the root causes of the faults. That is, the root causes of the faults may be classified based on two different rules.

[0062] The first method is to classify fault root causes based on stack matching rules. Specifically, a mapping table is created based on existing manually annotated data. When a failure feature is input in downtime status information, the mapping table is searched for matching features and the corresponding root cause is determined. This method relies on experience and existing manually annotated data to construct a mapping table to associate feature combinations with root causes.

[0063] The second approach is to classify root causes based on feature matching rules. Specifically, based on experience and existing knowledge, some feature rules are manually defined. When the combination of downtime and / or system features meets these rules, the downtime fault is attributed to a specific root cause. This approach does not rely on manual labeling, but rather relies on human judgment and matching of features for classification.

[0064] The following describes in detail the first fault root cause classification method based on stack matching rules.

[0065] Optionally, in some embodiments, the correspondence between the feature rule and the root cause of the fault is presented in the form of a mapping table, where the feature rule is a key in the mapping table and the root cause of the fault is a value in the mapping table. Determining a target feature rule that matches the downtime feature, and based on the correspondence, determining a target root cause of the fault corresponding to the target feature rule as the root cause of the downtime of the downtime server includes: comparing the downtime feature of the downtime server with the key in the mapping table to determine a target key that matches the downtime feature of the downtime server; and determining the value corresponding to the target key in the mapping table as the root cause of the downtime of the downtime server.

[0066] Specifically, in the above process, after the downtime feature is obtained, a search can be performed in the mapping table, that is, the downtime feature is matched with each key contained in the mapping table, so that the value corresponding to the matching target key is determined as the downtime feature. The root cause of the server downtime.

[0067] See Table 2 below, which is an exemplary mapping table provided in the embodiment of the present application.

[0068] As described above, the fault root cause classification method based on stack matching rules relies on experience and existing annotated data to construct a mapping table. The following explains the mapping table construction process, namely, the process of adding new key-value pairs to the mapping table.

[0069] Optionally, in some embodiments, the feature rule includes features and feature values corresponding to the features; and the process of adding a new key-value pair to the mapping table may include: obtaining pending downtime status information; performing feature extraction on the pending downtime status information to obtain multiple downtime features included in the pending downtime status information; selecting at least some of the multiple downtime features included in the pending downtime status information, and determining the at least some of the features and the feature values corresponding to the at least some of the features as keys in a new key-value pair; and determining a downtime root cause corresponding to the pending downtime status information, and using the determined downtime root cause as a value in the new key-value pair.

[0070] Specifically, the above process involves determining the following three pieces of information: classification basis, classification scope, and root cause. The classification basis indicates the downtime characteristics used to classify the pending downtime status information; the classification scope primarily represents a further limitation of system characteristics; and the root cause is the root cause of the fault corresponding to the pending downtime status information.

[0071] The specific processing process is as follows: after extracting features from the pending downtime status information and obtaining multiple downtime features, at least some of the downtime features can be marked as classification criteria; at least some of the system features can be determined as the classification scope (this step is optional); and a corresponding root cause can be set for the pending downtime status information. The processing process is now complete, and accordingly, a new key-value pair can be created in the mapping table. The set classification criteria and classification scope together determine the key in the new key-value pair, while the set root cause determines the value in the new key-value pair.

[0072] The following is a detailed explanation of the classification scope: Setting the classification scope means adding system features that restrict the system in addition to the downtime features to be matched with the feature rules. Specifically, when setting the classification scope, you can set a specific kernel version (such as 3.10 kernel + Centos7 series), a specific distribution version (such as Centos > Ubuntu, etc.), a specific OS category (such as RHel, Debian > Suse, etc.), and of course, a specific system (Linux). See Figure 3, which is a schematic diagram comparing different classification scopes. As can be seen from Figure 3, the above five setting methods gradually relax the restrictions on the system. In other words, as the scope is further expanded, the system is further expanded. When matching row feature rules, the matching range gradually expands.

[0073] In addition, when the classification scope is fixed, choosing different downtime characteristics as the classification basis may also result in rule matching conditions of different strictness. See Table 3 below, which shows the correspondence between the classification basis and the strictness of the matching conditions.

[0074] Table 3 above shows that the stringency of the matching conditions becomes increasingly relaxed as we move from top to bottom. This is because if two stacks have identical FullCallTrace data, they must also have identical data in the last three or fifth layers of the stack. However, the reverse is not true: the probability that two stacks have identical data in the last three layers is higher than the probability that their full stacks are identical. Therefore, it can be concluded that the condition requiring a full stack match is more stringent than the condition requiring a match in the last three layers of the stack.

[0075] 4, which is a schematic diagram of a process for classifying fault root causes based on stack matching rules. The above-mentioned fault root cause classification process will be described below in conjunction with FIG4.

[0076] After extracting features from the current downtime status information to obtain downtime features and acquiring system features, the current downtime status information can be compared with previously labeled (processed) downtime status information in the database based on the features to check whether certain feature combinations match keys in key-value pairs obtained based on the labeled downtime status information in a mapping table. If so, classification is successful, and the target value corresponding to the matched target key is determined as the root cause of the fault corresponding to the current downtime status information. Conversely, if no matching target key exists, classification fails, indicating that the root cause of the fault corresponding to the current downtime status information has not been determined. Alternatively, the obtained current downtime status information can be used as downtime status information to be labeled. By manually labeling, a key-value pair corresponding to the downtime status information to be labeled is added to the mapping table. After the key-value pair is constructed, the state of the downtime status information to be labeled changes from an unclassified state (unlabeled state) to a classified state (labeled state).

[0077] Furthermore, the step of comparing the downtime characteristics of the downtime server with the keys in the mapping table and determining a target key that matches the downtime characteristics of the downtime server can be implemented in the following two ways.

[0078] The first method is the "pattern classification method." The core of this method is that when two different pieces of downtime status information share the same downtime characteristics and system characteristics, they are considered to have the same root cause. Specifically, this method compares the downtime characteristics and system characteristics of the downtime server with the keys in the mapping table. If a key has the same values as the downtime characteristics and system characteristics, that key is identified as the target key.

[0079] The second method, "Similarity Classification," involves performing vectorized encoding on each key in the mapping table to obtain a key vector corresponding to each key in the mapping table. Vectorized encoding is performed on the downtime characteristics and / or system characteristics of the downtime server to obtain a feature vector. Based on the similarity between the feature vector and the key vector corresponding to each key in the mapping table, a target key matching the downtime characteristics is determined.

[0080] In comparison, the first approach, based on exact matching, has the advantage of accurately matching known data and providing highly accurate matching results. The second approach, on the other hand, utilizes a similarity detection algorithm to evaluate the degree of similarity between different pieces of downtime status information by calculating their similarity. When the similarity exceeds a certain threshold, the two pieces of downtime status information are considered highly similar and likely share the same root cause. This approach generalizes the algorithm, improving its accuracy and adaptability.

[0081] 5, which is a schematic diagram of the process of the similarity classification method. The process of the similarity classification method described above will be described below in conjunction with FIG5.

[0082] Extract each key from the mapping table; perform an encoding operation on each key to obtain a key vector, and store the obtained key vector in a quantity library; obtain the total number of downtime status information to be classified; determine whether the number of classified downtime status information is less than the total number; if the number of classified downtime status information is less than the total number, obtain a piece of downtime status information to be classified and search for a similar key vector in the vector library; if there is a target key vector with a similarity greater than a preset threshold, modify the state of the downtime status information to be classified to the classified downtime status information, and determine the value corresponding to the target key vector as the fault root cause corresponding to the classified downtime status information; if there is no target key vector with a similarity greater than the preset threshold, return to the step of determining whether the number of classified downtime status information is less than the total number; if the number of classified downtime status information is equal to the total number, terminate the process.

[0083] The second fault root cause classification method based on feature matching rules is described in detail below.

[0084] As described above, this fault root cause classification method does not rely on manual labeling. Instead, it defines characteristic rules based on human experience and existing knowledge. When a combination of downtime characteristics and / or system characteristics meets these rules, the downtime fault is attributed to a specific root cause. In this case, characteristic rules can be understood as preset conditions satisfied by a characteristic or a combination of characteristics. Correspondingly, the process of determining a target characteristic rule that matches the downtime characteristics and, based on the corresponding relationship, determining the target root cause corresponding to the target characteristic rule as the root cause of the downtime of the downtime server may include: determining the target preset conditions satisfied by the downtime characteristics and / or system characteristics, and, based on the corresponding relationship between the preset conditions and the root cause, determining the root cause corresponding to the target preset conditions as the root cause of the downtime of the downtime server.

[0085] 6, which is a schematic diagram of a process for classifying fault root causes based on feature matching rules. The following describes the process of classifying fault root causes based on feature matching rules in conjunction with FIG6.

[0086] Obtain the (current) downtime status information to be classified, perform feature extraction on the downtime status information to be classified, obtain downtime features, and obtain system features; check whether the features meet certain preset conditions; if so, classification is successful, and the root cause of the fault corresponding to the preset conditions is determined as the root cause of the downtime status information to be classified; if not, classification fails, and the root cause of the downtime status information to be classified is not analyzed.

[0087] Furthermore, when classifying fault root causes, the aforementioned stack matching rule-based fault root cause classification method and the aforementioned feature matching rule-based fault root cause classification method can be combined to improve the accuracy of the classification results. See Figure 7 , which illustrates a schematic diagram of the fault root cause classification process based on a combination of stack matching rules and feature matching rules. Referring to Figure 7 , the specific process may include: obtaining downtime status information of the downtime server; extracting features from the downtime status information to obtain downtime features, and obtaining system features; executing a feature matching rule-based fault root cause classification solution based on the features; if the classification is successful, the process ends; if the classification fails, executing a stack matching rule-based fault root cause classification solution again based on the features; if the classification is successful, the process ends.

[0088] In the embodiments of the present application, there is no restriction on the order in which the two schemes for fault root cause classification based on feature matching rules and stack matching rules are executed. FIG7 takes the example of first executing the fault root cause classification process based on feature matching rules and then executing the fault root cause classification process based on stack matching rules, which does not constitute a restriction on the execution order of the two schemes. In specific applications, the execution order can be customized according to actual conditions. For example, the order can be set according to the operating system type. Specifically, for Windows systems, the fault root cause classification process based on feature matching rules can be executed first, and then the fault root cause classification process based on stack matching rules; while for Linux systems, the fault root cause classification process based on stack matching rules can be executed first, and then the fault root cause classification process based on feature matching rules. The root cause classification process of faults.

[0089] Optionally, in some embodiments, the process of obtaining the downtime status information of the downtime server in the above step 102 may include: obtaining a process memory image file; the process memory image file is a file representing the execution status of the process generated in the downtime server when a downtime failure occurs; and executing a preset debugger instruction on the process memory image file to obtain a downtime status file, wherein the downtime status file includes the downtime status information.

[0090] Specifically, when a downtime failure occurs, the downtime server can automatically generate a process memory image file, such as a dump file. Therefore, this file can be obtained and, by executing preset debugger instructions on the file, a downtime status file containing downtime status information can be obtained. In the embodiments of the present application, the specific file format of the downtime status file is not limited. To facilitate subsequent fault classification and analysis, the file format can be set to text.

[0091] In addition, in some special scenarios, the above-mentioned file may not be generated in the down server. In this case, the kernel log information generated in the down server when the fault occurs can be obtained, and the down state information in this step can be obtained based on the above-mentioned kernel log information (such as serial port log and DMS log).

[0092] See Figure 8, which illustrates a flowchart for obtaining downtime status information. Specifically, if a process memory image file exists, a preset debugger instruction can be executed on the process memory image file to obtain a downtime status file containing downtime status information. If a process memory image file does not exist, kernel log information generated by the downtime server at the time of the failure can be queried to obtain a downtime status file containing downtime status information.

[0093] Optionally, in some embodiments, if the operating system type of the downed server is Linux, executing preset debugger instructions on the process memory image file to obtain the downtime status file includes: determining a file analysis environment corresponding to the operating system version; different file analysis environments correspond to different operating system versions, and different file analysis environments are encapsulated in different containers; and executing preset debugger instructions corresponding to the operating system version in the file analysis environment corresponding to the operating system version to obtain the downtime status file.

[0094] Specifically, for Linux operating systems, crash status files are obtained by executing a series of fixed crash instructions on the process memory image file. Due to the diversity of Linux operating systems, adapting the correct analysis environment (including Crash and Debuginfo corresponding to the operating system version) is somewhat difficult. To address this issue, the embodiments of this application adopt a containerized analysis solution, constructing file analysis environments corresponding to the operating system version and isolating different file analysis environments. This effectively ensures that the analysis environment fully matches the operating system version, thereby improving the efficiency and accuracy of obtaining crash status files.

[0095] See Figure 9, which illustrates a flowchart for analyzing and obtaining a crash status file in a Linux operating system. Specifically, after obtaining the process memory image file, a containerized file analysis environment corresponding to the operating system version can be adapted based on the specific operating system version information. Preset debugger instructions are then executed within this analysis environment to obtain the crash status file.

[0096] Optionally, in some embodiments, if the operating system type of the downtime server is Windows, executing preset debugger instructions on the process memory image file to obtain the downtime status file includes: obtaining a customized script file; the customized script file is used to execute multiple debugger instructions on the process memory image file, wherein, during the execution of the debugger instructions, the type and parameters of the (i+1)th debugger instruction are determined by the execution result of the (i)th debugger instruction, where i is a natural number; and running the customized script file to obtain the downtime status file.

[0097] Specifically, for the Windows operating system, the crash status file is obtained by executing a series of Windbg commands on the process memory image file. Unlike Linux, the Windows analysis environment is relatively simple to prepare, but the number of debugging commands is large and variable, requiring adjustment based on specific circumstances. Therefore, in the embodiments of the present application, by pre-generating a customized script file, a customized file analysis process is implemented based on the specific process, ensuring that the crash status file can be obtained efficiently and accurately.

[0098] Referring to FIG. 10 , FIG. 10 is a flow chart illustrating the process of analyzing and obtaining a downtime status file in a Windows operating system. Specifically, an analysis environment may be prepared in advance. After obtaining the process memory image file, a customized script file may be run in the analysis environment to obtain the downtime status file.

[0099] Example 2.

[0100] Referring to FIG. 11 , FIG. 11 is a flowchart illustrating the steps of a method for analyzing a system downtime failure according to a second embodiment of the present application. The method illustrated in FIG. 11 can be used in a scenario where a virtual machine deployed on a host machine experiences a system downtime failure on a cloud computing platform. In this case, the method illustrated in FIG. 11 can be used to perform system downtime failure analysis. Specifically, the system downtime failure analysis method provided in this embodiment includes steps 1102 through 1106.

[0101] Step 1102, receiving a downtime fault analysis request; the downtime fault analysis request includes a process memory image file obtained by the host machine in the cloud computing platform; the process memory image file is generated when a target virtual machine deployed in the host machine crashes.

[0102] Step 1104: parse the process memory image file to obtain downtime status information; perform feature extraction on the downtime status information to obtain downtime features; determine the target feature rule that matches the downtime feature from the preset feature rules, and determine the downtime root cause of the target virtual machine based on the correspondence between the feature rule and the root cause of the fault.

[0103] Step 1106: Return the analysis result, which includes the root cause of the downtime of the target virtual machine.

[0104] The crash fault analysis solution provided in the embodiments of the present application, after obtaining the crash status information of the target virtual machine, performs feature extraction on the crash status information to obtain the crash characteristics of the target virtual machine. Furthermore, pre-established feature rules and the correspondence between the feature rules and the root cause of the fault are obtained. The target feature rule that matches the crash characteristics is then determined, and the root cause of the crash of the target virtual machine is determined based on the correspondence. This embodiment of the present application utilizes a rule-based matching approach to automatically classify the crash faults of the target virtual machine and thereby determine the root cause of the crash. Compared to manual analysis, this improves the efficiency and accuracy of crash fault analysis.

[0105] Example 3.

[0106] Referring to FIG. 12 , FIG. 12 is a flowchart illustrating the steps of a method for analyzing a system downtime according to a third embodiment of the present application. The method illustrated in FIG. 12 can be applied in a scenario where a host computer on a cloud computing platform experiences a system downtime and then restarts. In this scenario, the method illustrated in FIG. 12 can be used to analyze the system downtime. Specifically, the method provided in this embodiment includes steps 1202 through 1206.

[0107] Step 1202: Receive a downtime fault analysis request sent by a host in a cloud computing platform; the downtime fault analysis request includes a process memory image file generated by the host in a historical stage when the downtime fault occurs.

[0108] Step 1204: parse the process memory image file to obtain downtime status information; perform feature extraction on the downtime status information to obtain downtime features; determine the target feature rule that matches the downtime feature from the preset feature rules, and determine the historical downtime root cause of the host machine based on the correspondence between the feature rule and the root cause of the fault.

[0109] Step 1206: Return the analysis results to the host machine, where the analysis results include the root causes of historical downtime.

[0110] The crash fault analysis solution provided in the embodiments of the present application, after obtaining the crash status information of the host machine, performs feature extraction on the crash status information to obtain the host machine crash characteristics. Furthermore, pre-established feature rules and the correspondence between the feature rules and the root cause of the fault are obtained. The target feature rule that matches the crash characteristics is then determined, and the root cause of the host machine crash is determined based on the correspondence. This embodiment of the present application utilizes a rule-based matching approach to automatically classify host machine crash faults and thereby determine the root cause of the crash. Compared to manual analysis, this improves the efficiency and accuracy of crash fault analysis.

[0111] Example 4.

[0112] 13 is a block diagram of a system downtime fault analysis device according to a fourth embodiment of the present application. The system downtime fault analysis device provided in this embodiment includes an information acquisition module 1302, a feature extraction module 1304, a correspondence acquisition module 1306, and a root cause determination module 1308.

[0113] The information acquisition module 1302 is used to obtain the downtime status information of the downtime server; the downtime status information is used to describe the running status information of the downtime server when the downtime failure occurs.

[0114] The feature extraction module 1304 is used to extract features from the downtime status information to obtain downtime features of the downtime server.

[0115] The corresponding relationship acquisition module 1306 is used to acquire characteristic rules and the corresponding relationship between the characteristic rules and the root cause of the fault.

[0116] The root cause determination module 1308 is configured to determine a target feature rule matched by the downtime feature, and based on the corresponding relationship, determine the target fault root cause corresponding to the target feature rule as the downtime root cause of the downtime server.

[0117] Optionally, in some embodiments, the correspondence between the characteristic rules and the root causes of the faults is presented in the form of a mapping table, where the characteristic rules are keys in the mapping table and the root causes of the faults are values in the mapping table. The root cause determination module 1308 is specifically configured to: compare the downtime characteristics of the downtime server with the keys in the mapping table to determine a target key that matches the downtime characteristics of the downtime server; and determine the value corresponding to the target key in the mapping table as the root cause of the downtime of the downtime server.

[0118] Optionally, in some embodiments, the feature rules include features and feature values corresponding to the features; the downtime fault analysis device also includes: a new key-value pair adding module, used to obtain multiple downtime features to be processed; selecting at least some of the features from the multiple downtime features included in the downtime status information to be processed, so as to determine at least some of the features and the feature values corresponding to at least some of the features as keys in a new key-value pair; determining the root cause of the downtime corresponding to the downtime status information to be processed, and determining the determined root cause of the downtime as the value in the new key-value pair.

[0119] Optionally, in some embodiments, the downtime feature includes at least: installed module information, key module information, and key stack information of the downtime server; the feature extraction module 1304 is specifically configured to: locate the location of the installed module information of the downtime server and the location of the key stack information in the downtime status information through keyword search; obtain the installed module information of the downtime server from the downtime status information according to the location of the installed module information; and obtain the key stack information from the downtime status information according to the location of the key stack information.

[0120] Optionally, in some embodiments, the information acquisition module 1302 is specifically configured to: obtain a process memory image file; the process memory image file is a file representing the execution status of the process generated in the downtime server when a downtime failure occurs; execute preset debugger instructions on the process memory image file to obtain a downtime status file, wherein the downtime status file includes downtime status information.

[0121] Optionally, in some embodiments, if the operating system type of the downed server is Linux, the information acquisition module 1302, when executing the step of executing preset debugger instructions on the process memory image file to obtain the downtime status file, is specifically used to: determine a file analysis environment corresponding to the operating system version; different file analysis environments correspond to different operating system versions, and different file analysis environments are encapsulated in different containers; and execute preset debugger instructions corresponding to the operating system version in the file analysis environment corresponding to the operating system version to obtain the downtime status file.

[0122] Optionally, in some embodiments, if the operating system type of the downtime server is Windows, the information acquisition module 1302, when executing a preset debugger instruction on the process memory image file to obtain the downtime status file, is specifically configured to: obtain a customized script file; the customized script file is used to execute multiple debugger instructions on the process memory image file, wherein, during the execution of the debugger instructions, the type and parameters of the (i+1)th debugger instruction are determined by the execution result of the (i)th debugger instruction, where i is a natural number; and run the customized script file to obtain the downtime status file.

[0123] Optionally, in some embodiments, the downtime fault analysis device further includes: The system feature acquisition module is used to obtain the system features of the downed server. The system features represent the characteristics of the operating system of the downed server. Correspondingly, the root cause determination module 1308, when executing the step of determining the target feature rules matched by the downtime features, is specifically used to: determine the target feature rules satisfied by the downtime features and the operating system features.

[0124] The system downtime fault analysis device of this embodiment is used to implement the corresponding system downtime fault analysis method of the aforementioned first embodiment and has the beneficial effects of the corresponding method embodiment, which will not be described in detail here. Furthermore, the functional implementation of each module in the system downtime fault analysis device of this embodiment can refer to the corresponding descriptions of the aforementioned method embodiment and will not be described in detail here.

[0125] Example 5.

[0126] 14 is a block diagram of a system downtime fault analysis device according to Embodiment 5 of the present application. The system downtime fault analysis device provided in Embodiment 5 of the present application includes a first request receiving module 1402, a first analyzing module 1404, and a first result returning module 1406.

[0127] The first request receiving module 1402 is configured to receive a downtime fault analysis request; the downtime fault analysis request includes a process memory image file obtained from a host machine in a cloud computing platform; the process memory image file is generated when a target virtual machine deployed in a host machine experiences a downtime fault.

[0128] The first analysis module 1404 is configured to parse the process memory image file to obtain downtime status information; perform feature extraction on the downtime status information to obtain downtime features; determine a target feature rule that matches the downtime features from preset feature rules, and determine the root cause of the downtime of the target virtual machine based on the correspondence between the feature rule and the root cause of the fault.

[0129] The first result returning module 1406 is configured to return an analysis result, where the analysis result includes a root cause of the downtime of the target virtual machine.

[0130] The system downtime fault analysis device of this embodiment is used to implement the corresponding system downtime fault analysis method of the aforementioned second embodiment and has the beneficial effects of the corresponding method embodiment, which will not be described in detail here. Furthermore, the functional implementation of each module in the system downtime fault analysis device of this embodiment can be referenced to the corresponding descriptions of the aforementioned method embodiment and will not be described in detail here.

[0131] Example 6.

[0132] 15 is a block diagram of a system downtime fault analysis device according to Embodiment 6 of the present application. The system downtime fault analysis device provided in this embodiment of the present application includes a second request receiving module 1502 , a second parsing module 1504 , and a second result returning module 1506 .

[0133] The second request receiving module 1502 is configured to receive a downtime fault analysis request sent by a host in the cloud computing platform. The downtime fault analysis request includes a process memory image file generated by the host in a historical stage when the downtime fault occurred.

[0134] The second parsing module 1504 is configured to parse the process memory image file to obtain downtime status information; perform feature extraction on the downtime status information to obtain downtime features; determine target feature rules that match the downtime features from preset feature rules, and determine the historical root cause of the host machine's downtime based on the correspondence between the feature rules and the root cause of the fault.

[0135] The second result returning module 1506 is used to return the analysis result to the host machine, where the analysis result includes the historical root cause of the downtime.

[0136] The system downtime fault analysis device of this embodiment is used to implement the corresponding system downtime fault analysis method of the aforementioned third embodiment and has the beneficial effects of the corresponding method embodiment, which will not be described in detail here. Furthermore, the functional implementation of each module in the system downtime fault analysis device of this embodiment can be referenced to the corresponding descriptions of the aforementioned method embodiment and will not be described in detail here.

[0137] Example 7.

[0138] 16, there is shown a schematic structural diagram of an electronic device according to Embodiment 7 of the present application. The specific embodiments of the present application do not limit the specific implementation of the electronic device.

[0139] As shown in FIG16 , the electronic device may include: a processor 1602> a communication interface Communications Interface 604 > Memory 1606 > and Communications Bus 1608 »

[0140] The processor 1602, the communication interface 1604, and the memory 1606 communicate with each other via the communication bus 1608.

[0141] The communication interface 1604 is used to communicate with other electronic devices.

[0142] The processor 1602 is configured to execute the program 1610, and specifically to execute the relevant steps in the above-mentioned embodiment of the method for analyzing downtime failure.

[0143] Specifically, the program 1610 may include program code, and the program code includes computer operation instructions.

[0144] Processor 1602 may be a CPU, an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present application. The one or more processors included in the smart device may be processors of the same type, such as one or more CPUs, or may be processors of different types, such as one or more CPUs and one or more ASICs.

[0145] The memory 1606 is used to store the program 1610. The memory 1606 may include a high-speed RAM memory, and may also include a non-volatile memory (non-volatile memory), such as at least one disk memory.

[0146] The program 1610 may include multiple computer instructions. Specifically, the program 1610 may enable the processor 1602 to execute operations corresponding to the downtime fault analysis method described in any of the aforementioned multiple method embodiments through the multiple computer instructions.

[0147] The specific implementation of each step in program 1610 can be found in the corresponding descriptions of the corresponding steps and units in the aforementioned method embodiments, and corresponding beneficial effects are achieved, so a detailed description thereof is omitted here. Those skilled in the art will clearly understand that, for ease and brevity of description, the specific operating processes of the devices and modules described above can be found in the corresponding process descriptions in the aforementioned method embodiments, and a detailed description thereof is omitted here.

[0148] The present application also provides a computer storage medium having a computer program stored thereon. When the computer program is executed by a processor, the method described in any one of the aforementioned method embodiments is implemented. The computer storage medium includes, but is not limited to, a compact disc read-only memory (CD-ROM), a random access memory (RAM), and a computer program. (Random Access Memory, RAM), floppy disk, hard disk or magneto-optical disk, etc.

[0149] An embodiment of the present application further provides a computer program product, including computer instructions, which instruct a computing device to execute operations corresponding to any one of the downtime fault analysis methods in the above-mentioned multiple method embodiments.

[0150] In addition, it should be noted that the user-related information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to sample data used for model training, data used for analysis, stored data, displayed data, etc.) involved in the embodiments of the present application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0151] It should be noted that, according to implementation needs, the various components / steps described in the embodiments of the present application can be split into more components / steps, or two or more components / steps or partial operations of components / steps can be combined into new components / steps to achieve the purpose of the embodiments of the present application.

[0152] The above-described methods according to the embodiments of the present application can be implemented in hardware or firmware, or as software or computer code that can be stored in a recording medium (such as a CD-ROM, RAM, floppy disk, hard disk, or magneto-optical disk), or as computer code originally stored in a remote recording medium or non-transitory machine-readable medium downloaded via a network and then stored in a local recording medium. Thus, the methods described herein can be stored in such software processing on a recording medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware (such as an application-specific integrated circuit (ASIC) or a field-programmable gate array (FPGA)). It will be understood that a computer, processor, microprocessor controller, or programmable hardware includes a storage component (e.g., random access memory (RAM), read-only memory (ROM), flash memory, etc.) that can store or receive software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the methods described herein are implemented. In addition, when a general purpose computer accesses code for implementing the methods shown herein, the execution of the code transforms the general purpose computer into a special purpose computer for executing the methods shown herein.

[0153] Those skilled in the art will appreciate that the various exemplary units and method steps described in conjunction with the embodiments disclosed herein can be implemented using electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented using hardware or software depends on the specific application and design constraints of the technical solution. Professionals may use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of the embodiments of this application.

[0154] The above embodiments are only used to illustrate the embodiments of the present application and are not intended to limit the embodiments of the present application. A person skilled in the art may make various changes and modifications without departing from the spirit and scope of the embodiments of the present application. Therefore, all equivalent technical solutions also fall within the scope of the embodiments of the present application. The scope of patent protection of the embodiments of the present application shall be defined by the claims.

Claims

Claims 1. A method for analyzing a downtime failure, comprising: Get the downtime status information of the downtime server; The downtime status information is used to describe the running status information of the downtime server when the downtime failure occurs; Performing feature extraction on the downtime status information to obtain downtime features of the downtime server; Obtaining feature rules and the corresponding relationship between the feature rules and the root cause of the fault; determining a target feature rule that matches the downtime feature, and based on the corresponding relationship, determining the target root cause of the fault corresponding to the target feature rule as the root cause of the downtime of the downtime server.

2. The method according to claim 1, wherein: The correspondence between the feature rule and the root cause of the fault is presented in the form of a mapping table, where the feature rule is a key in the mapping table, and the root cause of the fault is a value in the mapping table; determining the target feature rule that matches the downtime feature, and determining the target root cause of the fault corresponding to the target feature rule as the root cause of the downtime of the downtime server based on the correspondence, includes: comparing the downtime feature of the downtime server with the key in the mapping table, determining the target key that matches the downtime feature of the downtime server; and determining the value corresponding to the target key in the mapping table as the root cause of the downtime of the downtime server.

5. The method according to any one of claims 1 to 3, wherein: The obtaining of the downtime status information of the downtime server includes: obtaining a process memory image file; the process memory image file is a file representing the process execution status generated in the downtime server when a downtime failure occurs; executing a preset debugger instruction on the process memory image file to obtain a downtime status file, wherein the downtime status file includes the downtime status information.

6. The method according to claim 5, wherein: If the operating system type of the downtime server is Linux, executing preset debugger instructions on the process memory image file to obtain the downtime status file includes: determining a file analysis environment corresponding to the version of the operating system; different file analysis environments correspond to different operating system versions, and different file analysis environments are encapsulated in different containers; and executing preset debugger instructions corresponding to the operating system version in the file analysis environment to obtain the downtime status file.

7. The method according to claim 5, wherein: If the operating system type of the downtime server is Windows, executing preset debugger instructions on the process memory image file to obtain the downtime status file includes: obtaining a customized script file; using the customized script file to execute multiple debugger instructions on the process memory image file, wherein, during the execution of the debugger instructions, the type and parameters of the (i+1)th debugger instruction are determined by the execution result of the (i)th debugger instruction, where (i) is a natural number; and running the customized script file to obtain the downtime status file.

8. The method according to claim 1, wherein: The method further includes: obtaining a system characteristic of the downtime server; the system characteristic representing a characteristic of an operating system of the downtime server; The determining of the target feature rule matched by the downtime feature includes: determining the target feature rule satisfied by the downtime feature and the operating system feature.

9. A method for analyzing a downtime failure, comprising: Receive downtime fault analysis requests; The downtime fault analysis request includes a process memory image file obtained through a host machine in the cloud computing platform; The process memory image file is generated when a target virtual machine located in the host machine crashes; the process memory image file is parsed to obtain crash status information; feature extraction is performed on the crash status information to obtain crash features; a target feature rule that matches the crash features is determined from preset feature rules, and a crash root cause of the target virtual machine is determined based on a correspondence between the feature rule and the root cause of the fault; and an analysis result is returned, wherein the analysis result includes the crash root cause of the target virtual machine.

10. A method for analyzing a downtime failure, comprising: Receive a downtime fault analysis request sent by a host machine in a cloud computing platform; The downtime fault analysis request includes a process memory image file generated by the host machine at a historical stage when the downtime fault occurred; the process memory image file is parsed to obtain downtime status information; feature extraction is performed on the downtime status information to obtain a downtime feature; a target feature rule that matches the downtime feature is determined from preset feature rules, and a historical downtime root cause of the host machine is determined based on a correspondence between the feature rule and the root cause of the fault; and an analysis result is returned to the host machine, wherein the analysis result includes the historical downtime root cause.

11. A system downtime fault analysis device, comprising: An information acquisition module is used to obtain downtime status information of downtime servers; The downtime status information is used to describe the running status information of the downtime server when the downtime failure occurs; A feature extraction module is configured to extract features from the downtime status information to obtain downtime features of the downtime server; a correspondence acquisition module is configured to obtain feature rules and the correspondence between feature rules and root causes of the fault; and a root cause determination module is configured to determine a target feature rule that matches the downtime feature and, based on the correspondence, determine a target root cause corresponding to the target feature rule as the root cause of the downtime of the downtime server.

12. An electronic device comprising: a processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other via the communication bus; The memory is used to store at least one executable instruction, where the executable instruction enables the processor to perform an operation corresponding to the method according to any one of claims 1 to 10.

13. A computer storage medium having a computer program stored thereon, which, when executed by a processor, implements the method according to any one of claims 1 to 10.

14. A computer program product comprising computer instructions, wherein the computer instructions instruct a computing device to perform operations corresponding to the method according to any one of claims 1 to 10.

Images