Fault detection method, device and equipment in private cloud scenario and medium

Abstract

The embodiment of the application discloses a fault detection method, device, equipment and medium in a private cloud environment. The method comprises the following steps: obtaining input parameters corresponding to a fault detection task in a private cloud environment, determining one or more detection objects for the fault detection task based on the input parameters, and obtaining detection data of each detection object; determining whether target fault data exists in the detection data of each detection object; if the target fault data exists in the detection data of any detection object in the detection objects, obtaining target detection data associated with the target fault data from the detection data, and displaying the target detection data on a fault detection interface, so that automatic troubleshooting in a private scene can be realized, and the fault detection efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of cloud technology, and in particular to a fault detection method, apparatus, device and medium in a private cloud scenario. Background Technology

[0002] In a public cloud environment, public clouds can provide customers with shared resource services and typically offer accompanying automated management systems, such as resource management and fault detection, eliminating the need for manual intervention. However, in a private cloud environment, due to its inherent characteristics and the fact that its customers are mostly government agencies, enterprises, and banks, the network environment is private and cannot provide public network access. Therefore, the resource services provided by a private cloud are usually managed by the customer themselves. In other words, in a private cloud scenario, when resource services malfunction, fault detection or troubleshooting usually requires on-site and manual intervention.

[0003] Currently, the methods for detecting on-site faults involve manual processes, including initial troubleshooting by on-site technicians, contacting R&D personnel, identifying the person in charge of the fault, contacting the specific person in charge, initiating meetings or taking photos of logs with mobile phones, and locating the fault online through video or images. This process is quite complex, and the chain from the occurrence of the fault to finding the corresponding person in charge is relatively long, which is time-consuming and labor-intensive, and cannot improve the efficiency of fault detection in private cloud scenarios. Summary of the Invention

[0004] This application provides a fault detection method, apparatus, device, and medium for a private cloud scenario, which can realize automated fault diagnosis in a private scenario and improve fault detection efficiency.

[0005] The first aspect of this application discloses a fault detection method in a private cloud scenario, the method comprising:

[0006] Obtain the input parameters corresponding to the fault detection task in the private cloud environment, determine one or more detection objects for the fault detection task based on the input parameters, and obtain the detection data of each detection object;

[0007] Determine whether target fault data exists in the detection data of each of the detection objects;

[0008] If target fault data exists in the detection data of any of the detection objects, then target detection data associated with the target fault data is obtained from the detection data, and the target detection data is displayed on the fault detection interface.

[0009] The second aspect of this application discloses a fault detection device in a private cloud environment, the device comprising:

[0010] The first acquisition module is used to acquire the input parameters corresponding to the fault detection task in the private cloud environment, determine one or more detection objects for the fault detection task based on the input parameters, and acquire the detection data of each detection object.

[0011] The determination module is used to determine whether target fault data exists in the detection data of each detection object;

[0012] The second acquisition module is used to acquire target detection data associated with the target fault data from the detection data if the detection data of any of the detection objects contains target fault data, and to display the target detection data on the fault detection interface.

[0013] A third aspect of this application discloses a fault detection device, including a processor and a memory, wherein the memory is used to store a computer program, the computer program includes program instructions, and the processor is configured to invoke the program instructions to execute the method described in the first aspect.

[0014] A fourth aspect of this application discloses a computer-readable storage medium storing a computer program, the computer program including program instructions that, when executed by a processor, cause the processor to perform the method described in the first aspect.

[0015] A fifth aspect of this application discloses a computer program product or computer program, the computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, causing the computer device to perform the method described in the first aspect.

[0016] In this embodiment, input parameters corresponding to the fault detection task can be obtained to determine one or more detection objects for the fault detection task based on the input parameters, and detection data of each detection object can be obtained. After obtaining the detection data of each detection object, it can be further determined whether target fault data exists in the detection data of each detection object. If target fault data exists in the detection data of any detection object, target detection data associated with the target fault data can be obtained from the detection data, and the target detection data can be displayed on the fault detection interface. This can realize automated fault diagnosis in private scenarios, allowing on-site inspection personnel to quickly locate on-site faults, solve tedious and error-prone manual operations, and improve the efficiency of fault diagnosis and fault detection. Attached Figure Description

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

[0018] Figure 1a This is a schematic diagram of the architecture of a fault detection system provided in an embodiment of this application;

[0019] Figure 1b This is a schematic diagram of a fault detection scheme in a private cloud environment provided in an embodiment of this application;

[0020] Figure 2 This is a flowchart illustrating a fault detection method in a private cloud environment provided in an embodiment of this application;

[0021] Figure 3a This is a schematic diagram of a process for inspecting a pod provided in an embodiment of this application;

[0022] Figure 3b This is a schematic diagram of a registration check process provided in an embodiment of this application;

[0023] Figure 3c This is a schematic diagram of a login check process provided in an embodiment of this application;

[0024] Figure 4 This is a schematic diagram of the structure of a fault detection device provided in an embodiment of this application;

[0025] Figure 5 This is a schematic diagram of the structure of a fault detection device provided in an embodiment of this application. Detailed Implementation

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

[0027] Cloud technology refers to a managed technology that unifies a series of resources such as hardware, software, and networks within a wide area network or local area network to achieve data computing, storage, processing, and sharing.

[0028] Cloud technology is a collective term for network technology, information technology, integration technology, management platform technology, and application technology applied to the cloud computing business model. It can form resource pools, providing flexible and convenient on-demand access. Cloud computing technology will become a crucial support. Backend services of technical network systems require substantial computing and storage resources, such as video websites, image websites, and many portal websites. With the rapid development and application of the internet industry, every item may have its own identification mark in the future, requiring transmission to backend systems for logical processing. Data at different levels will be processed separately, and various industry data will all require robust system support, which can only be achieved through cloud computing.

[0029] Cloud computing is a computing model that distributes computing tasks across a resource pool consisting of a large number of computers, enabling various application systems to access computing power, storage space, and information services as needed. The network providing these resources is called the "cloud." From the user's perspective, the resources in the "cloud" are infinitely scalable, readily available, on-demand, expandable, and pay-as-you-go.

[0030] As a provider of fundamental cloud computing capabilities, a cloud resource pool (referred to as a cloud platform, generally called an IaaS (Infrastructure as a Service) platform) is established. Various types of virtual resources are deployed in the resource pool for external customers to choose from. The cloud resource pool mainly includes: computing devices (virtualized machines containing operating systems), storage devices, and network devices.

[0031] A private cloud is a cloud infrastructure and hardware / software resources created within a firewall, allowing various departments within an organization or enterprise to share resources within a data center. In addition to hardware resources, creating a private cloud typically involves cloud equipment (IaaS, Infrastructure as a Service) software.

[0032] Private cloud computing also comprises three layers: cloud hardware, cloud platform, and cloud services. The difference is that cloud hardware consists of the user's own personal computer or server, rather than the cloud computing provider's data center. Cloud computing providers build data centers to provide public cloud services to millions of users, thus requiring hundreds of thousands or even millions of servers. Private cloud computing, for individuals, serves only family and friends; for businesses, it serves only their own employees, customers, and suppliers. Therefore, an individual's or business's own personal computer or server is sufficient to provide cloud services.

[0033] Based on the aforementioned introduction to cloud technology, this application proposes a fault detection scheme in a private cloud environment. The general principle of this fault detection scheme is as follows: Input parameters corresponding to the fault detection task can be obtained to determine the target detection data corresponding to the fault. For example, firstly, input parameters corresponding to the fault detection task can be obtained to determine one or more detection objects for the fault detection task, and detection data for each detection object can be obtained. After obtaining the detection data for each detection object, it can be further determined whether target fault data exists in the detection data of each detection object. If target fault data exists in the detection data of any detection object, target detection data associated with the target fault data can be obtained from the detection data, and the target detection data can be displayed on the fault detection interface. This enables automated fault diagnosis in a private environment, allowing on-site personnel to quickly locate on-site faults, reducing the workload of those responsible for the fault, and solving tedious and error-prone manual operations, thereby improving the efficiency of fault diagnosis and troubleshooting.

[0034] In specific implementations, the aforementioned fault detection scheme can be applied to fault detection equipment (or fault detection system or fault detection platform), which can be a server or a terminal. The terminal mentioned here can be a smartphone, tablet, laptop, desktop computer, or other devices, or peripheral devices such as a gamepad or touchscreen; the server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms, etc. For example, when the fault detection equipment is a server, this application embodiment provides a fault detection system, such as... Figure 1a As shown, the fault detection system includes at least one terminal and at least one server. The terminal can acquire input parameters input by the inspector and upload the acquired input parameters to the server (i.e., the fault detection device), so that the fault detection device can obtain the input parameters and determine the target detection data based on the input parameters. Furthermore, the target detection data can be displayed on the fault detection interface of the terminal. The terminal and the server can be directly or indirectly connected via wired or wireless communication, which is not limited herein.

[0035] In one implementation, the above-mentioned fault detection scheme can be applied to detection software such as applications or mini-programs. The testing personnel can input some corresponding instructions (such as the input parameters mentioned above) on the relevant interface of the application or mini-program, and then obtain the target detection data associated with the fault through the fault detection scheme in this application, and display it on the fault detection interface, so that the specific fault on site can be determined based on these target detection data.

[0036] For further details, please see Figure 1b , Figure 1b This is an interactive diagram illustrating an application scenario of a fault detection solution in a private cloud environment provided in this application embodiment. It should be noted that in fault detection, R&D personnel (who can be understood as the fault manager) can locate specific fault problems and provide solutions based on fault data associated with the fault. In this case, to automatically acquire fault data for fault location, the fault detection device in this application can be used to acquire the fault data; this fault inspection device can also be called an inspection tool. Specific application scenarios can be as follows... Figure 1b As shown, Figure 1b As shown, R&D personnel or field testing personnel can upload the inspection tool to the field environment, or it can be released to the field environment simultaneously with the release of the corresponding version of the inspection tool, so as to use the inspection tool to detect or troubleshoot field faults. In one implementation, when a fault occurs in the field environment, the inspection tool can execute corresponding commands as needed to check the entire link of the field environment and return specific correct information or error information (error information can be understood as the fault data or target detection data mentioned above). Here, the field environment can be understood as the resource services provided by the customer's private cloud in a local area network environment, for example, it can be a business service system in an enterprise.

[0037] Optionally, when R&D personnel are on-site, they can identify the specific fault and provide a solution based on the error information. Alternatively, when R&D personnel are not on-site, on-site testing personnel can relay the error information to the R&D personnel, who can then identify the specific fault and provide a solution. For example, testing personnel can use this inspection tool to relay the error information to the terminal used by the R&D personnel (e.g., [missing information]). Figure 1b (On the R&D side), so that R&D personnel can determine the solution through the error information displayed on the terminal and send the solution to the inspection tool through the terminal.

[0038] The implementation details of the technical solutions in the embodiments of this application are described in detail below:

[0039] Based on the fault detection scheme provided above for a private cloud environment, this application embodiment provides a fault detection method for a private cloud environment, which can be executed by the aforementioned fault detection device. Please refer to... Figure 2 The fault detection method in this private cloud environment includes, but is not limited to, the following steps:

[0040] S201: Obtain the input parameters corresponding to the fault detection task in the private cloud environment, determine one or more detection objects for the fault detection task based on the input parameters, and obtain the detection data of each detection object.

[0041] In one implementation, the fault detection device can acquire the input parameters corresponding to the fault detection task in a private cloud environment. After acquiring the input parameters, it performs a correctness check on the input parameters to ensure the normal execution of the fault detection task. Specifically, the correctness check on the input parameters can be based on preset check rules. These preset check rules can include standard parameters that the fault detection device can accept. These standard parameters can include one or more, and the specific implementation of the correctness check can be to match the input parameters with these standard parameters. If the input parameter matches the standard parameter, the corresponding detection result is determined to be that the input parameter has passed the correctness check. Conversely, if the input parameter does not match the standard parameter, the corresponding detection result is determined to be that the input parameter has failed the correctness check. Optionally, if the detection result is that the input parameter has failed the correctness check, a re-entry parameter instruction can be returned to instruct the testing personnel to enter the correct parameters until the input parameters pass the correctness check, at which point subsequent testing operations can proceed.

[0042] In one implementation, the fault detection device can call a third-party library or a self-developed library to obtain the input parameters corresponding to the fault detection task. Optionally, the third-party library and the self-developed library pre-store various parameters, and the testing personnel can look up the required parameters in these libraries to pass to the fault detection device. The specific parameters that the fault detection device can receive are provided in the documentation released with the corresponding version of the fault detection device.

[0043] In one implementation, after receiving input parameters, the fault detection device can perform different processing logic based on the different input parameters to detect different objects. For example, if the inspector wants to check the status of a pod and whether the backend service is available, they can pass the parameter "check pod," and the fault detection device can then enter the "check pod" processing logic. Similarly, if the inspector wants to check whether the registration function of various backend services is available, they can pass the parameter "test register," and the fault detection device can then enter the "test register" processing logic. Likewise, if the inspector wants to check whether the login function of various backend services is available, they can pass the parameter "test login," and the fault detection device can then enter the "test login" processing logic. This application mainly describes these three processing logics.

[0044] As described above, input parameters can correspond to specific detection objects. For example, if the input parameter is "check pod," the corresponding detection object can include the pod itself. Within the pod, the specific detection objects can include one or more of the following: pod status, pod configuration rendering, and backend service interfaces. The specific detection object can be determined based on the needs of the testing personnel. For instance, the testing personnel can input the corresponding parameters on the relevant interface of the fault detection device. If the testing personnel have no specific requirements, the default detection objects under the pod include the three mentioned above. Similarly, if the input parameter is "testlogin," the corresponding detection object is the login function; and if the input parameter is "test register," the corresponding detection object is the registration function. Other input parameters and corresponding detection objects can also be included, but these are not listed in this application.

[0045] In one implementation, after the fault detection device determines the corresponding detection object based on the input parameters, it can further acquire the detection data corresponding to the detection object to use for fault diagnosis. The acquisition of detection data corresponding to each detection object is described in detail below.

[0046] (1) When the detection target is the pod status, the corresponding detection data can include the status data of all pods in the target cluster. This allows for subsequent determination of whether the pod status is normal based on the status data. For example, the target cluster can refer to a Kubernetes cluster (or simply a k8s cluster). The status data can include the pod name, pod running status, replica activity status, namespace, number of replicas, etc. In the specific implementation, after determining the current processing logic as "check pod" based on the input parameters, the status data of all pods in the Kubernetes cluster can be obtained by calling the interactive commands or RESTful interfaces of Kubernetes (or simply k8s). Optionally, after obtaining the status data of all pods in the Kubernetes cluster, this status data can be aggregated so that it can be displayed in tabular form, improving data cleanliness and thus enhancing the display effect.

[0047] (2) When the detection target is pod configuration rendering, the corresponding detection data can include the file content of the configuration files corresponding to all pods in the target cluster, so that the pod configuration rendering can be determined according to the file content. In the specific implementation, the file content of the configuration files corresponding to all pods in the Kubernetes cluster can be read. For example, after determining that the current processing logic is to check the pod based on the input parameters, the file content of the configuration file in the specified directory of the specified pod can be obtained by calling the interactive command of k8s.

[0048] Optionally, data related to the pods included in the target cluster (such as a Kubernetes cluster) can be pre-stored in the configuration file corresponding to the fault detection device. For ease of description later, this configuration file can be referred to as the target configuration file. The data stored in this target configuration file can include the pod names of the pods included in the Kubernetes cluster, allowing the identification of which pods are included in the Kubernetes cluster. After identifying all the pods in the Kubernetes cluster, the required data can be read from the configuration file corresponding to each pod, such as the file content and pod status data (e.g., pod running status, replica activity status, etc.). Optionally, the target configuration file can also pre-store data related to various backend services involved in the private cloud scenario, backend services with registration functions, backend services with login functions, etc., so that the required data can be queried in the target configuration file, as will be discussed later.

[0049] (3) When the detection object is a backend service interface, the detection data corresponding to the backend service interface may include the response data sent by the backend service interface, so that the availability of the backend service corresponding to the backend service interface can be determined based on the response data. Here, the backend service interface can be understood as the service interface of the backend service. The backend service interface may include one or more, that is, it can be used to troubleshoot all backend services in the current private cloud scenario, or it can be used to troubleshoot some backend services. This application does not make specific limitations.

[0050] Optionally, after determining that the current processing logic is to check the pod based on the input parameters, all backend services in the target configuration file can be traversed to obtain the request address and request parameters of the backend service interfaces. Once the request address and parameters are obtained, a data request can be sent to the backend service interface based on these parameters; this data request can be referred to as the first data request. For example, the fault detection device can call its HTTP module to send an HTTP request to the backend service; this HTTP request is the first data request. After receiving the first data request, the backend service interface can respond to it and obtain the corresponding response data. Then, the backend service interface can send this response data to the fault detection device so that the fault detection device receives the response data. The response data may include the return code and return parameters of the backend service interface.

[0051] Optionally, after the fault detection device obtains the response data (such as return codes and return parameters) from each backend service interface, it can aggregate the response data to display it in a table format, improving data clarity. Alternatively, the request paths and parameters of the backend modules involved in the private cloud can be pre-stored in a designated directory via configuration files, so that when the request paths and parameters are needed, they can be directly retrieved from the configuration files.

[0052] (4) When the detection object is the registration function, the detection data corresponding to the registration function can include the registration indication data returned by the registration interface. In the specific implementation, after determining that the current processing logic is the testregister processing logic based on the input parameters, the registration parameters used for registration can be obtained, and the backend service with the registration function can be queried in the target configuration file. The detection personnel can input the registration parameters on the relevant interface of the fault detection device. For example, the registration parameters can include the registration username, password, confirmation password, phone number, etc., or other registration parameters, which are not specifically limited in this application. Optionally, after obtaining the registration parameters, the fault detection device can also perform a reasonableness check on the registration parameters to ensure the normal progress of subsequent steps. For example, it can check whether the password and confirmation password are consistent, whether the password format is correct, whether the registration username format is correct, etc. If the registration parameter check fails, an error message can be thrown and a prompt message can be displayed to the detection personnel. For example, the error message and prompt message can be displayed on the relevant interface of the fault detection interface so that the detection personnel can input the correct registration parameters based on the prompt message. If the registration parameter check is successful, subsequent operations can be performed.

[0053] Furthermore, the fault detection device can send a data request to the registration interface corresponding to the backend service based on the registration parameters. For example, the registration parameters can be concatenated before sending the data request to the registration interface. The registration interface can include one or more interfaces, and this data request can be referred to as a second data request. The parameter concatenation can be processed according to the requirements of the second data request, and is not limited in this application. For instance, the fault detection device can call its HTTP module to send an HTTP request to the registration interface of the backend service; this HTTP request is the second data request. After receiving the second data request, the registration interface can respond to it to obtain the corresponding registration indication data and send this data to the fault detection device. The fault detection device can then receive the registration indication data sent by the registration interface to perform subsequent detection steps.

[0054] (5) When the detection object is the registration function, the detection data corresponding to its login function can include the login response data sent by the login interface. In specific implementation, after determining that the current processing logic is the testlogin processing logic based on the input parameters, the identity information used for login can be obtained. This identity information can include the login username and login password. The detection personnel can input this identity information on the relevant interface of the fault detection device. Optionally, if the fault detection device detects that the detection personnel have only entered the login username, the fault detection device can provide an interactive command for the detection personnel to enter the login password; similarly, if the fault detection device detects that the detection personnel have only entered the login password, the fault detection device can provide an interactive command for the detection personnel to enter the login username.

[0055] Optionally, after the fault detection equipment obtains the login username and password entered by the testing personnel, it can also encrypt the login password to enhance information security. For example, a public key can be used to encrypt the entered login password.

[0056] After obtaining the identity information used for login, the system can query backend services with login functionality from the target configuration file to call a data request to send the identity information to the corresponding login interface of the backend service, thus enabling user login. For example, the identity information can be concatenated before sending a data request to the corresponding login interface of the backend service based on the concatenated identity information. The backend services with login functionality can include one or more, and the corresponding login interfaces can also include one or more; this data request can be referred to as a third data request; the information concatenation can be processed according to the information requirements in the third data request, and is not limited in this application. For example, the fault detection device can call its HTTP module to send an HTTP request to the login interface of the backend service; this HTTP request is the third data request. After receiving the third data request, the login interface can respond to it to obtain the corresponding login response data and send it to the fault detection device. The fault detection device can then receive the login response data sent by the login interface to implement subsequent detection steps.

[0057] S202: Determine whether target fault data exists in the detection data of each detection object.

[0058] S203: If target fault data exists in the detection data of any of the detection objects, then obtain the target detection data associated with the target fault data from the detection data and display the target detection data on the fault detection interface.

[0059] In steps S202 and S203, after acquiring the detection data of each object to be tested, fault diagnosis can be performed based on this data. For example, it can be detected whether target fault data exists in the detection data of each object. This target fault data can refer to abnormal data, i.e., data that would not appear under normal circumstances. If target fault data can be detected in the detection data of any of the objects, it can be determined that any object has a fault. To enable subsequent inspectors to locate the specific fault problem and determine a suitable solution based on this target fault data, target detection data associated with the target fault data can be obtained from the detection data and displayed on the fault detection interface. The target detection data may include the target fault data and information about its specific location.

[0060] In one implementation, if target fault data exists in the detection data of different detection objects, the target fault data and the corresponding target detection data can be different. The following is a specific explanation for different detection objects.

[0061] (1) When the detection object is the pod status, as described above, the detection data for this object can include the status data of all pods in the Kubernetes cluster. Therefore, it can be determined whether there is any abnormal status data in the status data of each pod that indicates an abnormal running status. If abnormal status data exists, it can be determined that target fault data has been detected from the pod status detection data. This target fault data can refer to the aforementioned abnormal status data. For example, if the pod's running status is displayed as "error," or the replica activity status is displayed as "error," it can be determined that abnormal status data exists.

[0062] After identifying the target fault data, associated target detection data can be obtained and displayed on the fault detection interface. This target detection data can include abnormal status data and information about the pod containing the abnormal status data. This information indicates which specific pod is experiencing a fault; for example, the pod information could include one or more of the following: pod name, path to the pod's configuration file, etc. For instance, if abnormal status data exists in the status data of a pod, this abnormal status data and the pod name can be used as target detection data. This allows the system to display the specific status of the pod, enabling inspectors to clearly understand the location of the fault.

[0063] (2) When the detection target is pod configuration rendering, as described above, the detection data can include the file content of the configuration files corresponding to all pods in the Kubernetes cluster. This allows us to determine whether any abnormal strings exist in the file content of each configuration file. If a preset abnormal string exists, it can be determined that target fault data has been detected from the pod configuration rendering detection data. This target fault data can refer to the aforementioned abnormal string. For example, abnormal strings can be filtered from the configuration file using Linux pipe operations. For instance, abnormal strings can include None, undefined, {}, etc. If abnormal strings can be filtered out from the configuration file, it indicates that the pod configuration rendering is abnormal.

[0064] After identifying the target fault data, related target detection data can be further obtained and displayed on the fault detection interface. This target detection data can include an exception string and information about the pod containing the exception string. This information indicates which specific pod's configuration rendering failed. For example, the pod's information could include one or more of the following: pod name, the node where the pod resides, and the path to the pod's configuration file. For instance, if an exception string exists in the configuration rendering of a pod, the location of the exception string (i.e., the specific location where the error occurred), along with the pod name, the node where the pod resides, and the path to the configuration file within the pod, can be displayed as target detection data on the fault detection interface for troubleshooting personnel.

[0065] (3) When the detection object is a backend service interface, as described above, the detection data of the detection object can include the response data sent by the backend service interface. If the response data contains a target return code, it can be determined that target fault data has been detected from the detection data of the backend service interface. This target fault data can refer to the aforementioned target return code. It should be noted that, generally, when the return code of an interface is 200, it indicates that the interface status is normal; if the return code is not 200, it indicates that the interface status is abnormal. Therefore, the target return code in this application can include return codes other than 200.

[0066] After identifying the target fault data, associated target detection data can be obtained and displayed on the fault detection interface. This target detection data may include the target return code and related information about the backend service involved. This information can indicate which specific backend service's parent service interface has failed. For example, the backend service's information may include one or more of the following: the backend service's module name, the backend service's address, etc. For instance, the target return code and the module name of the backend service involved can be displayed on the fault detection interface.

[0067] (4) When the detection target is the login function, as described above, the detection data of the detection target may include the registration indication data returned by the registration interface. If the registration indication information indicates that registration has failed, such as if the registration indication information may include a return code other than 200, then it can be determined that target fault data has been detected from the detection data of the registration function. The target fault data can refer to the aforementioned registration indication information.

[0068] After identifying the target fault data, associated target detection data can be obtained and displayed on the fault detection interface. This target detection data may include registration indication data and relevant information about the backend service corresponding to the registration interface. This information can indicate which specific backend service's registration interface has failed. For example, the backend service's information may include one or more of the following: the backend service's module name, the backend service's address, etc. For instance, the backend service address corresponding to the registration interface and the registration indication data can be displayed as target detection data on the fault detection interface.

[0069] (5) When the detection target is the login function, as described above, the detection data of the detection target can include the login response data sent by the login interface. If the login response data contains target response information, it can be determined that target fault data has been detected from the detection data of the login function. Here, the target fault data can refer to the target response information mentioned above. Similar to the backend service interface and registration interface mentioned above, the target response information can include a non-200 return code.

[0070] After identifying the target fault data, associated target detection data can be obtained and displayed on the fault detection interface. This target detection data can include target response information and relevant information about the backend service corresponding to the login interface. This information can indicate which specific backend service's login interface is experiencing a fault. For example, the backend service's information could include one or more of the following: the backend service's module name, the backend service's address, etc. For instance, the backend service address corresponding to the login interface and the target response information can be displayed as target detection data on the fault detection interface.

[0071] It should be noted that when the processing logic, determined based on input parameters, includes multiple types of processing logic—for example, the processing logic includes pod checking, test register, and test login—these multiple processing logics can be processed in parallel or sequentially. This application does not impose any restrictions on this. In the case of sequential processing, the processing order of the various processing logics is not specifically limited. Similarly, the multiple detection objects corresponding to the pod checking logic (such as pod status, pod configuration rendering, and backend service interfaces) can be processed in parallel or sequentially. In the case of sequential processing, the corresponding processing order is also not specifically limited.

[0072] In this embodiment, the fault detection device can acquire input parameters corresponding to the fault detection task, determine one or more detection objects for the fault detection task based on the input parameters, and acquire detection data for each detection object. After acquiring the detection data of each detection object, it can further determine whether there is target fault data in the detection data of each detection object. If there is target fault data in the detection data of any detection object, the target detection data associated with the target fault data can be obtained from the detection data, and the target detection data can be displayed on the fault detection interface. This can realize automated fault troubleshooting in private scenarios, allow on-site inspection personnel to quickly locate on-site faults, reduce the workload of the person in charge of the fault, solve tedious and error-prone manual operations, and improve the efficiency of fault troubleshooting and fault detection.

[0073] To better understand the fault detection method provided in the embodiments of this application, the following is combined with... Figure 3a , Figure 3b as well as Figure 3c The flowcharts shown below will be further explained. These three diagrams mainly describe the interactions between the executing entities involved in performing the fault detection task, such as... Figure 3a , Figure 3b as well as Figure 3cAs shown, the execution entity may include inspection tools (which can be understood as the fault detection equipment mentioned above), Kubernetes clusters, and backend services. The entry point may refer to the relevant interface of the inspection tool. For example, it may include an input interface for inspectors to input parameters, or a fault detection interface that displays the final target detection data, and so on.

[0074] Optionally, after receiving the input parameters, the inspection tool can perform different logical judgments based on the different input parameters. For example, if the inspector wants to check the status of a pod and whether the backend service is available, they can pass the parameter "checkpod," and the inspection tool can then enter the "check pod" processing logic. Similarly, if the inspector wants to check whether the registration function of various backend services is available, they can pass the parameter "test register," and the inspection tool can then enter the "test register" processing logic. Likewise, if the inspector wants to check whether the login function of various backend services is available, they can pass the parameter "test login," and the inspection tool can then enter the "test login" processing logic. If the inspector needs to check various inspection objects, they can enter the corresponding input parameters for each inspection object. Figure 3a The process shown mainly describes the processing logic of the check pod. Figure 3b The flowchart shown mainly describes the processing logic of the test register. Figure 3b The flowchart shown mainly describes the processing logic for test login.

[0075] like Figure 3a The interaction process of the processing logic of the check pod shown can be described as follows:

[0076] a1. This inspection tool can be executed as needed to perform fault detection or troubleshooting in a private cloud environment. First, the required parameters can be passed to the inspection tool to execute the corresponding inspection command. The specific parameters that the inspection tool can accept are provided in the documentation accompanying the release of the corresponding version of the inspection tool. If the inspection tool determines the processing logic of the pod being inspected based on the input parameters, it can proceed with subsequent steps.

[0077] a2. After receiving the input parameters, the inspection tool can perform an input parameter check to verify their correctness. If the input parameters are incorrect, it can throw a specific error and exit, allowing the inspector to re-enter the correct input parameters. Specific errors can be displayed on the relevant interface of the inspection tool, such as the aforementioned fault detection interface or other interfaces. If the input parameters are correct, subsequent steps can be performed.

[0078] a3. First, the inspection tool can invoke system commands to perform a preliminary check, namely, checking the pod status. Specifically, it can check the running status of core pods, replica activity status, namespaces, etc., in the private cloud environment. Specifically, it can retrieve the necessary data from the Kubernetes cluster, returning the information contained in the pods within the Kubernetes cluster to the inspection tool. The tool can then analyze this information to determine if any pod status anomalies exist. When a pod is unhealthy, i.e., its related status is abnormal, it can throw an error and return a response. For example, it can display the specific status of which pod and provide a prompt. The error information (which can be understood as the target detection data mentioned above) can be displayed and prompted on the inspection tool's fault detection interface.

[0079] a4. Next, the inspection tool can call system commands to check the configuration rendering of pods and retrieve the configuration renderings contained in the pod from the Kubernetes cluster. The inspection tool can then detect the configuration rendering to determine if there are any abnormal pod configurations. If a pod's configuration rendering returns an exception string such as NONE or undefined, an error can be thrown and returned. For example, the pod name and the specific file within the pod where the configuration rendering is problematic can be displayed in a user-friendly way, such as displaying the error information on the fault detection interface.

[0080] A5. Next, the inspection tool can call the interfaces of the backend service module to check the backend service interfaces. Specifically, it can request all relevant backend service interfaces through code and obtain their return codes. If the return code is 200, it indicates that the interface is normal; otherwise, it indicates that the interface is abnormal. In case of an exception, an error can be thrown and returned. For example, the backend service name, backend service address, return code, etc., can be displayed in a user-friendly table format, such as displaying error information on the fault detection interface. The code-based approach can be understood as obtaining the necessary data by sending HTTP requests.

[0081] like Figure 3b The interaction process of the test register processing logic is shown below, and can be described in detail as follows:

[0082] b1. The inspection tool determines the current registration inspection logic based on the input parameters, that is, it starts the registration inspection process. For example, the registration process can be inspected through code.

[0083] b2. Inspectors can pass the parameters required by the registered user to the inspection tool through the console (which can be understood as the fault diagnosis interface of the inspection tool). The inspection tool can verify the validity of the parameters. For example, if the parameters required by the registered user include a password and a confirmation password, the tool can verify whether the password and the confirmation password match. If the parameter verification fails, an error can be thrown and a user-friendly prompt can be provided, for example, displayed and prompted on the relevant interface of the fault detection equipment.

[0084] b3. Concatenate the registration parameters entered by the testing personnel and send an HTTP request to the registration interface of the backend service. This HTTP request can be understood as the second data request mentioned above.

[0085] b4. If the registration interface returns a registration success message (e.g., a return code of 200), the registration is successful; otherwise, if the return code is not 200, the registration has failed. Furthermore, the registration failure information can be displayed on the console for testing personnel to refer to, i.e., the error message can be displayed on the fault detection interface.

[0086] like Figure 3c The interaction process of the test login processing logic is shown below, and can be described in detail as follows:

[0087] c1. The inspection tool determines the login processing logic based on the input parameters, that is, it starts to inspect the login process. For example, the login process can be inspected through code.

[0088] c2. In the login logic, the tester can also pass in the login username and login password. If the tester only enters the login username, an interactive command is provided for the tester to enter the login password; similarly, if only the login password is entered, an interactive command is provided for the tester to enter the login username.

[0089] c3. Send the login username and encrypted login password to the login interface of the backend service via an HTTP request. This HTTP request can be understood as the third data request mentioned above.

[0090] c4. Make corresponding judgments based on the response from the backend service. If the response return code is 200, it means the login was successful; otherwise, it means the login failed. Print the specific error information to the front end for the testing personnel to refer to, that is, display the error information on the fault detection interface.

[0091] Please see Figure 4 , Figure 4 This is a schematic diagram of a fault detection device in a private cloud environment provided in an embodiment of this application. The fault detection device described in this embodiment includes:

[0092] The first acquisition module 401 is used to acquire input parameters corresponding to the fault detection task in the private cloud environment, determine one or more detection objects for the fault detection task based on the input parameters, and acquire detection data of each detection object.

[0093] The determining module 402 is used to determine whether target fault data exists in the detection data of each detection object;

[0094] The second acquisition module 403 is used to acquire target detection data associated with the target fault data from the detection data if the detection data of any of the detection objects contains target fault data, and to display the target detection data on the fault detection interface.

[0095] In one implementation, the one or more detection objects include pod status; the first acquisition module 401 is specifically used for:

[0096] Obtain the status data of all pods in the target cluster;

[0097] The determining module 402 is further configured to:

[0098] Determine if there is any abnormal status data in the status data of each pod that indicates an abnormal status.

[0099] If the abnormal state data exists, it is determined that the target fault data exists in the detection data of the pod state.

[0100] In one implementation, the one or more detection objects include pod configuration rendering; the first acquisition module 401 is specifically used for:

[0101] Read the contents of the configuration files corresponding to all pods in the target cluster;

[0102] The determining module 402 is further configured to:

[0103] Determine if any abnormal strings exist in the contents of each configuration file;

[0104] If the abnormal string exists, it is determined that the target fault data exists in the detection data rendered by the pod configuration.

[0105] In one implementation, the one or more detection objects include a backend service interface; the first acquisition module 401 is specifically used for:

[0106] Obtain the request address and request parameters of the backend service interface from the target configuration file;

[0107] A first data request is sent to the backend service interface according to the request address and the request parameters;

[0108] Receive response data sent by the backend service interface;

[0109] The determining module 402 is further configured to:

[0110] If the response data contains a target return code, then it is determined that the detection data of the backend service interface contains target fault data.

[0111] In one implementation, the one or more detection objects include a registration function; the first acquisition module 401 is specifically used for:

[0112] Obtain the registration parameters used for registration, and query the backend service with the registration function from the target configuration file;

[0113] A second data request is sent to the registration interface corresponding to the backend service according to the registration parameters;

[0114] Receive registration instruction data sent by the registration interface;

[0115] The determining module 402 is further configured to:

[0116] If the registration indication information indicates that registration has failed, then it is determined that there is target fault data in the detection data of the registration function.

[0117] In one implementation, the one or more detection objects include a login function; the first acquisition module 401 is specifically used for:

[0118] Obtain the identity information used for login, and query the backend service with the login function from the target configuration file;

[0119] A third data request is sent to the login interface corresponding to the backend service based on the identity information;

[0120] Receive login response data sent by the login interface;

[0121] The determining module 402 is further configured to:

[0122] If the login response data contains target response information, then it is determined that the login function's detection data contains target fault data.

[0123] In one implementation, the first acquisition module 401 is specifically used for:

[0124] Obtain the input parameters corresponding to the fault detection task, and perform correctness detection on the input parameters based on preset inspection rules;

[0125] If the detection result indicates that the input parameter has failed the correctness check, a re-entry parameter instruction will be returned until the input parameter passes the correctness check.

[0126] It is understood that the module division in this embodiment is illustrative and merely a logical functional division; in actual implementation, there may be other division methods. The functional modules in this embodiment can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated modules can be implemented in hardware or as software functional modules.

[0127] Please see Figure 5 , Figure 5 This is a schematic diagram of a fault detection device provided in an embodiment of this application. The fault detection device includes a processor 501 and a memory 502. Optionally, the fault detection device may also include a network interface 503. The processor 501, memory 502, and network interface 503 can exchange data.

[0128] The processor 501 mentioned above can be a Central Processing Unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0129] The aforementioned memory 502 may include read-only memory and random access memory, and provides program instructions and data to the processor 501. A portion of the memory 502 may also include non-volatile random access memory. The processor 501 executes the program instructions by calling them:

[0130] Obtain the input parameters corresponding to the fault detection task in the private cloud environment, determine one or more detection objects for the fault detection task based on the input parameters, and obtain the detection data of each detection object;

[0131] Determine whether target fault data exists in the detection data of each of the detection objects;

[0132] If target fault data exists in the detection data of any of the detection objects, then target detection data associated with the target fault data is obtained from the detection data, and the target detection data is displayed on the fault detection interface.

[0133] In one implementation, the processor 501 is specifically used for:

[0134] In one implementation, the one or more detection objects include pod status; the processor 501 is specifically used for:

[0135] Obtain the status data of all pods in the target cluster;

[0136] Determine if there is any abnormal status data in the status data of each pod that indicates an abnormal status.

[0137] If the abnormal state data exists, it is determined that the target fault data exists in the detection data of the pod state.

[0138] In one implementation, the one or more detection objects include pod configuration rendering; the processor 501 is specifically used for:

[0139] Read the contents of the configuration files corresponding to all pods in the target cluster;

[0140] Determine if any abnormal strings exist in the contents of each configuration file;

[0141] If the abnormal string exists, it is determined that the target fault data exists in the detection data rendered by the pod configuration.

[0142] In one implementation, the one or more detection objects include a backend service interface; the processor 501 is specifically used for:

[0143] Obtain the request address and request parameters of the backend service interface from the target configuration file;

[0144] A first data request is sent to the backend service interface according to the request address and the request parameters;

[0145] Receive response data sent by the backend service interface;

[0146] If the response data contains a target return code, then it is determined that the detection data of the backend service interface contains target fault data.

[0147] In one implementation, the one or more detection objects include a registration function; the processor 501 is specifically used for:

[0148] Obtain the registration parameters used for registration, and query the backend service with the registration function from the target configuration file;

[0149] A second data request is sent to the registration interface corresponding to the backend service according to the registration parameters;

[0150] Receive registration instruction data sent by the registration interface;

[0151] If the registration indication information indicates that registration has failed, then it is determined that there is target fault data in the detection data of the registration function.

[0152] In one implementation, the one or more detection objects include a login function; the processor 501 is specifically used for:

[0153] Obtain the identity information used for login, and query the backend service with the login function from the target configuration file;

[0154] A third data request is sent to the login interface corresponding to the backend service based on the identity information;

[0155] Receive login response data sent by the login interface;

[0156] If the login response data contains target response information, then it is determined that the login function's detection data contains target fault data.

[0157] In one implementation, the processor 501 is specifically used for:

[0158] Obtain the input parameters corresponding to the fault detection task, and perform correctness detection on the input parameters based on preset inspection rules;

[0159] If the detection result indicates that the input parameter has failed the correctness check, a re-entry parameter instruction will be returned until the input parameter passes the correctness check.

[0160] This application also provides a computer storage medium storing program instructions, which, when executed, may include, for example... Figure 2 Some or all of the steps of the fault detection method in the corresponding embodiment.

[0161] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0162] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, which may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0163] This application also provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. The processor of the fault detection device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the fault detection device to perform the steps described in the embodiments of the above methods.

[0164] The above provides a detailed description of a fault detection method, apparatus, device, and medium in a private cloud scenario provided by the embodiments of this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A fault detection method in a private cloud environment, characterized in that, include: The system obtains input parameters corresponding to the fault detection task in a private cloud environment, determines one or more detection objects for the fault detection task based on the input parameters, and obtains detection data for each detection object; the detection objects include one or more of pod status, pod configuration rendering, backend service interface, login function, and registration function. Determine whether target fault data exists in the detection data of each of the detection objects; If target fault data exists in the detection data of any of the detection objects, then target detection data associated with the target fault data is obtained from the detection data, and the target detection data is displayed on the fault detection interface; wherein, the target detection data corresponding to the pod status includes abnormal status data and information about the pod where the abnormal status data is located; the target detection data corresponding to the pod configuration rendering includes an abnormal string and information about the pod where the abnormal string is located; the target detection data corresponding to the backend service interface includes the target return code and information about the backend service involved in the target return code; the target detection data corresponding to the login function includes the target response information and information about the backend service corresponding to the login interface; and the target detection data corresponding to the registration function includes registration indication data indicating registration failure and information about the backend service corresponding to the registration interface.

2. The method according to claim 1, characterized in that, The one or more detection objects include pod status; The acquisition of detection data for each detection object includes: Obtain the status data of all pods in the target cluster; This also includes: Determine if there is any abnormal status data in the status data of each pod that indicates an abnormal status. If the abnormal state data exists, it is determined that the target fault data exists in the detection data of the pod state.

3. The method according to claim 1, characterized in that, The one or more detection objects include pod configuration rendering; obtaining the detection data of each detection object includes: Read the contents of the configuration files corresponding to all pods in the target cluster; This also includes: Determine if any abnormal strings exist in the contents of each configuration file; If the abnormal string exists, it is determined that the target fault data exists in the detection data rendered by the pod configuration.

4. The method according to claim 1, characterized in that, The one or more detection objects include a backend service interface; obtaining the detection data of each detection object includes: Obtain the request address and request parameters of the backend service interface from the target configuration file; A first data request is sent to the backend service interface according to the request address and the request parameters; Receive response data sent by the backend service interface; This also includes: If the response data contains a target return code, then it is determined that the detection data of the backend service interface contains target fault data.

5. The method according to claim 1, characterized in that, The one or more detection objects include a registration function; the acquisition of detection data for each detection object includes: Obtain the registration parameters used for registration, and query the backend service with the registration function from the target configuration file; A second data request is sent to the registration interface corresponding to the backend service according to the registration parameters; Receive registration instruction data sent by the registration interface; This also includes: If the registration indication information indicates that registration has failed, then it is determined that there is target fault data in the detection data of the registration function.

6. The method according to claim 1, characterized in that, The one or more detection objects include a login function; the acquisition of detection data for each detection object includes: Obtain the identity information used for login, and query the backend service with the login function from the target configuration file; A third data request is sent to the login interface corresponding to the backend service based on the identity information; Receive login response data sent by the login interface; This also includes: If the login response data contains target response information, then it is determined that the login function's detection data contains target fault data.

7. The method according to any one of claims 1-6, characterized in that, The input parameters for obtaining the fault detection task include: Obtain the input parameters corresponding to the fault detection task, and perform correctness detection on the input parameters based on preset inspection rules; If the detection result indicates that the input parameter has failed the correctness check, a re-entry parameter instruction will be returned until the input parameter passes the correctness check.

8. A fault detection device in a private cloud environment, characterized in that, include: The first acquisition module is used to acquire input parameters corresponding to the fault detection task in the private cloud environment, determine one or more detection objects for the fault detection task based on the input parameters, and acquire detection data for each detection object; the detection objects include one or more of pod status, pod configuration rendering, backend service interface, login function and registration function; The determination module is used to determine whether target fault data exists in the detection data of each detection object; The second acquisition module is used to acquire target detection data associated with the target fault data from the detection data if the detection data of any of the detection objects contains target fault data, and to display the target detection data on the fault detection interface; wherein, the target detection data corresponding to the pod status includes abnormal status data and information about the pod where the abnormal status data is located, the target detection data corresponding to the pod configuration rendering includes an abnormal string and information about the pod where the abnormal string is located, the target detection data corresponding to the backend service interface includes the target return code and information about the backend service involved in the target return code, the target detection data corresponding to the login function includes the target response information and information about the backend service corresponding to the login interface, and the target detection data corresponding to the registration function includes registration indication data indicating registration failure and information about the backend service corresponding to the registration interface.

9. A fault detection device, characterized in that, The system includes a processor and a memory, wherein the memory is used to store a computer program, the computer program including program instructions, and the processor is configured to invoke the program instructions to perform the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, the computer program including program instructions that, when executed by a processor, cause the processor to perform the method as described in any one of claims 1-7.

11. A computer program product, characterized in that, The computer program product includes computer instructions that are executed by a processor to implement the method as described in any one of claims 1-7.

Images