Cloud service-based fault detection method and apparatus

Abstract

The present application provides a cloud service-based fault detection method and apparatus. The method comprises: providing a configuration interface of a fault detection service, wherein the configuration interface is used for receiving system configuration information and a first service requirement that are of an application system and are input by a user, the system configuration information is used for indicating a topological relationship between a plurality of topological nodes, and the first service requirement indicates that fault detection is performed for at least two levels among a plurality of levels; acquiring running data of the plurality of topological nodes when the application system is running, wherein the running data of the plurality of topological nodes is used for determining fault detection results corresponding to the at least two levels; and displaying a fused detection result of the application system on a result interface of the fault detection service, wherein the fused detection result is obtained by fusing, on the basis of the topological relationship, the fault detection results corresponding to the at least two levels. The method can be used for making a comprehensive decision on the basis of fault detection results obtained by a plurality of fault isolation methods, thereby improving the accuracy of the fault detection results.

Description

A cloud service-based fault detection method and device

[0001] Cross-reference to Related Applications

[0002] The present application claims priority to the Chinese Patent Application No. 202411274512.7, filed on September 11, 2024, and entitled "A Cloud Service-Based Fault Detection Method and Device", the content of which is incorporated herein by reference in its entirety. TECHNICAL FIELD

[0003] The present application relates to the field of cloud technology, and in particular to a cloud service-based fault detection method and device. BACKGROUND

[0004] An application system is a computing cluster that provides background services for enterprise applications, for example, the application system is a background service system of a financial system, etc. Fault isolation refers to a process of determining the fault range when a fault occurs in an application system. For example, through fault isolation, it can be determined that which subsystem in the application system has a fault and causes the application system to fail to work normally, so that the application system can be quickly repaired.

[0005] At present, in order to improve the accuracy of fault isolation, a plurality of methods can be used to perform fault isolation respectively. However, in the case that fault information determined by the plurality of methods is different, it is unable to select a result obtained by which method as the final fault isolation result. SUMMARY

[0006] Embodiments of the present application provide a cloud service-based fault detection method and device, which are used to make a comprehensive decision according to fault detection results obtained by a plurality of fault isolation methods, and improve the accuracy of the fault detection results.

[0007] In a first aspect, a cloud service-based fault detection method is provided, which can be applied to a cloud management platform. The cloud management platform is configured to manage an infrastructure providing cloud services, the infrastructure comprising a plurality of regions, each region comprising at least one cloud data center, and the cloud services being run on at least one server of at least one cloud data center located in one of the plurality of regions. The method comprises: providing a configuration interface of a fault detection service, the configuration interface being configured to receive system configuration information of an application system and first service requirements input by a user, the application system adopting a hierarchical architecture comprising a plurality of levels, the plurality of levels comprising a plurality of topology nodes, each topology node being located in one of the plurality of levels, the system configuration information being configured to indicate a topology relationship between the plurality of topology nodes, and the first service requirements being configured to indicate that fault detection is to be performed on at least two levels of the plurality of levels; obtaining running data of the plurality of topology nodes of the application system, the running data of the plurality of topology nodes being configured to determine fault detection results corresponding to the at least two levels; and displaying a fusion detection result of the application system on a result interface of the fault detection service, the fusion detection result being obtained by fusing the fault detection results corresponding to the at least two levels according to the topology relationship.

[0008] In the method, the user can configure the system configuration information of the application system to be detected and configure the at least two levels for which fault detection is to be performed. The cloud management platform can perform fault detection on the at least two levels according to the running data of the application system when running, and fuse the fault detection results corresponding to the at least two levels according to the topology relationship indicated by the system configuration information to obtain a final fusion detection result. It can be seen that the embodiments of the present application realize fusion of fault detection results of different levels. Moreover, since the method performs fault detection from different levels and fuses the fault detection results, the complementarity of information between different levels can be fully utilized, which is conducive to improving the accuracy of the final fusion detection result.

[0009] In a possible implementation, the configuration interface is further configured to receive second service requirements input by the user, the second service requirements being configured to indicate N candidate faults of the application system, the levels corresponding to the N candidate faults being higher than any level of the at least two levels, or the levels corresponding to the N candidate faults being the highest level of the at least two levels. Then, the fusion detection result can be displayed on the result interface based on the second service requirements input by the user. The fusion detection result comprises at least one candidate fault of the N candidate faults, and the at least one candidate fault is obtained by performing layer-by-layer fusion on the fault detection results corresponding to the at least two levels in a direction from low level to high level according to the topology relationship.

[0010] In this embodiment, the user can also configure N candidate faults of the final output, the level corresponding to the N candidate faults being higher than or equal to the highest level in the at least two levels, so that the cloud management platform can perform fusion layer by layer in the direction from low to high level until the level corresponding to the N candidate faults when performing hierarchical fusion. On the one hand, the user is provided with a way to configure the final output result, which can meet the personalized needs of the user and improve the flexibility of the cloud management platform. On the other hand, the hierarchical fusion from low to high level can sequentially and progressively integrate the information of each level, which is conducive to improving the fusion degree of information between levels and improving the accuracy of the final fusion detection result.

[0011] In a possible implementation, the at least two levels include a first level and a second level, the first level includes a plurality of first topology nodes, and the second level includes a plurality of second topology nodes. The fault detection results corresponding to the at least two levels include first fault detection results corresponding to the first level and second fault detection results corresponding to the second level. The fusion detection result includes third fault detection results, the third fault detection results being determined according to the topology relationship and the second fault detection results, the third fault detection results corresponding to the first level; and / or the fusion detection result includes fourth fault detection results, the fourth fault detection results being obtained by fusing the third fault detection results and the first fault detection results.

[0012] In this embodiment, some intermediate data are involved in the hierarchical fusion process, and these intermediate data can also be presented in the result interface when the fusion detection result is displayed in the result interface, so that the user can perceive more information related to hierarchical fusion, which is conducive to improving the service experience of the user. In addition, for different two levels, the fault detection results of one level can be converted to another level for fusion, and the new fault detection result is the information fused from the two levels, which is conducive to improving the accuracy of fault detection.

[0013] In a possible implementation, the third fault detection result includes a plurality of confidence levels, the first fault detection result is used to indicate fault information of the plurality of first topology nodes, and the plurality of confidence levels correspond to the plurality of first topology nodes one by one. In this embodiment, the confidence level of the fault detection result of one level is converted to the fault detection result of another level, which is equivalent to taking the detection result of one level as a verification of the fault detection result of another level to enhance the fault detection result of another level, thereby improving the accuracy and reliability of fault detection.

[0014] In a possible implementation, the second fault detection result indicates a respective fault probability of each of the second topology nodes. The third fault detection result includes one or more of: a confidence that each of the first topology nodes is fault-free, determined according to the respective fault probability of each of the second topology nodes; a confidence that each of the first topology nodes belongs to a first fault of the N candidate faults, determined according to the respective fault probability of each of the second topology nodes; a confidence that each of the first topology nodes belongs to a second fault of the N candidate faults, determined according to the respective fault probability of each of the first type of second topology nodes, the second fault affecting the operation of the first type of second topology nodes; or a confidence that each of the first topology nodes belongs to a third fault of the N candidate faults, determined according to the respective fault probability of each of the second type of second topology nodes, the third fault affecting the operation of the second type of second topology nodes. In this implementation, the first fault detection result is used to indicate a fault classification to which each of the first topology nodes belongs, and the first fault detection result can be enhanced by converting the fault probability of the second topology nodes that have a topology relationship with each of the first topology nodes into a confidence that each of the first topology nodes belongs to a fault classification, thereby improving the accuracy and reliability of fault detection.

[0015] In a possible implementation, the configuration interface is further configured to receive data indicator configuration information input by the user, the data indicator configuration information being used to indicate data indicators required to be collected for the topology nodes in each of the plurality of levels. Then, the operation data of the topology nodes in the application system can be acquired according to the data indicator configuration information. In this implementation, the user is provided with a way of configuring the required data indicators, and the accuracy of the required data indicators can be improved by the way of user configuration, thereby further improving the accuracy of fault detection in combination with more accurate operation data.

[0016] In a possible implementation, the configuration interface is further configured to receive a data indicator configuration file input by the user, the data indicator configuration file including the data indicator configuration information; or the configuration interface is further configured to display a plurality of data indicators and receive a data indicator selected by the user from the plurality of data indicators, the data indicator configuration information including the data indicator selected by the user. In this implementation, the user is provided with a plurality of ways of configuring the required data indicators, and the user can select a specific way according to the user's own needs, thereby improving the user experience.

[0017] In a possible implementation, the configuration interface is configured to display a plurality of levels, and receive at least two levels selected by the user from the plurality of levels; or, the configuration interface is configured to receive at least two fault detection methods input by the user, where each fault detection method is configured to obtain a fault detection result corresponding to one of the at least two levels. In this implementation, the user is provided with multiple ways of configuring the levels required for detection, and can select a specific way according to the user's own needs, thereby improving the user experience.

[0018] In a possible implementation, the configuration interface is configured to receive at least two fault detection methods input by the user, including one or more of the following: the configuration interface is configured to receive at least one expert rule input by the user, where each expert rule is configured to obtain a fault detection result corresponding to one level; or, the configuration interface is configured to receive at least one fault detection model input by the user, where each fault detection model is configured to obtain a fault detection result corresponding to one level according to a corresponding fault detection method after being trained by a training method corresponding to the fault detection model. In this implementation, the configuration process can be performed differently according to the type of fault detection method, thereby improving the accuracy of the configuration process.

[0019] In a possible implementation, the configuration interface is configured to receive system configuration information of the application system input by the user, including: the configuration interface is configured to receive a system configuration file input by the user, where the system configuration file includes the system configuration information; or, the configuration interface is configured to receive an editing operation input by the user, where the editing operation is configured to edit the topology nodes and edit the topology relationship between the topology nodes. In this implementation, the user is provided with multiple ways of configuring the system configuration information, and can select a specific way according to the user's own needs, thereby improving the user experience.

[0020] In a possible implementation, the fusion detection result of the application system is displayed on a result interface of the fault detection service, including: a topology relationship diagram of the application system is displayed on the result interface; and a topology node of a fault in the application system is marked in the topology relationship diagram according to the fusion detection result. In this implementation, the fault result can be marked in the topology relationship diagram, and the user can more intuitively perceive the location of the fault of the application system, thereby improving the user experience.

[0021] In a second aspect, a cloud service-based fault detection method is provided, which can be applied to a cloud management platform. The cloud management platform is configured to manage an infrastructure providing cloud services, the infrastructure including a plurality of regions, each region including at least one cloud data center, and the cloud services running on at least one server of at least one cloud data center located in one of the plurality of regions. The method includes: providing a configuration interface of a fault detection service, the configuration interface being configured to receive a topology type of an application system and third service requirements input by a user, the third service requirements indicating N fault types of the application system, N being a positive integer greater than 1; obtaining running data of the application system; and determining at least two fault detection results according to the running data using at least two fault detection methods, each fault detection result corresponding to one fault detection method; wherein, under each fault type of the topology type, the at least two fault detection methods have corresponding priorities, respectively; and displaying a fusion detection result of the application system on a result interface of the fault detection service, the fusion detection result being obtained by fusing the at least two fault detection results according to the priorities of the at least two fault detection methods, respectively.

[0022] In the method, under each fault type of the topology type of the application system, the at least two fault detection methods have corresponding priorities, respectively. The cloud management platform can fuse the obtained at least two fault detection results according to the priorities to obtain a final fusion detection result. On the one hand, the cloud management platform realizes comprehensive decision-making on the at least two fault detection results by the method, solving the problem that the comprehensive decision-making cannot be made under different fault detection results. On the other hand, the priorities are determined by the topology type, the fault type, and the fault detection method, etc. In other words, the applicability of each fault detection method to the fault detection of the current application system is evaluated. Then, the fusion of the fault detection results according to the evaluation results can improve the accuracy of the final fusion detection result.

[0023] In a possible implementation, the configuration interface is further configured to display a plurality of faults of a fault mode library, and receive M faults selected by a user from the plurality of faults, M being a positive integer greater than 1; wherein, each fault type of the N fault types corresponds to at least one fault of the fault mode library. The method further includes: obtaining fault exercise data of the application system running a plurality of fault samples, the plurality of fault samples corresponding to the M faults, and the fault exercise data being configured to determine a reference detection result of the application system; and displaying a fault exercise result on the configuration interface, the fault exercise result including the priorities of the at least two fault detection methods under each fault type of the topology type, respectively, and the fault exercise result being determined according to the reference detection results of the at least two fault detection methods, respectively.

[0024] In this embodiment, the application system can be subjected to fault simulation in combination with M faults selected by the user from the fault mode library, and the priority of each fault detection method under each fault type of the topology type is determined in combination with the result of the fault simulation, that is, the priority corresponding to each fault detection method is obtained in combination with the prior experience, which helps to improve the accuracy of the final fusion detection result. In addition, the M faults are configured by the user, and since the user is more familiar with the application system and the needs of the user, the configuration by the user can improve the pertinence of the fault simulation, and thus the priority corresponding to each fault detection method can be more accurately determined.

[0025] In a possible implementation, each fault detection result of the at least two fault detection results indicates a probability of a fault type to which the application system belongs. The fusion detection result includes one or more of the following: a weight of each fault type in the multiple fault types indicated by the at least two fault detection results, the weight of each fault type being determined according to the probability of the fault type indicated by the at least two fault detection results and the corresponding priority; or, a fault type with the maximum weight in the multiple fault types.

[0026] In this embodiment, some intermediate data are involved in the fusion process, and when the fusion detection result is displayed on the result interface, the intermediate data can also be presented on the result interface, so that the user can perceive more information related to the hierarchical fusion, which is beneficial to improve the service experience of the user. In addition, the fusion of the at least two fault detection results can be performed according to the probability of the fault detection result itself (which can be understood as the credibility of the fault detection method itself) in combination with the priority based on the prior experience, which is beneficial to improve the accuracy of fault detection.

[0027] In a possible implementation, the configuration interface is further configured to receive data index configuration information input by the user, and the data index configuration information is used to indicate a data index required to be collected for the application system. The running data of the application system at runtime is obtained according to the data index configuration information. In this embodiment, the user is provided with a way to configure the data index required to be collected, and since the user is more familiar with the application system, the accuracy of the data index required to be collected can be improved by the configuration of the user, and thus the accuracy of fault detection can be further improved in combination with more accurate running data.

[0028] In a possible implementation, the configuration interface is further configured to receive at least two fault detection methods configured by the user. In this embodiment, the user is provided with a way to configure the fault detection methods required to be used, which is beneficial to improve the accuracy of fault detection.

[0029] In a third aspect, a cloud service-based fault detection apparatus is provided, which can be applied to a cloud management platform for managing an infrastructure providing cloud services, the infrastructure comprising a plurality of regions, each region comprising at least one cloud data center, the cloud services running on at least one server of at least one cloud data center located in one of the plurality of regions.

[0030] The apparatus comprises: a service configuration module configured to provide a configuration interface of the fault detection service, the configuration interface being configured to receive system configuration information of an application system and first service requirements input by a user, the application system adopting a hierarchical architecture comprising a plurality of levels, the plurality of levels comprising a plurality of topology nodes, each topology node being located in one of the plurality of levels, the system configuration information being configured to indicate a topology relationship between the plurality of topology nodes, the first service requirements being configured to indicate that fault detection is performed on at least two levels of the plurality of levels; a data acquisition module configured to acquire running data of the plurality of topology nodes of the application system, the running data of the plurality of topology nodes being configured to determine fault detection results corresponding to the at least two levels; and a result display module configured to display a fusion detection result of the application system on a result interface of the fault detection service, the fusion detection result being obtained by fusing the fault detection results corresponding to the at least two levels according to the topology relationship.

[0031] In a possible implementation, the configuration interface is further configured to receive second service requirements input by the user, the second service requirements being configured to indicate N candidate faults of the application system, the levels corresponding to the N candidate faults being higher than any level of the at least two levels, or the levels corresponding to the N candidate faults being the highest level of the at least two levels. The result display module is specifically configured to display the fusion detection result on the result interface based on the second service requirements input by the user. The fusion detection result comprises at least one candidate fault of the N candidate faults, the at least one candidate fault being obtained by layer-by-layer fusion of the fault detection results corresponding to the at least two levels in a direction from low level to high level according to the topology relationship.

[0032] In a possible implementation, the at least two levels comprise a first level and a second level, the first level comprising a plurality of first topology nodes, and the second level comprising a plurality of second topology nodes. The fault detection results corresponding to the at least two levels comprise a first fault detection result corresponding to the first level and a second fault detection result corresponding to the second level. The fusion detection result comprises a third fault detection result corresponding to the first level, the third fault detection result being determined according to the topology relationship and the second fault detection result; and / or the fusion detection result comprises a fourth fault detection result, the fourth fault detection result being obtained by fusion of the third fault detection result and the first fault detection result.

[0033] In a possible implementation, the third fault detection result includes a plurality of confidence levels, and the first fault detection result is used to indicate fault information of the plurality of first topology nodes, and the plurality of confidence levels correspond to the plurality of first topology nodes one by one.

[0034] In a possible implementation, the second fault detection result indicates respective fault probabilities of the plurality of second topology nodes. The third fault detection result includes one or more of the following: a confidence level of each first topology node being fault-free determined according to the respective fault probabilities of the plurality of second topology nodes; a confidence level of each first topology node belonging to a first fault of the N candidate faults determined according to the respective fault probabilities of the plurality of second topology nodes; a confidence level of each first topology node belonging to a second fault of the N candidate faults determined according to respective fault probabilities of second topology nodes of a first type in the plurality of second topology nodes, the second fault affecting operation of the second topology nodes of the first type; or a confidence level of each first topology node belonging to a third fault of the N candidate faults determined according to respective fault probabilities of second topology nodes of a second type in the plurality of second topology nodes, the third fault affecting operation of the second topology nodes of the second type.

[0035] In a possible implementation, the configuration interface is further configured to receive data indicator configuration information input by the user, and the data indicator configuration information is used to indicate data indicators required to be collected for topology nodes in each level in the plurality of levels. The data acquisition module is specifically configured to acquire operation data of the plurality of topology nodes of the application system at runtime according to the data indicator configuration information.

[0036] In a possible implementation, the configuration interface is further configured to receive a data indicator configuration file input by the user, and the data indicator configuration file includes the data indicator configuration information; or the configuration interface is further configured to display a plurality of data indicators, and receive a data indicator selected by the user from the plurality of data indicators, and the data indicator configuration information includes the data indicator selected by the user.

[0037] In a possible implementation, the configuration interface is configured to display a plurality of levels, and receive at least two levels selected by the user from the plurality of levels; or the configuration interface is configured to receive at least two fault detection methods input by the user, and each fault detection method is used to obtain a fault detection result corresponding to one level in the at least two levels.

[0038] In a possible implementation, the configuration interface is configured to receive at least one expert rule input by the user, and each expert rule is used to obtain a fault detection result corresponding to one level; or the configuration interface is configured to receive at least one fault detection model input by the user, and each fault detection model is used to obtain a fault detection result corresponding to one level according to a corresponding fault detection method after each fault detection model is trained by using a training method corresponding to the fault detection model.

[0039] In a possible implementation, the configuration interface is configured to receive a system configuration file input by a user, the system configuration file comprising system configuration information; or the configuration interface is configured to receive an editing operation input by a user, the editing operation being used to edit the topology nodes and the topology relationship between the topology nodes.

[0040] In a possible implementation, the result display module is specifically configured to display a topology relationship diagram of the application system on a result interface; and mark the faulty topology nodes in the application system in the topology relationship diagram according to the fusion detection result.

[0041] The third aspect or any of the implementation forms of the third aspect is a step implementation of the apparatus of the first aspect or any of the implementation forms of the first aspect, and the description in the first aspect or any of the implementation forms of the first aspect is applicable to the third aspect or any of the implementation forms of the third aspect, and will not be repeated here.

[0042] In a fourth aspect, a cloud service-based fault detection apparatus is provided, which can be applied to a cloud management platform, the cloud management platform being configured to manage an infrastructure providing cloud services, the infrastructure comprising a plurality of regions, each region comprising at least one cloud data center, and the cloud services being run on at least one server of at least one cloud data center located in one of the plurality of regions.

[0043] The apparatus comprises: a service configuration module configured to provide a configuration interface of a fault detection service, the configuration interface being configured to receive a topology type of an application system and a third service requirement input by a user, the third service requirement indicating N types of faults of the application system, N being a positive integer greater than 1; a data acquisition module configured to acquire running data of the application system; a detection execution module configured to determine at least two fault detection results according to the running data by using at least two fault detection methods, each fault detection result corresponding to one fault detection method; wherein, under each type of fault of the topology type, the at least two fault detection methods have corresponding priorities respectively; and a result display module configured to display a fusion detection result of the application system on a result interface of the fault detection service, the fusion detection result being obtained by fusing the at least two fault detection results according to the priorities of the at least two fault detection methods respectively.

[0044] In a possible implementation, the configuration interface is further configured to display a plurality of faults in the fault mode library, and receive M faults selected by the user from the plurality of faults, M being a positive integer greater than 1; each fault type in the N fault types corresponds to at least one fault in the fault mode library. The apparatus further includes a fault simulation module configured to obtain fault simulation data of the application system running a plurality of fault samples, the plurality of fault samples corresponding to the M faults, and the fault simulation data being used to determine a reference detection result of the application system. The service configuration module is further configured to display the fault simulation result on the configuration interface, the fault simulation result including a priority of each fault detection method under each fault type of the topology type, and the fault simulation result being determined according to the reference detection result corresponding to each fault detection method.

[0045] In a possible implementation, each fault detection result in the at least two fault detection results indicates a probability of a fault type to which the application system belongs. The fused detection result includes one or more of the following: a weight of each fault type in the plurality of fault types indicated by the at least two fault detection results, the weight of each fault type being determined according to the probability of the fault type indicated by the at least two fault detection results and the corresponding priority; or, a fault type with the largest weight in the plurality of fault types.

[0046] In a possible implementation, the configuration interface is further configured to receive data index configuration information input by the user, the data index configuration information being used to indicate a data index required to be collected for the application system. The data acquisition module is specifically configured to acquire the running data of the application system running according to the data index configuration information.

[0047] In a possible implementation, the configuration interface is further configured to receive at least two fault detection methods configured by the user.

[0048] The fourth aspect or any of the possible implementation manners of the fourth aspect is a step implementation of the apparatus of the second aspect or any of the possible implementation manners of the second aspect, and the description in the second aspect or any of the possible implementation manners of the second aspect is applicable to the fourth aspect or any of the possible implementation manners of the fourth aspect, and will not be repeated here.

[0049] In a fifth aspect, a computing device cluster is provided, including at least one computing device, each computing device including a processor and a memory. The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster executes the method disclosed in the first aspect and any of the possible implementation manners of the first aspect, or executes the method disclosed in the second aspect and any of the possible implementation manners of the second aspect.

[0050] In a sixth aspect, the present application provides a computer program product comprising instructions which, when executed by a computer device cluster, cause the computer device cluster to implement the method disclosed in the first aspect and any possible implementation of the first aspect, or perform the method disclosed in the second aspect and any possible implementation of the second aspect.

[0051] In a seventh aspect, the present application provides a computer-readable storage medium comprising computer program instructions, which, when executed by a computer device cluster, cause the computer device cluster to implement the method disclosed in the first aspect and any possible implementation of the first aspect, or perform the method disclosed in the second aspect and any possible implementation of the second aspect. BRIEF DESCRIPTION OF DRAWINGS

[0052] FIGS. 1A-1D are schematic diagrams of system architectures provided by embodiments of the present application;

[0053] FIG. 2 is a schematic diagram of a method provided by an embodiment of the present application;

[0054] FIGS. 3A-3E are schematic diagrams of interfaces provided by embodiments of the present application;

[0055] FIGS. 4A and 4B are schematic diagrams of fusion of fault detection results provided by embodiments of the present application;

[0056] FIG. 5 is a schematic diagram of hierarchical fusion provided by an embodiment of the present application;

[0057] FIG. 6 is a schematic diagram of another method provided by an embodiment of the present application;

[0058] FIGS. 7A-7D are example diagrams of topology types provided by embodiments of the present application;

[0059] FIG. 8 is a schematic diagram of a process of determining priority provided by an embodiment of the present application;

[0060] FIG. 9 is a schematic diagram of the structure of an apparatus provided by an embodiment of the present application;

[0061] FIG. 10 is a schematic diagram of the structure of another apparatus provided by an embodiment of the present application;

[0062] FIG. 11 is a schematic diagram of the structure of a computing device provided by an embodiment of the present application;

[0063] FIG. 12 is a schematic diagram of a computer device cluster provided by an embodiment of the present application. DETAILED DESCRIPTION

[0064] In order to make the purposes, technical solutions and advantages of the embodiments of the present application clearer, the following will further describe the embodiments of the present application in detail with reference to the drawings. In the description of the embodiments of the present application, the terms "first", "second" are only used for the purpose of description, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined with "first", "second" can be explicitly or implicitly included one or more of the features.

[0065] It should be understood that "at least one" in the embodiments of the present application means one or more, and "multiple" means two or more. The association relationship of the associated objects is described, which means that there can be three kinds of relationships, for example, A and / or B can mean that A exists alone, A and B exist together, and B exists alone, where A and B can be singular or plural. The character " / " generally represents an "or" relationship between the associated objects before and after it. "At least one of the following" or similar expressions means any combination of these items, including any combination of single item or multiple items. For example, at least one of a, b or c can mean a, b, c, a and b, a and c, b and c, or a, b and c, where a, b and c can be single or multiple.

[0066] An application system refers to a computer system specially designed for a certain specific application field or business requirement, which can complete a specific task or solve a specific problem. An application system is usually composed of application programs (or software parts), system resources (or hardware parts), and databases, etc. The application program is responsible for implementing the main functions of the system, such as processing data, performing calculations, generating reports, etc. The system resource refers to the physical resource required to support the operation of the application program, and the database is used to store, manage and retrieve the data required by the application program. Application systems can be widely used in various fields, such as enterprise management, financial services, medical care or education, etc., and can help improve work efficiency, optimize business processes and achieve data analysis, etc.

[0067] Due to the wide implementation of distributed technology, the scale of application systems is increasingly large, which increases the complexity and uncertainty of the fault localization process of the application system, and increases the difficulty of fault localization. In order to improve the accuracy of the application system, a variety of fault localization methods are often used to perform fault localization, and the results of the various fault localization methods are combined to obtain the final fault localization result. For example, the voting method or the method of training a new model to fuse the results of different fault localization methods is currently used, but these comprehensive decision methods are often based on the assumption that the output forms of the various fault localization methods are consistent. For example, the current comprehensive decision method can only be used in the case where the fault granularity indicated by the results of the various fault localization methods is the same, so these comprehensive decision methods can be used for application systems with relatively simple architecture topology.

[0068] However, for an application system of a more complex distributed architecture topology, modeling needs to be performed from different perspectives, which may result in different fault information determined by different fault bounding methods, for example, different output forms of fault information (for example, fault granularity) or conflicts of fault information. The current comprehensive decision method cannot comprehensively integrate the results of multiple fault bounding methods.

[0069] In view of this, the embodiment of the present application provides a fault detection method based on cloud services, which is used to solve the comprehensive decision problem when multiple fault bounding methods are used to detect faults of an application system.

[0070] In some scenarios, the application system can also be replaced by a computer cluster, a distributed computing cluster, a cloud computing cluster, a data center, a cloud data center, or other names, and no specific limitation is made.

[0071] Please refer to FIG. 1A, which is a schematic diagram of an application scenario of the method provided by the embodiment of the present application. The scenario can include a cloud management platform 100, which is used to manage multiple cloud data centers set by a cloud vendor in different regions. The cloud management platform can provide an interface related to a public cloud service, such as a page or an application program interface (API), for a user to remotely access the public cloud service. The user can log in to the cloud management platform through a pre-registered account password on a public cloud access page, and after successful login, select and purchase a public cloud service provided by a cloud data center in a region selected by the user on the public cloud access page, such as an object storage service, a virtual machine service, a container service, or a fault detection service related to the embodiment of the present application.

[0072] The cloud management platform 100 is used to manage the infrastructure providing the cloud service, and the infrastructure includes multiple regions (Region), each region including at least one cloud data center, and the cloud service running on at least one server of at least one cloud data center located in one of the multiple regions. A region refers to a geographical location of the cloud service, and the cloud service can be divided from the dimensions of geographical location and network latency through the region. The cloud services in the same region use infrastructure located in the same geographical location, for example, a cloud service selected region is set to South China, and the cloud service is provided by a cloud data center in the South China region. A region can include one or more availability zones (AZ), and an AZ is a collection of one or more cloud data centers with independent water and electricity. The resources such as computing, network, and storage in the availability zone are logically divided into multiple clusters. The multiple availability zones in a region are connected through high-speed optical fibers to meet the needs of users to build high-availability systems across AZs.

[0073] Referring to FIG. 1A, the cloud management platform 100 can provide a client 400, which can be used to display an interface of the fault detection service, and a user 500 can configure the fault detection service of the application system 200 and view the results through the interface of the fault detection service. For example, the user 500 can configure the service requirements of the fault detection service and the system configuration information of the application system 200 through the interface of the fault detection service, and in addition, the user can also view the fault detection results through the interface of the fault detection service. Optionally, the client 400 can be implemented through a terminal device or a functional module (such as a webpage or an application) in the terminal device, for example, the terminal device can be a personal computer (PC), a tablet computer (PAD), or a mobile phone, and the like, and the specific implementation is not limited.

[0074] For example, in the scenario shown in FIG. 1A, the user 500 can access the cloud management platform 100 through the client 400 via the Internet 300, and the user 500 can purchase a device fault detection service for the application system 200 in the cloud management platform 100. The user 500 can input / choose the related configuration information of the application system 200 and the service requirements in the cloud management platform 100 through the client 400, and the cloud management platform can run the fault detection service for the application system 200 according to the related configuration information of the user 500 and the service requirements. As shown in FIG. 1A, taking the cloud data center A-Region 1 as an example, the user 500 inputs the related configuration information of the application system 200 and the service requirements in the cloud management platform 100, and the application system 200 of the user 500 will be implemented by the cloud data center A in Region 1 to perform the fault detection service. Specifically, the application system 200 accesses the cloud data center A in Region 1 via the Internet through the cloud management platform 100. It should be noted that which cloud data center in which region serves the application system 200 of the user 500 can be that the user 500 selects the cloud data center serving the application system 200 of the user 500 through the cloud management platform 100, or the cloud management platform 100 randomly allocates the cloud data center serving the application system 200 of the user 500 without selection by the user 500. Herein, the allocation manner of the cloud data center serving the application system 200 is not limited.

[0075] The cloud management platform 100 can also be referred to as a fault detection platform or a fault detection system, which is used to provide the fault detection service for the application system 200. Optionally, the fault detection service can be a fault bounding service for the application system 200, and the cloud management platform 100 can also be referred to as a fault bounding system. In some scenarios, the cloud management platform 100 can also provide other fault detection services, such as fault positioning, root cause positioning, and the like, and thus the cloud management platform 100 can also be referred to as a fault positioning system or a root cause positioning system, and the like, and the specific implementation is not limited.

[0076] In some embodiments, the cloud management platform 100 can be independent of the application system 200, i.e. the resources relied on by the cloud management platform 100 and the application system 200 are irrelevant to each other, and the cloud management platform 100 can acquire the data required for the application system 200 fault detection, such as the running data of the application system 200, to perform fault detection on the application system 200 based on the data. Alternatively, the cloud management platform 100 can be a cloud management platform 100 dedicated to the application system 200, or the cloud management platform 100 can also be a cloud management platform 100 shared by multiple application systems 200, i.e. the cloud management platform 100 can provide fault detection services for multiple application systems 200.

[0077] In some embodiments, the cloud management platform 100 and the application system 200 can belong to the same system, i.e. the cloud management platform 100 and the application system 200 can rely on the same system resources to implement. For example, the cloud management platform 100 can be a part of the application system 200, or the application system 200 can be a part of the cloud management platform 100. That is, in this embodiment, the cloud management platform 100 can directly acquire the data required for fault detection in the application system 200, such as the running data of the application system 200, to perform fault detection on the application system 200 based on the data.

[0078] For example, when the cloud management platform 100 performs fault detection on the application system 200 based on the acquired running data of the application system 200, a variety of fault detection methods can be used to obtain corresponding fault detection results respectively, so as to realize comprehensive decision of multiple fault detection results by using the method provided in the embodiments of the present application.

[0079] The cloud management platform 100 in the embodiments of the present application can be implemented by software or by hardware. For example, one example of the cloud management platform 100 implemented by software is that the cloud management platform 100 can include code running on a computing instance. The computing instance can be at least one of a physical host (computing device), a virtual machine, a container, and the like. Optionally, the above computing device can be one or more. For example, the cloud management platform 100 can include code running on multiple hosts / virtual machines / containers. For another example, one example of the cloud management platform 100 implemented by hardware is that the cloud management platform 100 can include at least one computing device, such as a server and the like. Alternatively, the cloud management platform 100 can also be a device implemented by an application-specific integrated circuit (ASIC) or a programmable logic device (PLD), and the like. The above PLD can be implemented by a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof. The computing device included in the cloud management platform 100 can be referred to as a fault detection device. The fault detection device can also be referred to as a fault locating device, a fault determining device, or a root cause locating device, without specific limitation.

[0080] The application system 200 is configured to provide infrastructures required by applications (or services), which are arranged in at least one region, wherein each region includes at least one cloud data center (or database). In other words, the application system 200 is configured to provide background services of the applications (or services). The application system 200 according to the embodiments of the present application can adopt any possible architecture topology.

[0081] As one possible example, referring to FIG. 1B, a schematic diagram of one topology of the application system 200 provided by the embodiments of the present application is shown. Referring to FIG. 1B, the architecture topology of the application system 200 can include a combination of a resource vertical topology and an application horizontal topology. The resource vertical topology can be understood as a dependency relationship between system resources, that is, the resource vertical topology is an architecture topology divided from the hierarchy of system resources. The application horizontal topology can be understood as an architecture topology divided according to the hierarchy of application programs (or components).

[0082] According to the resource vertical topology, the application system 200 can include the following:

[0083] (1) Region, a region is a geographical collection of data centers, through region, users can help distribute system resources in different geographical locations to improve disaster recovery capabilities and reduce latency. For example, for an application system 200 that exists in multiple regions, the region of the application system 200 can refer to the geographical location where the system resources of the application system 200 are located. The background services in the same region use infrastructure located in the same geographical location. For example, a service in an application system 200 selects a region in South China, and then uses system resources in the South China region to provide the service.

[0084] (2) Availability Zone (AZ): Each region can contain one or more AZs. Each AZ is a cluster of one or more data centers with independent power, network, and cooling systems, ensuring high availability and fault tolerance. By distributing applications across different AZs, users can achieve higher redundancy and reliability.

[0085] (3) Host Group: Each AZ can include one or more host groups. Each host group is a collection of physical machines, usually used for centralized management and configuration to simplify resource deployment and maintenance.

[0086] (3) Physical Machine (PM): Each host group includes one or more physical machines. For example, a physical machine can be an actual hardware server. Unlike virtual machines, a physical machine does not have a virtualization layer and directly runs an operating system and applications. Physical machines can provide complete hardware resources and provide direct hardware access and control.

[0087] (4) Virtual Machine (VM): A physical machine can include one or more VMs. Virtual machines are virtualized instances created and run through virtualization technology, allowing multiple virtual machines to share the same hardware resources. Each virtual machine has an independent operating system and application environment. Each virtual machine can run one or more containers, such as the application container shown in FIG. IB. Application containers can be used to run application programs corresponding to the application system 200.

[0088] (5) Bare metal server (BMS), also known as single-tenant environment physical server, composed of one or more independent servers, is a computing service with the performance of elastic cloud server and physical machine, which can provide dedicated physical server on the cloud for enterprises, and provide excellent computing performance and data security for core database, key application system 200, high-performance computing, big data and other businesses. One or more containers can run on each BMS, such as the database container shown in FIG. IB, which can be used to implement the database-related functions corresponding to the application system 200.

[0089] According to the application level topology, the application system 200 can include the following:

[0090] (1) Application business, one application system 200 can provide one or more application businesses. For example, the application system 200 is a financial system, and one application business can be a deposit business or a lending business, etc.; or the application system 200 is an education system, and one application business can be a course selection business or an online course business, etc.; or the application system 200 can be a delivery system, and one application business can be a delivery business or a running errands business, etc., which is not limited.

[0091] (2) Microservice, also known as service group, middleware, etc., one application business can be implemented through the combination of one or more microservices. Microservice is essentially a software architecture pattern, in which the application business can be split into small, independently deployable services, each responsible for a specific business function. Each microservice usually has its own database and business logic, and can be developed, deployed and expanded independently.

[0092] (3) Component, also known as unit, business unit, service unit or microservice unit, etc., one microservice can include one or more components. A component usually refers to a modular part within a single application, and a component can be understood as a function under a microservice.

[0093] (4) Basic module, one component can include one or more basic function modules. The basic module can be understood as the smallest functional unit in an application system 200.

[0094] (5) Container, Container is a lightweight, portable virtualization technology, used to package and run applications and their dependencies, through the container can provide a consistent running environment, so that the application can be run consistently in different systems and environments. As shown in FIG. 1B, the container according to the different functions of the embodiment of the present application can be divided into database container and application container. The database container can be used to implement the database related functions corresponding to the application system 200, and different database containers can be divided according to the different stored data. For example, the database container A is used to store and detect the data of users 1-100, and the database container B is used to store and detect the data of users 101-200. The application container can be used to run the application program corresponding to the application system 200, and the application programs running in different application containers can be the same or different.

[0095] The above-mentioned A includes B can be understood as B is a component of A, or the implementation of A depends on B, or the implementation of B depends on A, or B is deployed on A, etc.

[0096] Referring to FIG. 1C, it is a system architecture schematic diagram of the cloud management platform 100 provided by the embodiment of the present application. Wherein, the cloud management platform 100 can include service purchase related functions, service configuration related functions and service usage related functions. The following will be introduced respectively.

[0097] I. Service purchase related functions, which can be used to provide users with functions related to the purchase of fault detection services. As shown in FIG. 1C, the service purchase related functions can include a service purchase module. For example, the service purchase module can provide a service purchase interface to the user, and the user can purchase fault detection services according to the prompts in the service purchase interface. Correspondingly, the service purchase module will also perform corresponding processing after the user purchases the fault detection service, such as storing the order information of the user, etc.

[0098] II. Service configuration related functions, which can be used to provide users with functions related to the configuration of fault detection services, or to configure functions related to fault detection services according to the user's instructions. After the fault detection service is configured, it can execute the fault detection process according to the configured content. As a possible example, as shown in FIG. 1C, the service configuration related functions can include the following modules:

[0099] (1) Resource configuration module, which is used to configure the physical resources used by the fault detection service, which can include computing resources and storage resources, etc. After the configuration through the resource configuration module, the fault detection service can be deployed on the corresponding resources and utilize these resources to implement the fault detection service.

[0100] Optionally, the resource configuration module can provide a resource configuration page through which a user can input resources of the fault detection service. For example, the user can input resource requirements of the fault detection service, such as the number or type of resources, etc. Alternatively, the user can be provided with selectable resources through the resource configuration page, and can select resources required for deployment of the fault detection service from the selectable resources.

[0101] (2) a basic configuration module, which can be used to configure basic information of the fault detection service, which can also be understood as basic configuration information of the application system. Optionally, the basic information can include faults of the application system, i.e., faults of the application system that the fault detection eventually needs to output. The faults of the application system can be various faults or various fault types. Optionally, the faults of the application system can be configured according to actual conditions of the application system and user's own requirements. For example, if the fault detection refers to fault delimitation of the application system, then the faults of the application system can be determined according to a fault range for fast recovery or a means for fast recovery.

[0102] Optionally, the basic configuration module can provide a basic configuration page through which a user can input various faults of the application system. For example, the user can input various fault-related information, such as fault names and introductions of the faults, etc. Alternatively, the user can be provided with selectable various faults through the basic configuration page, and can select faults of the application system from the selectable various faults. Alternatively, the user can be shown a topology relationship diagram of the application system through the basic configuration page, and can specify topology nodes of possible faults of the application system in the topology relationship diagram, and a fault of a topology node can be considered as a fault.

[0103] (3) an index management module, which can be used to configure and manage data indexes required to be collected by the application system, so that running data can be collected according to the configured data indexes when the application system runs, and subsequent fault detection can be performed according to the running data. The data indexes can be understood as running characteristics of the application system, and the faults of corresponding topology nodes in the application system can be reflected through the running characteristics. As shown in FIG. IB, the application system can adopt a hierarchical architecture, i.e., the architecture of the application system can include multiple levels, and topology nodes included in the application system can be distributed on different levels, so that the index management module can be used to configure or manage data indexes required to be collected by different levels, and the topology nodes of different levels can be different, and thus the data indexes required to be collected by different levels can be different.

[0104] Optionally, the index management module can provide a configuration file uploading interface for the user, and the user can upload a data index configuration file through the configuration file uploading interface, the data index configuration file can include the data index required to be collected by the application system. Optionally, the index management module can provide an index configuration page, and the user can select or configure the data index required to be collected by the application system through the index configuration page.

[0105] (4) The rule management module, which can also be referred to as a rule engine, can be used to configure and manage the expert rules used in fault detection. The expert rules refer to the overall judgment of the application system based on certain rules to determine the fault of the application system. Among them, the expert rules refer to the rules formed based on the summary of past experience, and the combination of running data and expert rules can judge the fault in the application system. For example, the expert rules can form expert rules according to the business index of the park level and the summary of the experience of operation and maintenance experts, and then judge the fault of the application system from the application as a whole.

[0106] Optionally, the rule management module can provide a rule selection page, and the expert rules selected by the user can be displayed through the rule selection page. The user can select among these expert rules, and then configure the expert rules required to be used by the application system in fault detection according to the user's selection.

[0107] (5) The model management module can be used to configure and manage the fault detection model required to be used in fault detection. Optionally, the fault detection model can be a neural network model, and each fault detection model can output a corresponding fault detection result according to the input running data of the application system. Optionally, different fault detection models can be used to output fault detection results corresponding to different levels. Optionally, different fault detection models use different fault detection methods.

[0108] In an implementation, the model management module can provide a model selection page, which can display fault detection models selectable by a user, and the user can select a desired model in the model selection page. In another implementation, the user can also input a model requirement, which can indicate the user's requirements for the desired model or the requirements for the fault detection of the application system, and the model management module can match the most suitable fault detection model for the user according to the model requirement. In yet another implementation, there is a certain correspondence between the models and the levels of the application system. For example, different fault detection models can be used to perform fault detection for different levels, and the user can specify the level for which fault detection is required, and then the corresponding fault detection model can be determined according to the correspondence. When there are multiple fault detection models applicable to each level, one or more of the models can be specified by the user as the fault detection model for the level, or one or more of the models can be determined as the fault detection model for the level according to a model index (e.g., accuracy).

[0109] (6) The topology management module can be used to configure and manage the topology relationship between the topology nodes included in the application system. Optionally, the topology management module can provide a configuration file upload interface through which the user can upload a system configuration file, and the system configuration file can include system configuration information, which can indicate the topology relationship between the topology nodes in the application system. Alternatively, the topology management module can also provide a system configuration editing page, and the user can edit the topology nodes and the topology relationship between the topology nodes in the system configuration editing page, such as adding topology nodes and editing the topology relationship between pairs of topology nodes.

[0110] The embodiments of the present application do not limit the specific configuration of each of the above modules.

[0111] III. Related functions during service use, which can be used to provide related functions during the use of the fault detection service by the user. As shown in FIG. 1C, the service configuration related functions can include the following modules:

[0112] (1) The detection execution module, which is used to perform the fault detection process. For example, the detection execution module can perform fault detection on the application system according to the method provided by the embodiments of the present application, obtain multiple fault detection results, and fuse the multiple fault detection results to obtain the final fused detection result of the application system. Specifically, when the obtained multiple fault detection results are fault detection results for different levels, the embodiments of the present application can fuse the multiple fault detection results according to the topology relationship between the topology nodes in the application system to finally obtain the fused detection result corresponding to one level. In this way, by fusing the fault detection results for different levels, the accuracy of the fault detection of the application system can be improved.

[0113] (2) Detection result module, which can be used to provide a user with a display function of a detection process when providing a fault detection service to the user, and a display function of a fault detection result, such as a final fusion detection result or an intermediate detection result obtained in a fault detection process. As shown in FIG. 1C, the related function when the service is used can include a detection result module. For example, the detection result module can provide a user with a display interface of a fault detection process, and can display a detection progress of the fault detection process and other data involved in the fault detection process. Alternatively, the detection result module can also provide a user with a display interface of a fault detection result, so that the user can view the fault detection result.

[0114] The functions of the above-mentioned modules can be further split into different sub-modules, or the functions of multiple modules in the above-mentioned modules can be combined into one block, and the embodiments of the present application do not make specific limitations thereto.

[0115] Referring to FIG. 1D, another architecture schematic diagram of the cloud management platform 100 provided by the embodiments of the present application is shown. The cloud management platform 100 can include service purchase related functions, service configuration related functions and service use related functions. The following will be introduced respectively.

[0116] I. Service purchase related functions, which can be used to provide a user with functions related to purchasing a fault detection service. For the introduction of the service purchase related functions, please refer to the introduction in FIG. 1C, which will not be described in detail.

[0117] II. Service configuration related functions, which can be used to provide a user with functions related to configuring a fault detection service, or to configure functions related to a fault detection service according to the indication of a user. After the fault detection service is configured, the fault detection process can be executed according to the configured content. As a possible example, as shown in FIG. 1D, the service configuration related functions can include the following modules:

[0118] (1) Resource configuration module, which is used to configure resources used by a fault detection service, which can include computing resources and storage resources, etc. After the configuration through the resource configuration module, the fault detection service can be deployed on the corresponding resources, and the resources are used to implement the fault detection service.

[0119] (2) a basic configuration module, which can be used to configure basic information of the fault detection service, which can also be understood as basic configuration information of the application system. For example, the basic information can include a topology mode (or topology type) of the application system. The topology mode of the application system refers to a topology mode adopted by a system architecture of the application system. Different topology modes have different distributions of system resources, and correspondingly, different topology relationships relied on during fault detection and different detection results outputted. Optionally, the topology mode of the application system can include a single-region-single-AZ-single-database, single-region-multiple-AZ-multiple-databases, single-region-dual-AZ-primary / standby database, or dual-region-multiple-AZ-multiple-database (dual-active) topology mode. Each topology mode will be introduced at relevant positions below, and no more details are given here.

[0120] Optionally, a plurality of topology modes can be displayed in the configuration interface, and a user can select a topology mode of the application system to be fault detected from the plurality of topology modes. Alternatively, when the topology mode of the application system is not included in the displayed plurality of topology modes, the user can also create a new topology mode and edit relevant information in the topology mode.

[0121] Optionally, the basic information can also include other information of the application system, for example, the basic information can include candidate fault types of the application system, that is, one or more of the candidate fault types finally required to be outputted by the fault detection. The specific information included in the basic information is not limited.

[0122] (3) an index management module, the fault detection process relies on collected running data of the application system, and the index management module can be used to configure and manage data indexes required to be collected by the application system, so that running data can be collected according to the configured data indexes during running of the application system, and subsequent fault detection can be performed according to the running data.

[0123] (4) a method management module, which can be used to configure and manage a fault detection method used during fault detection. The fault detection method can also be referred to as a fault detection model or a fault detection scheme, etc. The method management module can provide a plurality of fault detection methods for a user to select, and the user can select a required fault detection method from the plurality of fault detection methods.

[0124] (5) A fault drill module, which can be used to configure related information when performing a fault drill, for example, a fault mode library used when performing the fault drill, and which faults in the fault mode library are drilled. After the user configures the related information when performing the fault drill, the fault drill module can perform a fault drill process according to the user's configuration. The fault drill can also be referred to as fault simulation or chaos engineering, which refers to simulating the occurrence of various faults in an application system. Through collection of fault drill data when performing the fault drill, the fault drill data can be subjected to fault detection by using a fault detection method configured by the user, to obtain a corresponding reference detection result. Then, according to the reference detection result, the priority of each fault detection method under a specific fault type in a specific topology mode (or topology type) can be determined. Subsequently, when fault detection results output by multiple fault detection methods are different, the fault detection results output by the multiple fault detection methods can be fused by using the priority of the fault detection method, to obtain a final fusion detection result.

[0125] The embodiments of the present application do not limit the specific configuration of each of the above modules.

[0126] III. Related functions when the service is used, which can be used to provide related functions when the user uses the fault detection service. As shown in FIG. 1D, the service configuration related functions can include the following modules:

[0127] (1) A detection execution module, which is used to execute a fault detection process. For example, the detection execution module can implement fault detection of an application system according to the method provided by the embodiments of the present application, obtain multiple fault detection results, and fuse the multiple fault detection results to obtain a final fusion detection result of the application system. Specifically, when the obtained multiple fault detection results are different, the embodiments of the present application can fuse the fault detection results output by the multiple fault detection methods by using the priority of the fault detection method, to obtain the final fusion detection result. In this way, the accuracy of the priority determined by prior experience obtained through an actual fault drill process is higher, and the accuracy of the fusion detection result obtained according to the priority is higher, which helps to improve the accuracy of fault detection of the application system.

[0128] (2) A detection result module, which can be used to provide a display function of a detection process and a display function of a fault detection result when the user uses the fault detection service, for example, to display the final fusion detection result or an intermediate detection result obtained in the fault detection process.

[0129] The functions of each of the above modules can be further split into different sub-modules, or the functions of multiple modules in each of the above modules can be combined into one block. The embodiments of the present application do not specifically limit this. For the same or similar modules in FIG. 1D and FIG. 1C, reference can be made to the introduction of part of FIG. 1C, which will not be described here.

[0130] In some embodiments, as the topology of the application system becomes more and more complex, the complexity of the fault detection of the application system is also increased, and it is necessary for the application system to configure a corresponding fault detection service. For example, the fault detection service needs to have the ability of fault localization to quickly localize the fault when the application system fails, so as to quickly recover the business of the application system.

[0131] In order to improve the accuracy of fault detection of the application system, fault detection needs to be performed from different dimensions, which leads to the fact that the dimensions of the fault detection results determined by different fault detection methods may be different. The dimension can also be understood as the output form (such as fault granularity) of the fault detection result. In order to solve this problem, the embodiment of the application provides a fault detection method based on cloud service. The method can perform fault detection from different levels for the application system with a layered architecture, and the method can also fuse the fault detection results of different levels to obtain the final fusion detection result. In the embodiment of the application, the fault detection can refer to fault localization, fault positioning or root cause positioning, and the following will mainly take fault detection as an example to introduce fault localization.

[0132] Referring to FIG. 2, a flowchart of the method provided by the embodiment of the application is shown. The method can be applied to the application scenario of FIG. 1A or the system architecture of FIG. 1C. The method can include the following steps:

[0133] Step 201: providing a configuration interface of a fault detection service. The configuration interface is used to receive system configuration information and first service requirements of an application system input by a user. The application system adopts a layered architecture, the layered architecture includes a plurality of levels, the plurality of levels includes a plurality of topology nodes, each topology node is located in one of the plurality of levels, the system configuration information is used to indicate a topology relationship between the plurality of topology nodes, and the first service requirement indicates that fault detection is performed on at least two levels of the plurality of levels.

[0134] The fault detection service can be understood as a cloud service provided by a cloud management platform. The cloud management platform can provide a plurality of cloud services, and a user can select and purchase cloud services required by the user. The cloud management platform can provide a purchase interface of the fault detection service. After the user logs in to the cloud management platform through an account and a password of the user, the user can purchase the fault detection service through the purchase interface in the cloud management platform. After purchasing the fault detection service, the user can view the fault detection service in the services owned by the user.

[0135] Before the application system is detected based on the fault detection service, the fault detection service needs to be configured. The cloud management platform can provide a configuration interface of the fault detection service for the user, and the user can configure the fault detection service through the configuration interface. The content input by the user during the configuration can assist in implementing the fault detection service. If the user is an old user, i.e., the user has used the fault detection service before, the historical configuration information of the user can be pulled, and the historical configuration information can be used continuously, or the user can adjust the historical configuration information to serve as the configuration information of the currently used fault detection service. For example, the historical configuration information can be displayed to the user, and the user can adjust the historical configuration information. If the user is a new user, i.e., the user has not used the fault detection service before, the user needs to add the configuration information of the user. Optionally, to help the user to configure quickly, a plurality of configuration templates can be provided for the user, and the user can select one of the configuration templates to use or adjust the configuration template to use. It should be noted that the configuration of the user for the fault detection service can be one-time, i.e., after the configuration is completed once, the information of the configuration does not need to be configured again in the subsequent service use process, and therefore, the step 201 is not necessarily performed.

[0136] In combination with FIG. 2, the cloud management platform provides a configuration interface of the fault detection service, and the user can input the system configuration information and the first service requirement of the application system through the client in the configuration interface. The client can send the system configuration information and the first service requirement of the application system input by the user to the cloud management platform.

[0137] In an embodiment of the present application, the configuration interface can be configured to receive system configuration information of an application system input by a user. The application system can adopt a hierarchical architecture, and the hierarchical architecture can include a plurality of levels, and the plurality of levels include a plurality of topology nodes, and each topology node is located in one of the plurality of levels. Alternatively, the topology structure of the application system can include a plurality of topology nodes, and the plurality of topology nodes are distributed on the plurality of levels, and one level includes part of the topology nodes. The system configuration information can be configured to indicate the topology relationship between the plurality of topology nodes, i.e., the system configuration information can be configured to indicate the topology relationship between each pair of topology nodes. For example, according to the system configuration information, it can be determined that one topology node includes (or is associated with or depends on) other topology nodes. For example, referring to the application system in FIG. 1B, an application service can be one level, and a microservice can be one level. Through the system configuration information, it can be determined that one application service includes a microservice. Alternatively, a component can be one level, and a container can be one level. Through the system configuration information, it can be determined that one component includes a container. Optionally, the system configuration information can be a topology relationship diagram, or the system configuration information can be a topology structure level table, and the topology structure level table can include the topology nodes included by the topology nodes in each highest level layer by layer downwards, or the system configuration information can be represented in other forms, which is not limited.

[0138] The configuration of the system configuration information can adopt various implementation manners.

[0139] In one implementation manner, the configuration interface can be configured to receive a system configuration file input by a user, i.e., the user can input a system configuration file through the configuration interface, and the system configuration file includes system configuration information. For example, the configuration interface can include an upload interface of the system configuration file, and the user can upload the system configuration file through the upload interface, and accordingly, the cloud management platform can receive the system configuration file uploaded by the user. For example, referring to the configuration interface 301 shown in FIG. 3A, the configuration interface 301 includes a file selection control 3011 and an upload control 3012. The user can select the system configuration file to be uploaded by operating the file selection control 3011, and the user can upload the selected system configuration file to the cloud management platform by operating the upload control 3012.

[0140] In another implementation, the configuration interface is configured to receive an editing operation input by the user, the editing operation being used to edit the topology nodes and the topology relationship between the topology nodes. That is, the configuration interface can be used by the user to edit the topology structure, and the user can edit the topology structure of the application system in the configuration interface. For example, the configuration interface can provide a drawing page (or drawing sub-interface) of the topology structure, and the user can draw the topology structure of the application system through the drawing page. For example, referring to the configuration interface 301 shown in FIG. 3A, the configuration interface 301 includes an adding node control 3013, a connecting node control 3014, and a drawing area 3015, and the user can add topology nodes in the drawing area 3015 by operating the adding node control 3013, and the user can connect the topology nodes by operating the connecting node control 3014, and the drawing area 3015 can be used by the user to preview the edited topology structure. In this example, the circle and the square respectively represent a level.

[0141] The above two implementations can be implemented in the same page as shown in FIG. 3A, or can be implemented through different configuration interfaces respectively, that is, the above two implementations can correspond to different pages respectively, and no specific limitation is made in this regard.

[0142] For the topology relationship of the configured application system, the cloud management platform can provide a viewing function to the user, and referring to the "topology view" in FIG. 3A, the user can view the topology relationship in the application system in this page, for example, can view through a topology relationship diagram, or can view through a topology structure level table, or can view through other possible manners, and no limitation is made in this regard.

[0143] The configuration interface of the embodiment of the present application can also be used to receive a first service requirement of the application system input by the user, and the first service requirement indicates that the fault detection is performed on at least two levels in the multiple levels, that is, the level required to be detected by the fault detection service. Different levels correspond to different granularity (dimension) of the topology nodes in the application system, and thus the first service requirement can also be understood as indicating the fault granularity (or fault dimension) to be detected.

[0144] The configuration of the first service requirement can adopt various implementation manners.

[0145] In one implementation, the configuration interface can be configured to display a plurality of levels, and at least two levels can be selected from the plurality of levels. Accordingly, the configuration interface can receive a user selection of the at least two levels, and the first service requirement can be obtained. For example, referring to the configuration interface 302 shown in FIG. 3B, the configuration interface 302 can include an example 3021 corresponding to the levels in the vertical topology of the resources of the application system shown in FIG. IB, from which a user can select at least two levels. The configuration interface 302 can also include an example 3022 corresponding to the levels in the horizontal topology of the applications of the application system shown in FIG. IB, from which a user can select at least two levels. Alternatively, the configuration interface 302 can include all the levels in the example 3021 and the example 3022, from which a user can select at least two levels. In addition, the configuration interface 302 can also include levels other than the levels indicated by the system configuration information, for example, the levels can be obtained according to the topology relationship indicated by the system configuration information, for example, a level including topology nodes of hardware, software, external dependencies, etc. can be obtained, or the levels can be user-defined, for example, the configuration interface 302 can provide a user with a custom interface 3023, and the user can define the required levels.

[0146] In another implementation, since different levels can be detected by different fault detection methods, or the levels where faults are detected by different fault detection methods are different, the levels can be implicitly selected by selecting the fault detection methods. Different fault detection methods have different principles of fault detection, different required input data, and different output fault detection results. The configuration interface can be configured to receive at least two fault detection methods input by a user. Each fault detection method can be configured to obtain a fault detection result corresponding to one of the at least two levels, i.e., each fault detection method can be configured to detect faults for one level and output a fault detection result corresponding to the level. In the embodiments of the present application, detecting faults for one level means that the fault indicated by the finally output fault detection result is located at the level, but it is not necessarily limited to detecting faults according to data related to the level.

[0147] Optionally, the configuration interface can display a plurality of selectable fault detection methods, and a user can select at least two fault detection methods from the plurality of fault detection methods. Alternatively, the configuration interface can provide a loading interface of the fault detection methods, and a user can load at least two required fault detection methods through the loading interface. Alternatively, the configuration interface can also provide a custom interface of the fault detection methods, and a user can customize at least two required fault detection methods through the loading interface. The above various implementations can also be combined to implement the input of the at least two fault detection methods.

[0148] Optionally, the fault detection method can be divided into different types, and different types of fault detection methods can be input respectively. For example, the fault detection method can be divided into expert rules and fault detection models. Among them, the expert rule refers to the rule formed based on the summary of previous experience, and the running data of the application system and the expert rule can be combined to judge the fault in the application system. That is, the configuration interface can be used to receive at least one expert rule input by the user, wherein each expert rule is used to obtain a hierarchical fault detection result. Optionally, the configuration interface can display a plurality of expert rules for the user to select, and the user can select at least one expert rule from them. For example, see the configuration interface 303 shown in FIG. 3C, which includes an expert rule selection area 3031, and the user can check the required expert rule in the expert rule selection area 3031. Alternatively, the configuration interface can also provide a custom interface for expert rules, and the user can customize the expert rule through the custom interface. For example, see the configuration interface 303 shown in FIG. 3C, which includes an expert rule customization area 3032, and the user can edit the related information of the customized expert rule in the expert rule customization area 3032, such as the name of the expert rule, the rule introduction, and the rule content, etc., and finally submit and confirm to generate a new expert rule. Alternatively, other configuration methods can also be used, for example, the configuration interface 303 can also provide an upload interface for the expert rule, and the user can upload the configuration file of the expert rule to realize the input of the expert rule. The specific configuration method is not limited. The configuration interface 303 is only one possible example, and the specific configuration interface of the expert rule is not limited.

[0149] Optionally, for the expert rule input by the user, the cloud management platform can provide a viewing function for the user, see "Rule View" in FIG. 3C, the user can view the input expert rule in this page, for example, the name of the expert rule, the rule introduction, and the specific rule content, etc.

[0150] The fault detection model refers to a model that needs to be trained by a specific model training method before being put into use. Each fault detection model can output a corresponding fault detection result according to the input running data of the application system. For example, the fault detection model can be a deep learning model or a neural network model. That is, the configuration interface can be used to receive at least one fault detection model input by the user. Each fault detection model is trained by using a corresponding training method of each fault detection model, and each fault detection model is used to obtain a fault detection result corresponding to a level according to a corresponding fault detection method. Optionally, the configuration interface can display multiple fault detection models for the user to select from, and the user can select at least one fault detection model from them. For example, referring to the configuration interface 304 shown in FIG. 3D, the configuration interface 304 includes a model selection area 3041, which can display some or all of the models in the current model library. The user can check the required fault detection model in the model selection area 3041. Alternatively, the configuration interface can also provide a file upload interface for the fault detection model, and the user can upload a model file through the file upload interface. For example, referring to the configuration interface 304 shown in FIG. 3D, the configuration interface 304 includes a file adding interface 3042 and a file uploading interface 3043. The user can add a model file through the file adding interface 3042 and upload the model file through the file uploading interface 3043. Alternatively, other configuration methods can also be used, which are not limited in this regard. The configuration interface 304 is only one possible example, and the configuration interface of the specific fault detection model is not limited.

[0151] The fault detection model can be divided into supervised training method and unsupervised training method according to the training method. The supervised training method can be supervised training through the collected training data (containing labeled training labels). When the model reaches the convergence condition, the model can be used for fault detection of the actual process. The training data of the unsupervised training method does not need to be labeled, so the complexity of the unsupervised training method is relatively lower than that of the supervised training method, but the accuracy is limited, and the application scenarios of the model obtained by the supervised training and the model obtained by the unsupervised training may also be different, for example, the types of fault detection results output by the two may be different.

[0152] In addition to the above configurations, other possible configurations can also be included, which are not limited in this regard.

[0153] Step 202: Obtain running data of multiple topology nodes of the application system during running. For example, as shown in FIG. 2, the cloud management platform can obtain the running data of the application system during running from the application system.

[0154] The running data of the plurality of topology nodes of the application system during runtime can be acquired based on the system configuration information and the first service requirement input by the user. That is, after the system configuration information and the first service requirement are input by the user, the fault detection service for the application system is configured, and the fault detection service can be used to detect the fault of the application system. Thus, the running data of the application system can be collected to detect the fault.

[0155] The running data of the plurality of topology nodes of the application system during runtime can be acquired at various occasions. For example, the running data of the application system can be collected synchronously. That is, the running data of the application system is collected synchronously during the running of the application system. Thus, when the application system fails, the fault can be detected based on the running data, the time delay for acquiring the running data is reduced, and the probability that the running data cannot be collected when the application system fails is reduced, so that sufficient data can be provided for the fault detection.

[0156] The running data of the plurality of topology nodes of the application system during runtime can be acquired in various manners.

[0157] In one implementation, the cloud management platform can send a data acquisition request to the application system, and the data acquisition request is used to request the running data of the plurality of topology nodes of the application system during runtime. Then, the cloud management platform can receive the running data sent by the application system. The data acquisition request can specify the running data to be acquired. For example, the cloud management platform can send a data acquisition request to the management device of the application system, and the management device sends the running data to the cloud management platform after acquiring the running data.

[0158] In another implementation, the application system can provide a data acquisition interface to the cloud management platform, and the cloud management platform can acquire the running data of the plurality of topology nodes of the application system during runtime through the data acquisition interface.

[0159] In another implementation, the cloud management platform can include one or more agent modules that can run in the application system, and the agent modules are configured to collect the runtime data of the plurality of topology nodes in the application system. The cloud management platform can obtain the runtime data through the agent modules. The number and locations of the agent modules in the application system can be configured according to the actual situation of the application system. For example, the application system includes two areas, and the number of agent modules can be 2, which are respectively arranged in the management devices or gateway devices of the two areas, and can be used to collect the runtime data of each area. Of course, the number of agent modules can be more, and no limitation is made thereto.

[0160] In another implementation, if the application system reports the runtime data to the database, the runtime data of the plurality of topology nodes in the application system can also be obtained from the database. For example, the cloud management platform can subscribe to specific data (i.e., the runtime data required for fault detection) in the database, and when the data in the database is updated, the cloud management platform can obtain the corresponding updated data.

[0161] Optionally, the required runtime data to be collected can be configured by the user, i.e., the data indicators to be collected can be configured by the user. The configuration interface in the embodiment of the present application can also be used to receive the data indicator configuration information input by the user, and the data indicator configuration information is used to indicate the data indicators required to be collected for the topology nodes in each level of the plurality of levels. Then, the runtime data of the plurality of topology nodes in the application system can be obtained according to the data indicator configuration information. The data indicators of any two levels of the plurality of levels can be the same or different. For example, the data indicators can be configured according to the characteristics of the topology nodes in each level. The data indicators can be understood as parameters or characteristic dimensions, and the runtime data includes the values of the parameters or characteristic dimensions. The data indicators can include common data indicators of all levels and unique data indicators of specific levels. For example, the common data indicators are the central processing unit (CPU) occupancy rate or the memory occupancy amount, etc. When the topology nodes are containers, the unique data indicators can be the number of invocations (or running) of the containers, etc.

[0162] The configuration of the data indicator configuration information can adopt various implementation manners.

[0163] In one implementation, the configuration interface can be configured to receive a data indicator configuration file input by a user, the data indicator configuration file including data indicator configuration information. For example, the configuration interface can include an upload interface of the data indicator configuration file, through which the user can upload the data indicator configuration file. For example, referring to the configuration interface 305 shown in FIG. 3E, the configuration interface 305 includes a file adding interface 3051 and a file uploading interface 3052, through which the user can add and upload the data indicator configuration file. The upload interface can also have other forms, which are not limited herein.

[0164] In another implementation, the configuration interface can be configured to display a plurality of data indicators, and configured to enable a user to select data indicators from the plurality of data indicators. Accordingly, the configuration interface can be configured to receive data indicators selected by the user from the plurality of data indicators, so that the data indicator configuration information can be generated according to the data indicators selected by the user, and the data indicator configuration information includes the data indicators selected by the user. For example, referring to the configuration interface 305 shown in FIG. 3E, the configuration interface 305 includes an indicator selection area 3053, which can display data indicators that can be selected at each level, and the user can check the data indicators to be collected at each level in the indicator selection area 3053. Alternatively, the indicator selection area 3053 can display all data indicators, and the user can bind specific data indicators to each level as the data indicators to be collected at each level. Alternatively, the indicator selection area 3053 can display general data indicators that can be selected by the user, and the selected data indicators will be collected for all levels, and the corresponding unique data indicators for each level will be displayed for the user to select.

[0165] The above two implementations can be used separately or in combination. Alternatively, other configuration methods can also be used, such as a method of providing a user with a self-defined data indicator, which is not limited herein. The configuration interface 305 is only one possible example, and the configuration interface of a specific data indicator is not limited herein.

[0166] Step 203: determining a fault detection result corresponding to the at least two levels according to the running data of the plurality of topology nodes.

[0167] In the embodiments of the present application, the collected running data of the plurality of topology nodes can be used to determine a fault detection result corresponding to the at least two levels. For each level, the fault detection result can be determined according to the running data of part or all of the plurality of topology nodes. Alternatively, for each fault detection method, the required running data can be part or all of the collected running data.

[0168] Exemplarily, the fault detection result corresponding to the at least two levels can include one or more implementation manners:

[0169] Implementation manner one, fault detection result based on expert rules. This manner starts from the whole application system, combines the experience summary of operation and maintenance experts, adopts rules for judgment, and determines the fault of the application system.

[0170] Exemplarily, referring to (a) shown in FIG. 4A, an expert rule can be formed based on the business indicators of the park level and the experience summary of the operation and maintenance experts, to judge the fault category from the whole application system. The formed expert rule can perform fault detection according to the running data of the application system in the actual application scene. By inputting the running data and combining the expert rule, a fault detection result based on the expert rule can be obtained. (a) in FIG. 4A shows a fault detection result based on the expert rule, that is, one or more fault types to which the application system belongs are output, such as the hardware fault, the software fault and the external dependency fault shown in FIG. 4A. The hardware fault refers to the fault of the hardware system in the application system, that is, the fault of the system resource on which the application system runs, and thus can also be called resource fault or system fault. The software fault refers to the fault of the software system in the application system, that is, the fault of the application program running in the application system, and thus can also be called application fault. The external dependency fault refers to the fault of the external resource on which the application system runs in the application system, for example, the external resource can include the database resource, and thus can also be called database fault. Of course, the fault types can also be divided in other manners, which is not specifically limited.

[0171] Implementation manner two, fault detection result based on the fault detection model trained by the supervised training method. This manner learns the historical faults of the application, specifically collects the data indicators of the normal stage and the fault stage of the application system through the fault rehearsal process, and performs label annotation after that, and then performs supervised training. The labeled label is the fault detection result of a topology node at a level, and the label is used for calculating the model loss value and adjusting the parameters of the fault detection model in the supervised training process. When the fault detection model reaches the convergence condition, the fault detection model can be used to perform fault detection on the topology node at this level in the application system. Taking the fault detection of the basic module at this level as an example, the fault label of the basic module can be annotated according to the collected running data, and the fault detection model is used to perform fault detection on the basic module at this level of the application system after the fault detection model reaches the convergence condition.

[0172] For example, as shown in (b) of FIG. 4A, after the supervised training is completed and the running data is input, the fault detection results of each basic module in the application system can be obtained, such as the fault detection results of the basic modules 1-P shown in (b) of FIG. 4A. The fault detection result of each basic module can include the probability of the basic module belonging to each fault type, such as the probability of the basic module 1 being fault-free, the probability of the basic module 1 belonging to a hardware fault, the probability of the basic module 1 belonging to a software fault, and the probability of the basic module 1 belonging to an external dependency fault. It should be noted that the fault detection result shown in (b) of FIG. 4A is only an example, and the embodiments of the present application do not limit this.

[0173] In a third implementation, the fault detection result of the fault detection model trained based on the unsupervised training method. This way, by combining the historical normal stage (i.e., fault-free) running data of the topology nodes in the application system, the normal stage features of the application system are learned through the unsupervised training (i.e., unsupervised learning) method. It can be understood as reconstructing the model of the normal stage of the application system, and then detecting whether the topology node has a fault according to the reconstruction error between the features of the actual scene (i.e., the features obtained according to the actually collected running data) and the learned normal stage features.

[0174] Taking the topology node as an example, the container node (such as the application container and the database container shown in FIG. 1B), the normal state reconstruction model can be learned based on the historical normal running data of the container node, and finally whether the container node is faulty is judged according to the reconstruction error between the running data of the container node in the actual scene and the normal running data. For example, as shown in (c) of FIG. 4A, after the running data is input, the fault detection result of each container can be obtained, which can include the fault probability or fault-free probability of the container, such as the fault probabilities of the containers 1-L shown in (c) of FIG. 4A.

[0175] It should be noted that whether the topology node is faulty can also be detected by other methods other than the model obtained by unsupervised training, such as the model obtained by supervised training can also be used for detection, which is not limited here.

[0176] Step 204: Fusing the fault detection results corresponding to at least two levels according to the topology relationship to obtain a fused detection result. For the specific implementation of step 204, please refer to the introduction in the subsequent part.

[0177] Step 205: Displaying the fused detection result of the application system on the result interface of the fault detection service.

[0178] In the embodiments of the present application, the cloud management platform can provide a result interface of the fault detection service, and the final fusion detection result can be displayed in the result interface. The user can view the fusion detection result in the result interface to understand the existing faults of the current application system. The fusion detection result refers to the detection result obtained by fusing the fault detection results corresponding to the at least two levels, that is, the method of the embodiments of the present application can fuse the fault detection results of different levels and then output.

[0179] Optionally, when the fusion detection result is displayed in the result interface, a topology relationship diagram of the application system can be displayed in the result interface, and the topology node of the fault in the application system can be marked in the topology relationship diagram according to the fusion detection result. In this way, the user can more intuitively view the topology node of the fault. Alternatively, other ways can be used to display the fusion detection result, which is not limited in particular.

[0180] Optionally, the user can specify the level of the final output fusion detection result. That is, the configuration interface is also used to receive the second service requirement input by the user, and the second service requirement is used to indicate N candidate faults of the application system. The level corresponding to the N candidate faults is higher than any level of the at least two levels, that is, the level of the final output fusion detection result is not in the level specified in the first service requirement, but the level of the fault indicated by the second service requirement is higher than the at least two levels specified in the first service requirement. Alternatively, the level corresponding to the N candidate faults is the highest level of the at least two levels.

[0181] Then, the fusion detection result can be displayed in the result interface based on the second service requirement input by the user. The fusion detection result includes at least one candidate fault of the N candidate faults, and the at least one candidate fault is obtained by fusing the fault detection results corresponding to the at least two levels in the direction from low level to high level. It can be understood that the user can specify the N candidate faults, and the final output fault can be one or more of the N candidate faults, and the level of the fault specified by the user is the highest level. In the process of fault detection, fault detection will also be performed from other levels, and the fault detection results of other levels will be fused from low level to high level until the fault detection result of the highest level is obtained, that is, the final fusion detection result.

[0182] Optionally, the user can input the second service requirement in multiple ways. One implementation way is that the configuration interface can display multiple candidate faults, and the user can select N candidate faults from the multiple candidate faults. Another implementation way is that the user does not need to perform additional input, and the candidate of the highest level of the at least two levels can be determined as the N candidate faults. Another implementation way is that the user can customize the N candidate faults. Alternatively, other implementation ways can be used, which is not limited in particular.

[0183] Optionally, the result interface can also be used to display detailed information of the fault detection process. For example, the result interface can provide a detailed viewing interface, and the user can trigger an operation on the detailed viewing interface to display the detailed information.

[0184] Optionally, in addition to displaying the fusion detection result, the result interface can also display other fault detection results. For example, the other fault detection results can include the fault detection results corresponding to the at least two levels and the intermediate results generated in the fusion process.

[0185] In one example, the at least two levels can include a first level and a second level, the first level includes a plurality of first topology nodes, and the second level includes a plurality of second topology nodes. One first topology node can include one or more second topology nodes, that is, the first level is higher than the second level. The fault detection results corresponding to the at least two levels can include first fault detection results corresponding to the first level and second fault detection results corresponding to the second level. The first level and the second level can be any two levels in a plurality of levels included in the application system. The following examples illustrate several possible cases, but are not limited thereto:

[0186] Case 1: The first level is a subsystem level, and the subsystem can be a hardware subsystem, a software subsystem, and an external dependency subsystem, that is, one first topology node can be one of the hardware subsystem, the software subsystem, and the external dependency subsystem. The second level is the basic module level shown in FIG. 1B, that is, one second topology node can be one basic module. The first fault detection result can indicate the fault of the subsystem, and the second fault detection result can indicate the fault of the basic module. For example, the first fault detection result can indicate which of the hardware subsystem, the software subsystem, and the external dependency subsystem is faulty, such as the first fault detection result shown in (a) of FIG. 4A, which can include the fault probabilities of the hardware subsystem, the software subsystem, and the external dependency subsystem. The second fault detection result can indicate the fault of each basic module, that is, whether each basic module is faulty and the specific fault type when it is faulty, such as the second fault detection result shown in (b) of FIG. 4A, which includes the probability of no fault, the probability of hardware fault, the probability of software fault, and the probability of external dependency fault for each basic module.

[0187] Case 2, the first level is the subsystem level, that is, a first topology node can be one of a hardware subsystem, a software subsystem and an external dependency subsystem. The second level is the container level shown in FIG. 1B, that is, a second topology node can be a container. The first fault detection result can indicate a fault of a subsystem, and the second fault detection result can indicate a fault of a container. For example, the first fault detection result can indicate which of the hardware subsystem, the software subsystem and the external dependency subsystem is faulty, such as the first fault detection result shown in (a) of FIG. 4A, which can include fault probabilities of the hardware subsystem, the software subsystem and the external dependency subsystem respectively. The second fault detection result can indicate a fault of each container, that is, whether each basic module is faulty, such as the second fault detection result shown in (c) of FIG. 4A, which includes a fault probability or a non-fault probability of each container.

[0188] Case 3, the first level is the basic module level shown in FIG. 1B, that is, a first topology node can be a basic module. The second level is the container level shown in FIG. 1B, that is, a second topology node can be a container. The first fault detection result can indicate a fault of a basic module, and the second fault detection result can indicate a fault of a container. For example, the first fault detection result can indicate a fault of each basic module, that is, whether each basic module is faulty and, if so, the specific fault type, such as the second fault detection result shown in (b) of FIG. 4A, which includes a non-fault probability, a hardware fault probability, a software fault probability and an external dependency fault probability of each basic module. The second fault detection result can indicate a fault of each container, that is, whether each basic module is faulty, such as the second fault detection result shown in (c) of FIG. 4A, which includes a fault probability or a non-fault probability of each container.

[0189] It should be noted that for different system architectures, the first level and the second level can also be different accordingly, and the first level and the second level can be configured according to actual needs. In addition, only the first level and the second level are taken as examples here, but in actual scenarios, more levels can also be included, and when other levels are included, the fusion of other levels can also be performed according to the same principle, and the embodiments of the present application do not limit this.

[0190] One possible fusion manner is to convert the second-level fault detection result to the first level. Referring to FIG. 4B, since there is a topological relationship between the second topology node and the first topology node, if a second topology node fails, the first topology node having a topological relationship with the second topology node will be affected, and the probability of failure is greatly increased, or the first topology node is also faulty. Therefore, the second fault detection result can be converted to the first level through the topological relationship to obtain a third fault detection result corresponding to the first level. The third fault detection result can include the converted fault information of each first topology node in the first level.

[0191] In one possible implementation, the first fault detection result is used to indicate the fault information of the plurality of first topology nodes, and the third fault detection result includes a plurality of confidence levels, which are in one-to-one correspondence with the plurality of first topology nodes. That is, the converted fault information of each first topology node included in the third fault detection result is the confidence level of the fault information of the first topology node. The confidence level can also be referred to as the reliability or confidence probability, etc., which is used to represent the reliability of the fault information of the first topology node. Converting the fault detection result of the second level to the confidence level of the fault detection result of the first level can be understood as verifying the reliability of the fault detection result of the first level by taking the fault detection result of the second level as the verification of the fault detection result of the first level, thereby improving the reliability of the final fault detection result.

[0192] In one example, the first fault detection result indicates the fault to which each first topology node belongs. The first fault detection result can indicate that the first topology node is fault-free, or the first fault detection result can indicate that the fault of the first topology node belongs to which one of N candidate faults, and the N candidate faults include a first fault, a second fault, and a third fault. For example, the first fault can be a hardware fault, the second fault can be a software fault, and the third fault can be an external dependency fault. The second fault detection result indicates the respective fault probabilities of the plurality of second topology nodes. Then, the second fault detection result is converted to the confidence level of the fault information of the first topology node in the first level. The specific conversion method can be as follows:

[0193] First, the confidence level of each first topology node being fault-free is determined according to the respective fault probabilities of the plurality of second topology nodes. That is, for a first topology node, the confidence level of the first topology node being fault-free is determined according to the respective fault probabilities of the second topology nodes having a topological relationship with the first topology node, or according to the respective fault probabilities of the second topology nodes included in the first topology node. Correspondingly, the third fault detection result can include the confidence level of each first topology node being fault-free.

[0194] Optionally, the confidence of the non-failure of a first topology node can be determined according to the maximum of the failure probabilities of all the second topology nodes included in the first topology node, or can be determined according to the minimum of the non-failure probabilities of all the second topology nodes included in the first topology node. For example, the confidence of the non-failure of a first topology node can be the difference between the upper limit of probability and the maximum of the failure probabilities of all the second topology nodes included in the first topology node. For example, if the maximum of the failure probabilities of all the second topology nodes is X, then the confidence of the non-failure of the first topology node is 1-X. Alternatively, the confidence of the non-failure of a first topology node can be the minimum of the non-failure probabilities of all the second topology nodes included in the first topology node.

[0195] Second, the confidence of the first failure of each first topology node determined according to the respective failure probabilities of the plurality of second topology nodes, i.e. for a first topology node, the confidence of the first failure of the first topology node can be determined according to the respective failure probabilities of the second topology nodes having a topology relationship with the first topology node, or in other words, the confidence of the first failure of the first topology node can be determined according to the respective failure probabilities of the second topology nodes included in the first topology node. Correspondingly, the third failure detection result can include the confidence of the first failure of each first topology node.

[0196] Optionally, the confidence of the first failure of a first topology node can be determined according to the maximum of the failure probabilities of all the second topology nodes included in the first topology node. Taking the above example of the first failure being a hardware failure, when the hardware fails, the operation of all the topology nodes in the application system can be affected, and thus the confidence of the first failure can be determined according to the failure probabilities of all the second topology nodes. For example, the confidence of the first failure of a first topology node can be the maximum of the failure probabilities of all the second topology nodes included in the first topology node.

[0197] Thirdly, the confidence of each first topology node belonging to the second failure is determined according to the failure probability of each second topology node of the first type. The second failure affects the operation of the second topology node of the first type. The second failure affecting the operation of the second topology node of the first type can be understood as that, when the third failure occurs, part or all of the second topology node of the first type cannot operate normally. Then, for a first topology node, the confidence of the first topology node belonging to the second failure can be determined according to the failure probability of each second topology node of the first type which has a topology relationship with the first topology node, or in other words, the confidence of the first topology node belonging to the second failure can be determined according to the failure probability of each second topology node of the first type which is included in the first topology node. Correspondingly, the third failure detection result can include the confidence of each first topology node belonging to the second failure.

[0198] Optionally, the confidence of a first topology node belonging to the second failure can be determined according to the maximum value of the failure probability of the second topology node of the first type included in the first topology node. Taking the software failure as the second failure, for example, when the software fails, the operation of the topology node (such as the container node) related to the software in the application system can be affected, and thus the confidence of belonging to the second failure can be determined according to the failure probability of the second topology node of the first type. For example, the confidence of a first topology node belonging to the second failure can be the maximum value of the failure probability of the second topology node of the first type included in the first topology node.

[0199] Fourthly, the confidence of each first topology node belonging to the third failure is determined according to the failure probability of each second topology node of the second type. The third failure affects the operation of the second topology node of the second type. The third failure affecting the operation of the second topology node of the second type can be understood as that, when the third failure occurs, part or all of the second topology node of the second type cannot operate normally. Then, for a first topology node, the confidence of the first topology node belonging to the third failure can be determined according to the failure probability of each second topology node of the second type which has a topology relationship with the first topology node, or in other words, the confidence of the first topology node belonging to the third failure can be determined according to the failure probability of each second topology node of the second type which is included in the first topology node. Correspondingly, the third failure detection result can include the confidence of each first topology node belonging to the third failure.

[0200] Optionally, the confidence degree of a first topology node belonging to the third fault can be determined according to the maximum value of the failure probability of the second topology node of the second type included by the first topology node. Taking the third fault as an external dependent fault (e.g. database fault) as an example, when the external dependent fault occurs, the operation of the topology node (e.g. database node) related to the external dependent fault in the application system can be affected, and thus the confidence degree of the third fault can be determined according to the failure probability of the second topology node of the second type. For example, the confidence degree of a first topology node belonging to the third fault can be the maximum value of the failure probability of the second topology node of the second type included by the first topology node.

[0201] Continuing to refer to FIG. 4B, after obtaining the third fault detection result, the first fault detection result and the third fault detection result can be fused to obtain a fourth fault detection result. The fourth fault detection result can indicate the fused fault information of each first topology node.

[0202] The first fault detection result and the third fault detection result both correspond to the first level, and thus the fusion of the first fault detection result and the third fault detection result is the fusion of the fault detection results of the same level. The fusion of the first fault detection result and the third fault detection result can adopt various implementation manners.

[0203] One implementation manner is that the fault detection method corresponding to the first fault detection result and the fault detection method corresponding to the third fault detection result can have different priorities, and thus the fusion of the first fault detection result and the third fault detection result can be performed by referring to the different priorities.

[0204] Another implementation manner is that the fusion of the first fault detection result and the third fault detection result can be performed by adopting a voting manner. For example, the first fault detection result can indicate the probability of each first topology node belonging to each fault of the plurality of faults, and the third fault detection result can indicate the confidence degree of the probability of each first topology node belonging to each fault of the plurality of faults, and thus for a first topology node, the confidence probability of the first topology node belonging to a fault can be determined according to the probability and the corresponding confidence degree of the first topology node belonging to the fault. For example, referring to Table 1, the fusion example of a first topology node is shown, A1 to A4 are respectively the probability of the first topology node belonging to each classification (i.e. the first fault detection result), B1 to B4 are respectively the confidence degree of the first topology node belonging to each classification (i.e. the third fault detection result), and the corresponding confidence probability can be obtained according to the probability and the confidence degree of each classification, and An*Bn in Table 1 is only an example of calculation and is not limited in a specific manner. The confidence probability as shown in Table 1 can be obtained for each first topology node, and thus the fused fault information of each first topology node can be the several confidence probabilities as shown in Table 1.

[0205] Table 1

[0206] In another implementation, the first fault detection result and the third fault detection result can be input into a pre-trained fusion model to obtain a fourth fault detection result output by the model.

[0207] Or other possible fusion methods can also be used, and the embodiments of the present application do not limit this.

[0208] Optionally, the fourth fault detection result can also indicate the confidence probability of each classification, that is, the confidence probability of each first topology node belonging to each classification is further fused. For example, for each first topology node, the confidence probability shown in Table 1 can be obtained, and the confidence probability of each classification can be finally determined. The confidence probability of one classification is the sum of the confidence probabilities of all first topology nodes in the classification, thereby obtaining the fourth fault detection result.

[0209] Then, when the fusion detection result is displayed on the result interface, the displayed fusion detection result can also include the third fault detection result and / or the fourth fault detection result.

[0210] Next, the process of the above-mentioned hierarchical fusion will be introduced with specific examples.

[0211] Referring to FIG. 5, in this example, three fault detection methods are used for fault detection, and the three fault detection methods obtain different fault detection results based on different perspectives (i.e., levels or dimensions) and fault detection processes. Among them, the three fault detection methods are as follows:

[0212] Method one, as shown in (a) of FIG. 4A, this method is based on the park-level business indicators and the experience summary of operation and maintenance experts to form expert rules, to judge the fault category from the application as a whole, and finally output the fault detection result based on the expert rules, that is, output the fault type (or the probability of each fault type) of the application system, such as hardware fault, software fault and external dependency fault, as shown in FIG. 4A.

[0213] Method two, as shown in (b) of FIG. 4A, this method uses a supervised multi-classification model for fault detection, that is, combining the historical data and the data indicators of the application system in the normal stage and the fault stage collected through fault simulation, after labeling, supervised training is performed to detect the fault of the basic module, and the fault classification result of each basic module is output, that is, the classification to which each basic module belongs, or the probability of each basic module belonging to each classification, that is, the probability of belonging to no fault, the probability of belonging to hardware fault, the probability of belonging to software fault and the probability of belonging to external dependency fault.

[0214] Method three, as shown in (c) of FIG. 4A, adopts an unsupervised model for fault detection, i.e., state detection for deployed base nodes, such as containers or VMs, etc., and here takes containers as an example. Based on historical normal data of the containers, an unsupervised learning is performed to obtain a normal state reconstruction model of the containers. Finally, whether the containers are faulty can be determined according to the reconstruction error between the actual scene collected running data and the normal state reconstruction model, and the fault probability of each container is finally output.

[0215] Since the fault ranges obtained by the above three fault detection methods have different accuracies, and different fault categories may also occur, they need to be considered comprehensively. In this example, a hierarchical fusion strategy is adopted to integrate the fault detection results of different levels layer by layer to improve the accuracy and reliability of fault detection. First, the fault classification results of the base modules of method two and the states of the containers of method three are fused. The fault classification results of the base modules can correspond to the states of the containers, so the states of the nodes of method three are converted into the confidence of the fault types of the base modules of method two. Second, the results of all base modules are fused by voting majority. Finally, the model results are fused with the results of the expert rules of method one. If the confidence probability of the model results is low, the results of the expert rules of method one are selected as the bottom result, otherwise the model results are output.

[0216] Continuing to refer to FIG. 5, the specific steps are as follows:

[0217] Step S10: bottom layer fusion, i.e., fusion of the fault classification results of the base modules and the state results of the containers.

[0218] In this step S10, the node abnormal state detection results in method three are converted into the confidence of the module fault categories in method two, realizing the bottom layer data fusion. This conversion of confidence probability strengthens the accuracy of the fault classification module and the reliability of the results.

[0219] In the embodiments of the present application, the application system can include multiple base modules, each base module containing multiple application containers and database containers. The fault classification results of each base module output by method two can be represented as: [probability of belonging to no fault, probability of belonging to hardware fault, probability of belonging to software fault, probability of belonging to external dependency fault]. Method three performs fault detection on each container to obtain the container level detection results, which can be represented as: [fault probability, no fault probability].

[0220] Specifically, the container level detection results of method three are converted into the confidence of the fault types of the base modules of method two. For any base module A, the conversion method can be as follows:

[0221] (1) The confidence of the base module A belonging to no fault: take the minimum value of the no fault probability of all containers in the base module A.

[0222] (2) The confidence of the base module A belonging to hardware fault: take the maximum value of the fault probability of all containers in the base module A.

[0223] (3) The confidence of the base module A belonging to external dependent fault: take the maximum value of the fault probability of the database container in the base module A.

[0224] (4) The confidence of the base module A belonging to software fault: take the maximum value of the fault probability of the application container in the base module A.

[0225] After the conversion, for the base module A, the product of the probability of the base module A belonging to each category and the corresponding confidence can be calculated as the confidence probability of the base module A belonging to each category.

[0226] Step S11: intermediate layer fusion, i.e. fusion of the fault classification results of the base modules.

[0227] The intermediate layer refers to the integrated processing layer of the fault classification results of the base modules fused from the bottom layer. In this layer, the results of different base modules are combined through certain rules to obtain more comprehensive fault detection results.

[0228] Optionally, the fusion of the intermediate layer can adopt a voting mechanism, i.e. the confidence probability of each category can be determined according to the confidence probabilities of the same categories of all base modules to realize the fusion of the fault classification results of the base modules. For example, the sum of the confidence probabilities of the same categories of all base modules can be taken as the confidence probability of a category, such as adding the confidence probabilities of all base modules belonging to no fault to obtain the confidence probability of the application system belonging to no fault, adding the confidence probabilities of all base modules belonging to hardware fault to obtain the confidence probability of the application system belonging to hardware fault, and so on. Through the fusion of the fault detection results of multiple base modules, the accuracy of the decision is increased and the risk of the judgment error of a single module is reduced.

[0229] Step S12: top layer fusion, i.e. fusion of the model results and the expert rule results. The model results refer to the results after the above-mentioned intermediate layer fusion, and the expert rule results refer to the results obtained by the method one.

[0230] The top layer is a stage of fusing the model result and the expert rule in method one. The top layer can integrate the information of the bottom layer and the intermediate layer, and add the judgment of the expert rule to improve the accuracy of the finally determined fault. When fusing the top layer, if the confidence probability of the model result obtained by the intermediate layer fusion is low, the result of the expert rule in method one is considered as a bottom strategy to ensure that the expert rule can be used as the last guarantee when the model result is not reliable enough.

[0231] Referring to FIG. 5, if the confidence probability of the model result obtained by the intermediate layer fusion is high (for example, greater than or equal to a set threshold), the model result is directly output, and the model result can include information such as the fault type, the basic module of the fault, and the container of the fault. Then, when the result interface is displayed, the fault type, the basic module of the fault, and the container of the fault can be displayed. For example, in order to facilitate the user to perceive the relationship between faults at different levels, the faults at different levels can also be jointly displayed, for example, a chain structure can be used for display, and through the chain structure, the fault at each level from the top layer to the bottom layer can be viewed. If the confidence probability of the model result obtained by the intermediate layer fusion is low (for example, less than the set threshold), the expert rule result is directly output, and the expert rule result can include the fault type.

[0232] Through the above decision scheme based on hierarchical fusion, from the direct processing of the bottom layer data to the result fusion of the intermediate layer, and to the final decision of the top layer, a comprehensive, multi-angle, and high-reliability integrated bounding and fault detection system is formed, which not only improves the accuracy and robustness of fault detection, but also fully utilizes the complementarity of information between layers to achieve efficient positioning and processing of complex system faults.

[0233] In some embodiments, in order to improve the accuracy of fault detection of the application system, various fault detection methods can be used for detection, but the fault detection results determined by different fault detection methods may conflict. To solve this problem, the embodiment of the application provides another fault detection method based on cloud service. The method can perform fault drilling on various fault types under various topologies in advance, collect fault drilling data, and then perform fault detection according to the fault drilling data by using different fault detection methods to determine the priority of each fault detection method for a specific fault type under a specific topology. In actual application scenarios, when the fault detection results determined by different fault detection methods conflict, the different fault detection results can be fused according to the priority to obtain the final fusion detection result. In the embodiment of the application, the fault detection can refer to fault bounding, fault positioning, or root cause positioning, and the following will mainly take fault detection as an example for introduction.

[0234] Referring to FIG. 6, another flow diagram of a method provided by the embodiments of the present application is shown, which can be applied to the application scenario of FIG. 1A or the system architecture of FIG. 1D. The method can include the following steps:

[0235] Step 601: providing a configuration interface of the fault detection service. The configuration interface is configured to receive a topology type of the application system and a third service requirement input by a user, the third service requirement indicating N types of faults of the application system, N being a positive integer greater than 1.

[0236] The cloud management platform can provide a purchase interface of the fault detection service, and the user can purchase the fault detection service through the purchase interface of the cloud management platform after logging in the cloud management platform by using an account and a password of the user. After purchasing the fault detection service, the user can view the fault detection service in the services owned by the user. For example, the user can purchase the fault detection service through the service purchase module of FIG. 1D.

[0237] In combination with FIG. 6, the cloud management platform provides a configuration interface of the fault detection service, and the user can input the topology type of the application system and the third service requirement through the configuration interface by using the client. The client can send the topology type of the application system and the third service requirement input by the user to the cloud management platform.

[0238] Before performing fault detection on the application system based on the fault detection service, the fault detection service needs to be configured. The cloud management platform can provide a configuration interface of the fault detection service for the user, and the user can configure the fault detection service through the configuration interface. The content input by the user during the configuration can assist in implementing the fault detection service. It should be noted that the configuration of the fault detection service by the user can be one-time, that is, after the configuration is completed once, the information of the configuration does not need to be configured again in the subsequent service use process, and therefore, step 601 is not a necessary step.

[0239] In the embodiments of the present application, the configuration interface can be configured to receive the topology type of the application system input by the user. The topology type can also be referred to as an architecture type, a topology mode, or an architecture topology mode, etc.

[0240] Optionally, the topology type can be classified from the perspective of the architecture adopted by the application system, for example, the application system can adopt a micro-service architecture, a monolithic architecture, a service-oriented architecture, etc.

[0241] Optionally, the topology type can be classified from the perspective of the distribution of resources of the application system. Different topology types have different distributions of system resources, and correspondingly, the topology relationship relied on during fault detection and the detection result output can be different. The following examples illustrate several topology types:

[0242] Topology Type 1, a topology type of single region-single AZ-single database. Referring to FIG. 7A, an example of topology type 1 is shown, in which the infrastructure of the application system is deployed in a single region, the region includes one AZ, and the AZ includes only one database.

[0243] Topology Type 2, a topology type of single region-multiple AZs-multiple databases. Referring to FIG. 7B, an example of topology type 2 is shown, in which the infrastructure of the application system is deployed in a single region, the region includes multiple AZs, such as AZ1-AZ3 shown in FIG. 7B, and the multiple AZs use a distributed database architecture.

[0244] Topology Type 3, a topology type of single region-dual AZs-primary / standby databases. Referring to FIG. 7C, an example of topology type 3 is shown, in which the infrastructure of the application system is deployed in a single region, the region includes two AZs, such as AZ1-AZ2 shown in FIG. 7B, and the multiple AZs respectively deploy respective databases, and the two databases use a primary / standby database architecture, in which one of the databases is a primary database and the other is a standby database.

[0245] Topology Type 4, a topology type of dual regions-multiple AZs-multiple databases (dual active). Referring to FIG. 7D, an example of topology type 4 is shown, in which the infrastructure of the application system is deployed in two regions, such as region 1 and region 2 shown in FIG. 7D, each region includes multiple AZs, such as AZ1-AZ3 in region 1 and AZ1-AZ3 in region 2 shown in FIG. 7D, the AZs in the two regions are different, the multiple AZs in one region use a distributed database architecture, and the databases in different regions use a data replication service (DRS) bidirectional replication technology to maintain consistency of data.

[0246] The configuration of the topology type can be implemented in various manners. For example, the configuration interface can display multiple topology types, and the user can select the topology type corresponding to the application system from the multiple topology types. For another example, the configuration interface can provide an input interface, and the user can input the topology type corresponding to the application system through the input interface. For yet another example, the configuration interface can provide a topology type identification interface, and the user can input necessary information, such as system configuration information of the application system or description information of the application system, and the topology type corresponding to the application system can be identified according to the information input by the user.

[0247] In the embodiments of this application, the configuration interface can also be used to receive a third service requirement of the application system input by the user, the third service requirement indicating N fault types of the application system, and the final output fusion detection result being one or more of the N fault types. That is, the cloud management platform can provide a configuration interface for the user to input the detection target, so as to determine the user's requirement according to the user's input, such as determining the fault type to be detected by the user, the level of the fault type, and the like.

[0248] In some scenarios, the user also does not need to input the third service requirement, and the cloud management platform can identify possible fault types according to the system configuration information of the application system, or the cloud management platform adopts a default fault type, and no specific limitation is made in this regard.

[0249] In addition to the above configuration, other possible configurations can also be included, and the embodiments of this application do not limit this.

[0250] Step 602: Obtain the running data of the application system at runtime. For example, as shown in FIG. 6, the cloud management platform can obtain the running data of the application system at runtime from the application system.

[0251] The running data of the application system at runtime can be obtained based on the topology type and the third service requirement input by the user, that is, it can be understood that after the user inputs the topology type and the third service requirement, the fault detection service for the application system has been configured, and the fault detection of the application system can be realized through the fault detection service, so that the running data of the application system can be collected for fault detection.

[0252] The timing of obtaining the running data and the implementation manner of obtaining can refer to the introduction in the foregoing step 202, and will not be repeated here.

[0253] Optionally, the configuration interface can also be used to receive data index configuration information input by the user, the data index configuration information being used to indicate the data index required to be collected for the application system, and the running data of the application system at runtime can be obtained according to the data index configuration information. The configuration of the data index information can also refer to the introduction in the foregoing step 202, and will not be repeated here.

[0254] Step 603: At least two fault detection methods are used to determine at least two fault detection results according to the running data, each fault detection result corresponding to one fault detection method; wherein each fault detection method has a corresponding priority under each fault type of the topology type.

[0255] Optionally, the at least two fault detection methods can be methods that are adopted by the cloud management platform by default. Optionally, the at least two fault detection methods can also be configured by a user. That is, the configuration interface is further configured to receive at least two fault detection methods configured by a user. For example, the configuration interface can display a plurality of optional fault detection methods, and a user can select at least two fault detection methods from the plurality of fault detection methods. Alternatively, the configuration interface can also provide a loading interface of a fault detection method, and a user can load at least two required fault detection methods through the loading interface. Alternatively, the configuration interface can also provide a self-defining interface of a fault detection method, and a user can define at least two required fault detection methods through the loading interface. The above various implementation manners can also be combined to implement the input of the at least two fault detection methods.

[0256] The specific fault detection method is not limited in the embodiment of the application, and the fault detection method can be a detection method based on an expert rule, a detection method based on a supervised learning model, a detection method based on an unsupervised learning model, or any other possible detection method.

[0257] Optionally, considering that the accuracies of different fault detection methods can be different, the different priorities are given to the different fault detection methods in the embodiment of the application, and the fusion of the fault detection results can be performed by referring to the priorities of the fault detection methods.

[0258] In the embodiment of the application, the priority corresponding to each fault detection method can be obtained through a fault rehearsal process. Next, the determination process of the priority of each fault detection method is introduced. Referring to FIG. 8, a flowchart of the determination process of the priority is shown.

[0259] Step S20: a preparation stage of the fault rehearsal, in which an exhaustive method is used to sort out all possible topology types of the application system, a fault mode library, and a fault type. The step can include identifying and defining the topology type of the application system, establishing the fault mode library, the fault mode library can include all potential faults and the influence of the faults on the application system, and determining the fault type, the determination of the fault type can be based on the source of the fault, the influence range, or the nature of the fault, and one fault type can correspond to at least one fault in the fault mode library.

[0260] An example of variables that may be involved in the fault drill is shown in Table 2 below. The number of schemes indicates the number of at least two fault detection methods used for fault detection, and the variable symbol N is used herein, where N is 3, indicating that there are three fault detection methods. The credibility refers to the credibility (probability) of the fault detection result of the fault detection method used in the fault drill, and the variable symbol T is used herein, where T is 0-1. The credibility threshold is used to measure whether the fault detection result of the current fault detection method is adopted in the actual scenario. The value range of the topology type, fault, and fault type can be the value in the code table, which contains the candidate values of the topology type, fault, and fault type respectively. The code tables corresponding to the topology type, fault, and fault type can be the same or different.

[0261] Table 2

[0262] Step S21: Perform a fault drill on the application system that needs fault detection. In the fault drill, a fault can be selectively introduced into the application system for a specific application system, and fault drill data when the application system runs the fault example is obtained.

[0263] Optionally, the fault drill process can also be performed according to the user's own needs. For example, the configuration interface of the cloud management platform can also be used to display a plurality of faults in the fault mode library, and receive M faults selected by the user from the plurality of faults, where M is a positive integer greater than 1. Each fault type of the N fault types can correspond to at least one fault in the fault mode library.

[0264] After the user selects M faults to be drilled in the application system, a plurality of fault examples corresponding to the M faults can be injected into the application system, and fault drill data when the application system runs the plurality of fault examples is obtained. The fault drill data, which can also be referred to as fault data samples, can be used to determine the reference detection result of the application system. The application system can run M fault examples to obtain corresponding fault drill data, i.e., one fault is injected each time to collect running data when the fault occurs; or, a plurality of fault examples can be run to obtain corresponding fault drill data, i.e., a plurality of faults can be injected each time to collect running data when the faults occur, or a combination of the two methods is used, so that more abundant fault drill data is obtained.

[0265] Optionally, the fault injected in the embodiment of the application can be a hardware fault, such as network delay, storage failure, etc., or a software fault, such as service crash, etc., or a database fault, such as database lock, etc.

[0266] Step S22: analyze the fault drill result. Wherein, at least two fault detection methods can be used to determine the reference detection result of the application system according to the fault drill data, the reference detection result can indicate a fault type corresponding to a fault drill data, and the priority of the at least two fault detection methods under each fault type of the topology type of the application system can be determined according to the reference detection result corresponding to each fault detection method.

[0267] One implementation is that the score of the at least two fault detection methods under each fault type of the topology type of the application system can be calculated according to the reference detection result, and the priority can be determined according to the score. For a fault type of a topology type, the higher the accuracy of the reference detection result obtained by a fault detection method, the higher the corresponding score. In addition to considering accuracy, other factors such as the complexity of the fault detection method can also be considered. Generally speaking, the higher the complexity, the lower the score should be.

[0268] Another implementation is that the reference detection result under each fault type of the topology type of the application system can be displayed to the user, and the priority of each fault detection method can be input by the user.

[0269] The above two implementations can be used alone or in combination. For example, the priority can be sorted by the first implementation, and then confirmed by the user again to improve the accuracy of the final priority.

[0270] Optionally, the priority can be determined by the number of fault detection methods, for example, if the number of fault detection methods is 5, the priority can include 5 levels, so that the priority of each fault detection method can be different. Optionally, the priority can be a fixed level, for example, the priority can be divided into three levels of high, medium and low, high using the number 3, medium using the number 2, and low using the number 1. The reference detection result of each fault detection method can be assigned to different fault detection methods, and the priority of different fault detection methods can be the same or different.

[0271] Step S23: display the fault drill result in the configuration interface. The fault drill result includes the priority of the at least two fault detection methods under each fault type of the topology type.

[0272] The configuration interface of the cloud management platform can also be used to display the final fault drill result, that is, the priority of the at least two fault detection methods under each fault type of the topology type of the application system can be displayed in the configuration interface. Optionally, the cloud management platform can provide a priority viewing interface, and when receiving a trigger command of the user for the priority viewing interface, the priority of the at least two fault detection methods under each fault type of the topology type of the application system can be displayed in the configuration interface.

[0273] The priority obtained above can be used to realize fusion of multiple fault detection results when the application system actually fails.

[0274] Step 604: fusing the at least two fault detection results according to the priority of each fault detection method to obtain a fused detection result.

[0275] In the embodiment of the application, when the application system actually fails, the at least two fault detection methods described above can be used to detect the fault, and the corresponding at least two fault detection results can be obtained. For example, when the application system actually fails, the fault type can be quickly identified according to the existing fault mode library and previous experience of the drill.

[0276] Optionally, for any fault detection result of the at least two fault detection results, the fault detection result can include the fault type to which the application system belongs and the probability (or confidence) of belonging to the fault type. When the probability is less than or equal to a certain threshold, the fault detection result can be considered invalid, and can be excluded from the at least two fault detection results, that is, the fault detection result does not need to participate in the subsequent fusion process. When the probability is greater than a certain threshold, the fault detection result can be considered valid, and the fault detection result can participate in the subsequent fusion process.

[0277] Optionally, if the at least two fault detection results are the same, that is, the fault types indicated by the at least two fault detection results are consistent, the final fault detection result can be directly outputted.

[0278] Optionally, if the at least two fault detection results are different, that is, the at least two fault detection results indicate at least two fault types, and the at least two fault types appear all or partial conflicts, the at least two fault detection results need to be fused, and the final fused detection result can be outputted.

[0279] For example, the probability of each fault detection result of the at least two fault detection results indicates the fault type to which the application system belongs, and the conflict can be solved by calculating the weight of each fault detection result, that is, the weight of each fault type can be determined according to the probability of the fault type indicated by the at least two fault detection results and the corresponding priority. The weight of each fault type is the product of the confidence of the fault detection result and the priority of the fault detection method.

[0280] For example, the weight of each fault detection result is calculated as follows:

[0281] The fault detection result 1 indicates that the probability of the fault type A is 0.85, the priority of the fault detection method corresponding to the fault detection result 1 under the fault type A of the topology type of the application system is 2 (namely, medium), and then the weight of the fault detection result 1 is 0.85*2=1.7.

[0282] The fault detection result 2 indicates that the probability of the fault type B is 0.7, the priority of the fault detection method corresponding to the fault detection result 2 under the fault type B of the topology type of the application system is 1 (namely, low), and then the weight of the fault detection result 2 is 0.7*1=0.7.

[0283] The fault detection result 3 indicates that the probability of the fault type B is 0.75, the priority of the fault detection method corresponding to the fault detection result 3 under the fault type A of the topology type of the application system is 1 (namely, low), and then the weight of the fault detection result 3 is 0.75*1=0.75.

[0284] For different schemes with the same fault detection result, the weights corresponding thereto can be added. For example, the three fault detection results above indicate the fault type A and the fault type B, the final weight of the fault type A is 1.7, the final weight of the fault type B is 1.45, the final weight of the fault type A is greater than the final weight of the fault type B, and thus it can be determined that the application system belongs to the fault type A. That is, after obtaining the weight of each fault type, the fault type with the highest weight can be selected as the final detection result, so that the user can select the most suitable solution for fault repair according to the final detection result.

[0285] In step 605, the fusion detection result of the application system is displayed on the result interface of the fault detection service.

[0286] In the embodiment, the cloud management platform can provide the result interface of the fault detection service, and the fusion detection result finally obtained can be displayed on the result interface, and the user can view the fusion detection result in the result interface, so as to understand the fault existing in the current application system. The fusion detection result refers to the result obtained by fusing at least two fault detection results according to the priorities of the at least two fault detection methods, that is, the method of the embodiment can output the fusion of different fault detection results according to the priorities obtained by fault simulation.

[0287] Specifically, as shown in FIG. 6, the user can trigger the viewing of the fault detection result through the client operation, and correspondingly, the cloud management platform can send the fusion detection result to be displayed to the client according to the operation, and the client can display the fusion detection result on the result interface.

[0288] Optionally, when the fusion detection result is displayed on the result interface, a topology relationship diagram of the application system can be displayed on the result interface, and the topology node of the fault in the application system is marked in the topology relationship diagram according to the fusion detection result, so that the user can more intuitively view the topology node of the fault. Alternatively, other ways can be used to display the fusion detection result, which is not limited in this regard.

[0289] Optionally, the finally output fusion detection result can include the weight of each fault type in the plurality of fault types indicated by the at least two fault detection results, and / or the fault type with the largest weight in the plurality of fault types.

[0290] Through the above embodiments, the fault detection results obtained by the plurality of fault detection methods are comprehensively decided in combination with the fault mode library, the fault drill and the architecture topology mode. The above process embodies a systematic and scientific fault response mechanism. The fault is pre-vaccinated through the fault drill, and the adaptability and recovery ability of the application system when encountering a real fault are improved. In addition, through the double screening of priority and credibility, the accuracy and efficiency of the fault detection result are ensured.

[0291] The two fault detection methods provided by the embodiments of the present application can be implemented separately or in combination. When implemented in combination, the fusion of the plurality of fault detection results at the same level in the above hierarchical fusion process can adopt the manner of the second fault detection method to further improve the accuracy of fault detection.

[0292] Based on the same inventive concept, the embodiments of the present application also provide a cloud service-based fault detection device. The device can be applied to a cloud management platform for managing infrastructure providing cloud services. The infrastructure includes multiple regions, each region including at least one cloud data center, and the cloud services running on at least one server of at least one cloud data center located in one of the multiple regions. FIG. 9 is a structural schematic diagram of a cloud service-based fault detection device according to an embodiment of the present application. As shown in FIG. 9, the device includes:

[0293] The service configuration module 901 is configured to provide a configuration interface of the fault detection service. The configuration interface is configured to receive system configuration information of an application system and first service requirements input by a user. The application system adopts a hierarchical architecture, and the hierarchical architecture includes multiple levels. The multiple levels include multiple topology nodes. Each topology node is located in one of the multiple levels. The system configuration information is used to indicate a topology relationship between the multiple topology nodes. The first service requirements indicate that fault detection is performed on at least two levels in the multiple levels.

[0294] The data acquisition module 902 is configured to acquire running data of a plurality of topology nodes of an application system at runtime, and the running data of the plurality of topology nodes is used to determine fault detection results corresponding to at least two levels.

[0295] The result display module 903 is configured to display a fusion detection result of the application system on a result interface of the fault detection service, and the fusion detection result is obtained by fusing the fault detection results corresponding to the at least two levels according to the topology relationship.

[0296] In a possible implementation, the configuration interface is further configured to receive a second service requirement input by a user, and the second service requirement is used to indicate N candidate faults of the application system, the N candidate faults corresponding to a level higher than any level of the at least two levels, or the N candidate faults corresponding to a highest level of the at least two levels.

[0297] The result display module 903 is specifically configured to display the fusion detection result on the result interface based on the second service requirement input by the user. The fusion detection result includes at least one candidate fault of the N candidate faults, and the at least one candidate fault is obtained by fusing the fault detection results corresponding to the at least two levels in a direction from low level to high level according to the topology relationship.

[0298] In a possible implementation, the at least two levels include a first level and a second level, the first level includes a plurality of first topology nodes, and the second level includes a plurality of second topology nodes. The fault detection results corresponding to the at least two levels include a first fault detection result corresponding to the first level and a second fault detection result corresponding to the second level. The fusion detection result includes a third fault detection result corresponding to the first level, and the third fault detection result is determined according to the topology relationship and the second fault detection result. The fusion detection result further includes a fourth fault detection result, and the fourth fault detection result is obtained by fusing the third fault detection result and the first fault detection result.

[0299] In a possible implementation, the third fault detection result includes a plurality of confidence levels, the first fault detection result is used to indicate fault information of the plurality of first topology nodes, and the plurality of confidence levels correspond to the plurality of first topology nodes in a one-to-one manner.

[0300] In a possible implementation, the second fault detection result indicates a respective fault probability of each of the plurality of second topology nodes. The third fault detection result comprises one or more of: a confidence level that each of the first topology nodes is fault-free, determined according to the respective fault probability of each of the plurality of second topology nodes; a confidence level that each of the first topology nodes belongs to a first fault of the N candidate faults, determined according to the respective fault probability of each of the plurality of second topology nodes; a confidence level that each of the first topology nodes belongs to a second fault of the N candidate faults, determined according to the respective fault probability of each of the first type of second topology nodes in the plurality of second topology nodes, the second fault affecting the operation of the first type of second topology nodes; or a confidence level that each of the first topology nodes belongs to a third fault of the N candidate faults, determined according to the respective fault probability of each of the second type of second topology nodes in the plurality of second topology nodes, the third fault affecting the operation of the second type of second topology nodes.

[0301] In a possible implementation, the configuration interface is further configured to receive data indicator configuration information input by the user, the data indicator configuration information being used to indicate data indicators required to be collected for topology nodes in each of the plurality of levels. The data acquisition module 902 is specifically configured to acquire operation data of the plurality of topology nodes of the application system at runtime according to the data indicator configuration information.

[0302] In a possible implementation, the configuration interface is further configured to receive a data indicator configuration file input by the user, the data indicator configuration file comprising the data indicator configuration information; or the configuration interface is further configured to display a plurality of data indicators, and receive a data indicator selected by the user from the plurality of data indicators, the data indicator configuration information comprising the data indicator selected by the user.

[0303] In a possible implementation, the configuration interface is configured to display a plurality of levels, and receive at least two levels selected by the user from the plurality of levels; or the configuration interface is configured to receive at least two fault detection methods input by the user, wherein each of the fault detection methods is used to obtain a fault detection result corresponding to one of the at least two levels.

[0304] In a possible implementation, the configuration interface is configured to receive at least one expert rule input by the user, wherein each of the expert rules is used to obtain a fault detection result corresponding to one of the levels; or the configuration interface is configured to receive at least one fault detection model input by the user, wherein each of the fault detection models is used to obtain a fault detection result corresponding to one of the levels after each of the fault detection models is trained by using a training method corresponding to the fault detection model.

[0305] In a possible implementation, the configuration interface is configured to receive a system configuration file input by a user, the system configuration file including system configuration information; or the configuration interface is configured to receive an editing operation input by a user, the editing operation being used to edit the topology nodes and the topology relationship between the topology nodes.

[0306] In a possible implementation, the result display module 903 is specifically configured to display a topology relationship diagram of the application system on a result interface, and mark the faulty topology nodes in the application system in the topology relationship diagram according to the fusion detection result.

[0307] The apparatus can be used to execute the method steps in the embodiments shown in FIG. 2, and therefore the introduction of the apparatus can refer to the introduction of the embodiments shown in FIG. 2, which will not be repeated here.

[0308] It should be noted that each of the above modules can be implemented by software or by hardware. For example, the service configuration module 901 is taken as an example, and the implementation of the service configuration module 901 is introduced. Similarly, the implementation of other modules can refer to the implementation of the service configuration module 901.

[0309] When implemented by software, the service configuration module 901 can be an application program or a code block running on a computer device. The computer device can be at least one of a physical host, a virtual machine, a container, and the like. Further, the computer device can be one or more. For example, the service configuration module 901 can be an application program running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the application program can be distributed in the same availability zone (AZ) or in different AZs. The multiple hosts / virtual machines / containers used to run the application program can be distributed in the same region or in different regions. Generally, one region can include multiple AZs.

[0310] Similarly, the multiple hosts / virtual machines / containers used to run the application program can be distributed in the same virtual private cloud (VPC) or in multiple VPCs. Generally, one region can include multiple VPCs, and one VPC can include multiple AZs.

[0311] When implemented by hardware, at least one computing device, such as a server, etc., can be included in the service configuration module 901. Alternatively, the cloud resource configuration service configuration module 901 can also be a device implemented by an application-specific integrated circuit (ASIC) or a programmable logic device (PLD), etc. Among them, the PLD can be implemented by a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0312] The plurality of computing devices included in the service configuration module 901 can be distributed in the same AZ, or distributed in different AZs. The plurality of computing devices included in the cloud resource configuration service configuration module 901 can be distributed in the same region, or distributed in different regions. Similarly, the plurality of computing devices included in the service configuration module 901 can be distributed in the same VPC, or distributed in multiple VPCs. Among them, the plurality of computing devices can be any combination of servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

[0313] It should be noted that each of the above modules can be used to perform part or all of the steps in the cloud service-based fault detection method.

[0314] The various modules of the cloud service-based fault detection apparatus disclosed in the embodiments of the present application have clear division of labor and close cooperation. The cooperation and mutual cooperation of each module can efficiently complete the fault detection service for the application system.

[0315] Based on the same inventive concept, the embodiments of the present application also provide another cloud service-based fault detection apparatus. The apparatus can be applied to a cloud management platform for managing infrastructure providing cloud services. The infrastructure includes multiple regions, each region includes at least one cloud data center, and the cloud services run on at least one server of at least one cloud data center in one of the multiple regions. FIG. 10 is a structural schematic diagram of a cloud service-based fault detection apparatus provided by an embodiment of the present application. As shown in FIG. 10, the apparatus includes:

[0316] The service configuration module 1001 is configured to provide a configuration interface of the fault detection service, and the configuration interface is configured to receive a topology type of an application system and third service requirements input by a user, the third service requirements indicating N fault types of the application system, and N is a positive integer greater than 1.

[0317] The data acquisition module 1002 is configured to acquire running data of the application system.

[0318] The detection execution module 1003 is configured to determine at least two fault detection results according to the running data by using at least two fault detection methods, each fault detection result corresponding to one fault detection method, and each fault detection method has a corresponding priority under each fault type of the topology type.

[0319] The result display module 1004 is configured to display a fusion detection result of the application system on a result interface of the fault detection service, and the fusion detection result is obtained by fusing the at least two fault detection results according to the priorities of the at least two fault detection methods.

[0320] In a possible implementation, the configuration interface is further configured to display a plurality of faults in a fault mode library, and receive M faults selected by the user from the plurality of faults, and M is a positive integer greater than 1; and each fault type of the N fault types corresponds to at least one fault in the fault mode library.

[0321] The apparatus further includes a fault drill module 1005 configured to acquire fault drill data of the application system running a plurality of fault samples, the plurality of fault samples corresponding to the M faults, and the fault drill data is used to determine a reference detection result of the application system.

[0322] The service configuration module 1001 is further configured to display a fault drill result on the configuration interface, and the fault drill result includes the priorities of the at least two fault detection methods under each fault type of the topology type, and the fault drill result is determined according to reference detection results respectively corresponding to the at least two fault detection methods.

[0323] In a possible implementation, each fault detection result of the at least two fault detection results indicates a probability of a fault type to which the application system belongs. The fusion detection result includes one or more of the following: a weight of each fault type in a plurality of fault types indicated by the at least two fault detection results, the weight of each fault type being determined according to the probability of the fault type indicated by the at least two fault detection results and the corresponding priority; or, a fault type with the largest weight in the plurality of fault types.

[0324] In a possible implementation, the configuration interface is further configured to receive data index configuration information input by the user, the data index configuration information being used to indicate data indexes required to be collected by the application system.

[0325] The data acquisition module 1002 is specifically configured to acquire running data of the application system according to the data index configuration information.

[0326] In a possible implementation, the configuration interface is further configured to receive at least two fault detection methods configured by the user.

[0327] The apparatus can be configured to execute the method steps in the embodiments shown in FIG. 6, and thus the description of the apparatus can refer to the description of the embodiments shown in FIG. 6, which will not be repeated here.

[0328] It should be noted that each of the above modules can be implemented by software or by hardware. For example, the implementation of each module can also refer to the implementation of the service configuration module 901, which will not be repeated here.

[0329] The embodiment of the present application further provides a computing device, which is shown in FIG. 11. FIG. 11 is a structural schematic diagram of a computing device 1100 for running a cloud service-based fault detection method according to an embodiment of the present application. The computing device 1100 includes a bus 1101, a processor 1103, a memory 1102 and a communication interface 1104. The processor 1103, the memory 1102 and the communication interface 1104 communicate with each other through the bus 1101. The computing device 1100 can be a server or a terminal device. It should be understood that the number of processors and memories in the computing device 1100 is not limited in the present application.

[0330] The bus 1101 can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For the convenience of representation, only one line is shown in FIG. 11, but it does not mean that there is only one bus or only one type of bus. The bus 1101 can include a path for transmitting information between various components (for example, the memory 1102, the processor 1103, the communication interface 1104) of the computing device 1100.

[0331] The processor 1103 can include any one or more of a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP), among other processors.

[0332] The memory 1102 can include volatile memory, such as random access memory (RAM), and non-volatile memory, such as read-only memory (ROM), flash memory, a hard disk drive (HDD), or a solid-state drive (SSD), among others.

[0333] The memory 1102 stores executable program code that, when executed, implements the cloud-service-based fault detection method. That is, the memory 1102 stores instructions for a cloud management platform to execute the cloud-service-based fault detection method.

[0334] The communication interface 1104 uses a transceiver module, such as but not limited to a network interface card or a transceiver, to enable communication between the computing device 1100 and other devices or communication networks.

[0335] Embodiments of the present disclosure also provide a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device, such as a desktop computer, a laptop computer, or a smartphone.

[0336] Referring to FIG. 12, FIG. 12 is a structural schematic diagram of a computing device cluster that executes a cloud-service-based fault detection method according to an embodiment of the present disclosure. The computing device cluster includes at least one computing device 1100. The memory 1102 in one or more computing devices 1100 in the computing device cluster can store the same cloud management platform for the instructions of the cloud-service-based fault detection method.

[0337] In some possible implementations, one or more computing devices 1100 in the computing device cluster can also be used to execute part of the instructions of the cloud service based fault detection method. In other words, the combination of one or more computing devices 1100 can collectively execute the instructions of the cloud service based fault detection method.

[0338] It should be noted that the memories 1102 in different computing devices 1100 in the computing device cluster can store different instructions for executing part of the functions of the cloud management platform. That is, the instructions stored in the memories 1102 in different computing devices 1100 can implement the functions of one or more modules in FIG. 9 or FIG. 10 described above.

[0339] The embodiments of the present application also provide a computer program product containing instructions. The computer program product can be a software or program product containing instructions, which can be run on a computing device or stored in any available medium. When the computer program product is run on at least one computing device, the at least one computing device is caused to perform the cloud service based fault detection method applied to the cloud management platform described above.

[0340] The embodiments of the present application also provide a computer readable storage medium. The computer readable storage medium can be any available medium that the computing device can store or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (for example, a floppy disk, a hard disk, a magnetic tape), an optical medium (for example, a DVD), or a semiconductor medium (for example, a solid state disk), etc. The computer readable storage medium includes instructions that instruct the computing device to perform the cloud service based fault detection method applied to the cloud management platform described above.

[0341] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, and not to limit them; although the above embodiments of the present application have been described in detail, those skilled in the art should understand that they can still modify the technical solutions recorded in the above embodiments, or make equivalent replacements to some technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the protection scope of the technical solutions of the embodiments of the present application.

Claims

1. A cloud service-based fault detection method, characterized by, The method is applied to a cloud management platform for managing an infrastructure providing cloud services, the infrastructure comprising being arranged in a plurality of regions, each region comprising at least one cloud data center, the cloud services running on at least one server of at least one cloud data center located in one of the plurality of regions, the method comprising: providing a configuration interface of a fault detection service, the configuration interface being configured to receive system configuration information and first service requirements of an application system input by a user, the application system adopting a hierarchical architecture, the hierarchical architecture comprising a plurality of levels, the plurality of levels comprising a plurality of topology nodes, each topology node being located in one of the plurality of levels, the system configuration information being configured to indicate a topological relationship between the plurality of topology nodes, the first service requirements being configured to indicate fault detection for at least two levels of the plurality of levels; obtaining running data of the plurality of topology nodes when the application system is running, the running data of the plurality of topology nodes being configured to determine fault detection results corresponding to the at least two levels; displaying a fusion detection result of the application system on a result interface of the fault detection service, the fusion detection result being obtained by fusing the fault detection results corresponding to the at least two levels according to the topological relationship.

2. The method of claim 1, wherein: the configuration interface is further configured to receive second service requirements input by the user, the second service requirements being configured to indicate N candidate faults of the application system, the N candidate faults corresponding to a level higher than any level of the at least two levels, or the N candidate faults corresponding to a highest level of the at least two levels; the displaying of the fusion detection result of the application system on the result interface of the fault detection service comprises: based on the second service requirements input by the user, displaying the fusion detection result on the result interface, wherein the fusion detection result comprises at least one candidate fault of the N candidate faults, the at least one candidate fault being obtained by fusing the fault detection results corresponding to the at least two levels in a direction from low level to high level according to the topological relationship.

3. The method according to claim 1 or 2, characterized in that, the at least two levels comprise a first level and a second level, the first level comprising a plurality of first topology nodes, and the second level comprising a plurality of second topology nodes; wherein the fault detection results corresponding to the at least two levels comprise a first fault detection result corresponding to the first level and a second fault detection result corresponding to the second level; the fusion detection result comprises a third fault detection result determined according to the topological relationship and the second fault detection result, the third fault detection result corresponding to the first level, and / or the fusion detection result comprises a fourth fault detection result obtained by fusing the third fault detection result and the first fault detection result.

4. The method of claim 3, wherein, The third fault detection result includes a plurality of confidence degrees, the first fault detection result is used to indicate fault information of the plurality of first topology nodes, and the plurality of confidence degrees correspond to the plurality of first topology nodes one by one.

5. The method according to claim 3 or 4, characterized in that, The second fault detection result indicates respective fault probabilities of the plurality of second topology nodes. The third fault detection result includes one or more of the following: a confidence degree of each first topology node being fault-free determined according to the respective fault probabilities of the plurality of second topology nodes; a confidence degree of each first topology node belonging to a first fault of the N candidate faults determined according to the respective fault probabilities of the plurality of second topology nodes; a confidence degree of each first topology node belonging to a second fault of the N candidate faults determined according to respective fault probabilities of first-type second topology nodes in the plurality of second topology nodes, the second fault affecting operation of the first-type second topology nodes; or a confidence degree of each first topology node belonging to a third fault of the N candidate faults determined according to respective fault probabilities of second-type second topology nodes in the plurality of second topology nodes, the third fault affecting operation of the second-type second topology nodes.

6. The method of any of claims 1-5, wherein: the configuration interface is further configured to receive data indicator configuration information input by the user, the data indicator configuration information being used to indicate data indicators required to be collected for topology nodes of each level in the plurality of levels; obtaining operation data of the plurality of topology nodes of the application system at runtime includes obtaining operation data of the plurality of topology nodes of the application system at runtime according to the data indicator configuration information. the configuration interface is further configured to receive data indicator configuration information input by the user, including:

7. The method of claim 6, wherein, the configuration interface is further configured to receive a data indicator configuration file input by the user, the data indicator configuration file including the data indicator configuration information; or the configuration interface is further configured to display a plurality of data indicators and receive a data indicator selected by the user from the plurality of data indicators, the data indicator configuration information including the data indicator selected by the user. the configuration interface is configured to receive first service requirements of the application system input by the user, including:

8. The method according to any one of claims 1 to 7, characterized in that, the configuration interface is configured to display a plurality of levels and receive the at least two levels selected by the user from the plurality of levels; or the configuration interface is configured to receive at least two fault detection methods input by the user, wherein each fault detection method is used to obtain a fault detection result corresponding to one level in the at least two levels. the configuration interface is configured to receive at least two fault detection methods input by the user, including one or more of the following:

9. The method of claim 8, wherein, the configuration interface is configured to receive at least one expert rule input by the user, wherein each expert rule is used to obtain a fault detection result corresponding to one level; or the configuration interface is configured to receive at least one expert rule input by the user, wherein each expert rule is used to obtain a fault detection result corresponding to one level; or The configuration interface is configured to receive at least one fault detection model input by the user, wherein each fault detection model is trained by using a corresponding training method of the fault detection model, and the trained fault detection model is configured to obtain a fault detection result corresponding to a level according to a corresponding fault detection method.

10. The method according to any one of claims 1 to 9, characterized in that, The configuration interface is configured to receive system configuration information of the application system input by the user, including: The configuration interface is configured to receive a system configuration file input by the user, wherein the system configuration file includes the system configuration information; or The configuration interface is configured to receive an editing operation input by the user, wherein the editing operation is configured to edit a topology node and edit a topology relationship between topology nodes.

11. The method according to any one of claims 1 to 10, characterized in that, The result interface of the fault detection service is configured to display a fusion detection result of the application system, including: The result interface is configured to display a topology relationship diagram of the application system; According to the fusion detection result, a topology node with a fault in the application system is marked in the topology relationship diagram.

12. A failure detection method of an application system, characterized by, The method is applied to a cloud management platform, wherein the cloud management platform is configured to manage an infrastructure providing cloud services, the infrastructure includes a plurality of regions, each region includes at least one cloud data center, the cloud services run on at least one server of at least one cloud data center located in one of the plurality of regions, and the method includes: Providing a configuration interface of a fault detection service, wherein the configuration interface is configured to receive a topology type of an application system and a third service requirement input by a user, and the third service requirement indicates N types of faults of the application system, wherein N is a positive integer greater than 1; Obtaining running data of the application system during running; At least two fault detection methods are used to determine at least two fault detection results according to the running data, and each fault detection result corresponds to a fault detection method; wherein under each fault type of the topology type, the at least two fault detection methods have corresponding priorities respectively; In the result interface of the fault detection service, a fusion detection result of the application system is displayed, wherein the fusion detection result is obtained by fusing the at least two fault detection results according to the priorities of the at least two fault detection methods respectively.

13. The method of claim 12, wherein: The configuration interface is further configured to display a plurality of faults included in a fault mode library, and receive M types of faults selected by the user from the plurality of faults, wherein M is a positive integer greater than 1; wherein each fault type of the N types of faults corresponds to at least one fault of the M types of faults; The method further includes: Obtaining fault exercise data of the application system when a plurality of fault samples run, wherein the plurality of fault samples correspond to the M types of faults, and the fault exercise data is used to determine a reference detection result of the application system; The configuration interface displays a fault drill result, the fault drill result including priorities of the at least two fault detection methods under each fault type of the topology type, and the fault drill result being determined according to reference detection results corresponding to the at least two fault detection methods.

14. The method according to claim 12 or 13, characterized in that, Each fault detection result of the at least two fault detection results indicates a probability of a fault type to which the application system belongs; The fusion detection result includes one or more of the following: The weight of each fault type in the plurality of fault types indicated by the at least two fault detection results, the weight of each fault type being determined according to a probability of a fault type indicated by the at least two fault detection results and a corresponding priority; or The fault type with the largest weight in the plurality of fault types.

15. The method of any one of claims 12-14, wherein: The configuration interface is further configured to receive data indicator configuration information input by the user, the data indicator configuration information being used to indicate data indicators required to be collected for the application system; The obtaining of the running data of the application system in operation includes: Obtaining the running data of the application system in operation according to the data indicator configuration information.

16. The method according to any one of claims 12 to 15, characterized in that, The configuration interface is further configured to receive the at least two fault detection methods configured by the user.

17. A cloud service based fault detection apparatus, characterized by, The device is applied to a cloud management platform, the cloud management platform being used to manage infrastructure providing cloud services, the infrastructure including being arranged in multiple regions, each region including at least one cloud data center, the cloud services being run on at least one server of at least one cloud data center located in one region of the multiple regions, and the device including: A service configuration module configured to provide a configuration interface of a fault detection service, the configuration interface being configured to receive system configuration information of an application system and first service requirements input by a user, the application system adopting a layered architecture, the layered architecture including multiple levels, the multiple levels including multiple topology nodes, each topology node being located in one level of the multiple levels, the system configuration information being used to indicate a topology relationship between the multiple topology nodes, and the first service requirements indicating fault detection for at least two levels of the multiple levels; A data acquisition module configured to acquire running data of the multiple topology nodes of the application system in operation, the running data of the multiple topology nodes being used to determine fault detection results corresponding to the at least two levels; A result display module configured to display a fusion detection result of the application system in a result interface of the fault detection service, the fusion detection result being obtained by fusing the fault detection results corresponding to the at least two levels according to the topology relationship.

18. A cloud service based fault detection apparatus, characterized by, The device is applied to a cloud management platform, the cloud management platform being used to manage infrastructure providing cloud services, the infrastructure including being arranged in multiple regions, each region including at least one cloud data center, the cloud services being run on at least one server of at least one cloud data center located in one region of the multiple regions, and the device including: A service configuration module configured to provide a configuration interface of a fault detection service, the configuration interface configured to receive a topology type of an application system and third service requirements input by a user, the third service requirements indicating N types of faults of the application system, N being a positive integer greater than 1; A data acquisition module configured to acquire running data of the application system; A detection execution module configured to determine at least two fault detection results according to the running data by using at least two fault detection methods, each fault detection result corresponding to one fault detection method; wherein, under each fault type of the topology type, the at least two fault detection methods have corresponding priorities respectively; A result display module configured to display a fusion detection result of the application system on a result interface of the fault detection service, the fusion detection result being obtained by fusing the at least two fault detection results according to the priorities of the at least two fault detection methods respectively.

19. A cluster of computing devices, characterized in that, At least one computing device, each computing device comprising a processor and a memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster executes the method of any one of claims 1-11, or executes the method of any one of claims 12-16.

20. A computer program product comprising instructions, characterized in that, When the instructions are executed by the computer device cluster, the computer device cluster executes the method of any one of claims 1-11, or executes the method of any one of claims 12-16.

21. A computer-readable storage medium, characterized in that, Computer program instructions, when executed by a computing device cluster, the computing device cluster executes the method of any one of claims 1-11, or executes the method of any one of claims 12-16.

Images