Fault alarm methods, devices, computer equipment and storage media

Abstract

This invention relates to the field of computer technology and discloses a fault alarm method, apparatus, computer equipment, and storage medium, comprising: obtaining the identification information and startup dependency order of each service running on the master node in the current cycle; obtaining the service status of each service based on the identification information and startup dependency order; when the service status of a target service is determined to be abnormal, or when the service status of the target service is not obtained, obtaining the configuration file of the target service in the current cycle and the file content indicator value of the target service in the previous cycle corresponding to the current cycle based on the identification information of the target service, wherein the target service is any service; determining the fault type of the target service based on the configuration file of the target service in the current cycle and the file content indicator value of the target service in the previous cycle; generating an alarm notification based on the identification information and fault type of the target service and sending it to the client. This invention can improve the efficiency of fault diagnosis.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and more specifically to fault alarm methods, devices, computer equipment, and storage media. Background Technology

[0002] In the field of computer technology, service platforms often employ a dual-machine hot standby system. A dual-machine hot standby system consists of a primary node and a standby node. The configurations of the two nodes are identical. Under normal conditions, only one node acts as the primary node to provide services. When the primary node fails, the standby node can immediately start providing services in response to external data requests.

[0003] However, after a node fails, technicians need to perform complex query operations to troubleshoot the related problems, which is inefficient. Summary of the Invention

[0004] In view of this, the present invention provides a fault alarm method, apparatus, computer equipment, storage medium and program product to solve the problem of low efficiency in troubleshooting.

[0005] In a first aspect, the present invention provides a fault alarm method, the method comprising:

[0006] In the current cycle, obtain the identification information corresponding to each of the at least one services running on the master node, as well as the startup dependency order corresponding to each of the services;

[0007] Based on the identification information and startup dependency order corresponding to each service, obtain the service status corresponding to each service;

[0008] When it is determined that the service status corresponding to the target service is abnormal, or when the service status corresponding to the target service is not obtained, the configuration file of the target service in the current period and the file content index value of the target service in the previous period corresponding to the current period are obtained according to the identification information corresponding to the target service, wherein the target service is any one of at least one of the services.

[0009] The fault type of the target service is determined based on the configuration file of the target service in the current period and the file content indicator value of the target service in the previous period.

[0010] Based on the identification information and fault type of the target service, an alarm notification is generated and sent to the client.

[0011] The fault alarm method provided by this invention has the following advantages:

[0012] This solution periodically retrieves the identification information and startup dependency order of services running on the master node. Based on this, it obtains the service status. When a service status is determined to be abnormal or no service status is found, it further retrieves the service's configuration file for the current period and the file content metric values ​​for the service in the previous period based on the service's identification information, and determines the fault type. Finally, an alarm notification is generated based on the service identification information and fault type and sent to the client. This eliminates the need for technical personnel to actively query and analyze to understand which specific part of the system is experiencing a fault and its specific cause (i.e., the fault type). This significantly improves troubleshooting efficiency, allowing technical personnel to resolve related faults promptly and minimizing the impact on the master node's service operations.

[0013] In one optional implementation, obtaining the service status corresponding to each service based on the identification information and startup dependency order corresponding to each service includes:

[0014] The order in which the service status is obtained for each service is determined based on the startup dependency order corresponding to each service.

[0015] Based on the order in which the service status of each service is obtained, the identification information corresponding to each service is traversed.

[0016] For each service's identifier information traversed, the service status corresponding to the traversed service is obtained based on the identifier information of the traversed service.

[0017] After traversing through the identification information corresponding to all services in at least one of the services, the operation of obtaining the service status corresponding to each service in the current cycle is completed.

[0018] Specifically, obtaining service status according to the startup dependency order ensures that all services that depend on a particular service have been checked before it is checked. This helps identify problems caused by failures in dependent services, thus allowing for a more accurate assessment of service status.

[0019] In one optional implementation, determining the fault type of the target service based on the target service's configuration file in the current period and the target service's file content indicator value in the previous period includes:

[0020] Based on the pre-built target algorithm, the configuration file of the target service in the current period is processed to obtain the file content index value of the target service in the current period;

[0021] The fault type of the target service is determined based on the file content index values ​​corresponding to the target service in the previous period and the current period, respectively.

[0022] Specifically, related technologies typically involve iterating through all configuration parameters in a configuration file and checking for changes to each parameter to determine if a failure might be caused by configuration changes. However, since configuration files also contain other code besides parameters, changes to this code can also lead to failures. Therefore, this solution directly determines the failure type by comparing the file content metrics of the service in two adjacent periods. This ensures the accuracy of the failure type determination and improves efficiency.

[0023] In one optional implementation, determining the fault type of the target service based on the file content indicator values ​​corresponding to the target service in the previous period and the current period respectively includes:

[0024] Determine whether the file content indicator value of the target service in the previous period is consistent with the file content indicator value in the current period;

[0025] When it is determined that the file content indicator value of the target service in the previous period is inconsistent with the file content indicator value in the current period, the fault type of the target service is determined to be the first fault type, wherein the first fault type is used to indicate that the fault cause of the target service is that the configuration file of the target service has been modified;

[0026] or,

[0027] When it is determined that the file content indicator value of the target service in the previous period is consistent with the file content indicator value in the current period, the fault type of the target service is determined to be the second fault type, wherein the second fault type is used to indicate that the fault cause of the target service is not that the configuration file of the target service has been modified.

[0028] Specifically, if the file content metric values ​​of the target service are consistent across two adjacent periods, it indicates that the configuration file has not changed. This suggests that the failure of the target service was not due to a configuration file failure, but rather a failure of the master node, such as a hardware failure, or changes to the operating system or other configuration files. Conversely, if the file content metric values ​​of the target service are inconsistent across two adjacent periods, it indicates that the failure of the target service was caused by changes to its own configuration file.

[0029] In an optional implementation, when the services running in the master node include a data synchronization service, the method further includes:

[0030] The network communication link between the master node and the backup node corresponding to the master node is detected.

[0031] When a network communication link failure is detected, it is determined whether the master node has mounted the data synchronization service;

[0032] When it is determined that the master node has mounted the data synchronization service, obtain the target time for mounting the data synchronization service;

[0033] The target time is added as a target identifier to the target log corresponding to the data synchronization service, wherein the target identifier is used to instruct the master node to mount the data synchronization service during the network communication link failure.

[0034] Specifically, by periodically checking the network communication link between the primary and backup nodes, a response can be initiated immediately upon network failure, maintaining a certain level of service continuity. Furthermore, when a network failure occurs, it checks whether a data synchronization service is mounted and records the mounting time. This target time is added to the log as an identifier, providing a clear timeline for subsequent troubleshooting, facilitating analysis of the data status during the failure period, and thus enabling faster identification of the root cause of the problem.

[0035] In an optional implementation, after adding the target time as a target identifier to the target log corresponding to the data synchronization service, the method further includes:

[0036] When the network communication link is detected to have returned to normal and a network fault check instruction sent by the client is received, it is determined whether the target identifier is included in the target log;

[0037] When it is determined that the target log includes the target identifier, the target identifier is sent to the client so that the client can determine whether there is an inconsistency between the data of the primary node and the data of the backup node during the network communication link failure.

[0038] Specifically, by checking the target identifier in the target log, it can be clearly determined whether the master node has mounted the data synchronization service during the communication link failure. This allows the client to assess and repair data inconsistency issues based on the received target identifier, ensuring data synchronization between the master and backup nodes.

[0039] In an optional implementation, after determining that the target log includes the target identifier and sending the target identifier to the client, the method further includes:

[0040] Upon receiving the target data processing instruction sent by the client, the target identifier is deleted from the target log. The target data processing instruction is the instruction obtained by the client when it determines that there is an inconsistency between the data of the master node and the data of the backup node.

[0041] The target data processing instructions are parsed to obtain the operation type;

[0042] When the operation type is determined to be a deletion operation, the data generated by the data synchronization service during the mounting period is deleted;

[0043] or,

[0044] When the operation type is determined to be a retention operation, the data generated by the data synchronization service during the mounting process is retained.

[0045] Specifically, upon receiving the target data processing instruction, the master node can delete the target identifier from the target log. This allows for the direct addition of a new time when a network communication link failure is detected subsequently, preventing multiple identifiers from existing simultaneously and thus avoiding the inability to correctly identify data inconsistencies. Furthermore, deleting or retaining data based on the target data processing instructions sent by the client can eliminate data inconsistency issues.

[0046] Secondly, the present invention provides a fault alarm device, the device comprising:

[0047] The acquisition module is configured to, in the current cycle, acquire the identification information corresponding to each of the at least one services running on the master node, and the startup dependency order corresponding to each of the services; acquire the service status corresponding to each of the services based on the identification information and startup dependency order corresponding to each service; when it is determined that the service status corresponding to the target service is abnormal, or when the service status corresponding to the target service is not acquired, acquire the configuration file of the target service in the current cycle, and the file content indicator value of the target service in the previous cycle corresponding to the current cycle, based on the identification information corresponding to the target service, wherein the target service is any one of the at least one of the services;

[0048] The determination module is used to determine the fault type of the target service based on the configuration file of the target service in the current period and the file content indicator value of the target service in the previous period.

[0049] The generation module is used to generate an alarm notification based on the identification information and fault type of the target service, and send it to the client.

[0050] Thirdly, the present invention provides a computer device, comprising: a memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the computer instructions to perform the fault alarm method of the first aspect or any corresponding embodiment described above.

[0051] Fourthly, the present invention provides a computer-readable storage medium storing computer instructions for causing a computer to execute the fault alarm method of the first aspect or any corresponding embodiment thereof.

[0052] Fifthly, the present invention provides a computer program product, including computer instructions, which are used to cause a computer to execute the fault alarm method described in the first aspect or any corresponding embodiment thereof. Attached Figure Description

[0053] To more clearly illustrate the technical solutions in the specific embodiments or related technologies of the present invention, the drawings used in the description of the specific embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0054] Figure 1 This is a schematic diagram of the architecture of the target system according to an embodiment of the present invention;

[0055] Figure 2 This is a flowchart illustrating a fault alarm method according to an embodiment of the present invention;

[0056] Figure 3 This is a schematic diagram of the process for detecting network communication link failures according to an embodiment of the present invention;

[0057] Figure 4 This is a structural block diagram of a fault alarm device according to an embodiment of the present invention;

[0058] Figure 5 This is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. Detailed Implementation

[0059] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0060] This invention can be implemented by a target system, such as Figure 1 As shown, the target system may include multiple nodes and clients, among which there are primary nodes and backup nodes. The primary and backup nodes can be servers, and the clients can be computers, mobile phones, etc.

[0061] This invention provides a fault alarm method that is highly efficient by automatically alarming and generating fault types.

[0062] According to an embodiment of the present invention, a fault alarm method embodiment is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0063] This embodiment provides a fault alarm method that can be executed by the master node. Figure 2 This is a flowchart of a fault alarm method according to an embodiment of the present invention, such as... Figure 2 As shown, the process includes the following steps:

[0064] Step S201: In the current cycle, obtain the identification information of each service in at least one service running on the master node, as well as the startup dependency order corresponding to each service.

[0065] The service identification information can include the service name, number, etc. For example, services can include database services, in-memory data structure services, request processing services, etc. The startup dependency order for the database service could be 1, the startup dependency order for the in-memory data structure service could be 2, and the startup dependency order for the request processing service could be 3.

[0066] Specifically, once any node in the target system becomes the master node, it can start periodically calling the detection script. Based on the execution steps in the detection script, it first obtains the identification information and startup dependency order of the currently running services in order to check whether any services are malfunctioning.

[0067] Step S202: Obtain the service status corresponding to each service based on the identification information and startup dependency order corresponding to each service.

[0068] The service status can be either normal or abnormal.

[0069] Specifically, the master node can first determine the service status retrieval order for each service based on the startup dependency order. Then, based on the service status retrieval order, it iterates through the identification information for each service. Upon traversing the identification information of each service, it retrieves the service status corresponding to that service. In this way, after traversing the identification information for all services in at least one service, the operation of retrieving the service status for each service in the current cycle is completed.

[0070] In some optional implementations, obtaining the service status corresponding to the traversed services based on the identification information of the traversed services can specifically be as follows:

[0071] First, a pre-built retrieval command template is obtained. Then, based on the retrieval command template and the identification information of the traversed services, a retrieval command corresponding to the identification information of the traversed services is generated and executed. After execution, the service status can be obtained. For example, the retrieval command template could be "systemctl status + service identification information".

[0072] Step S203: When it is determined that the service status corresponding to the target service is abnormal, or the service status corresponding to the target service is not obtained, the configuration file of the target service in the current period and the file content indicator value of the target service in the previous period corresponding to the current period are obtained according to the identification information corresponding to the target service.

[0073] The target service can be any one of at least one services.

[0074] Specifically, for the target service, when the master node obtains the service status corresponding to the target service, it can first determine whether the service status is normal or abnormal. If it is normal, no action is required; if it is abnormal, the fault type can be further determined. Alternatively, if the return result after executing the command corresponding to the target service's identification information is a service status retrieval failure (i.e., the service status corresponding to the target service was not obtained), the fault type can also be further determined. Before determining the fault type, the master node can first obtain the configuration file corresponding to the target service and the file content indicator value of the target service in the previous period from itself based on the target service's identification information. For example, the configuration file for the database service could be "mariadb-server.conf", and the configuration file for the request processing service could be "httpd.conf".

[0075] Step S204: Determine the fault type of the target service based on the target service's configuration file in the current period and the target service's file content indicator value in the previous period.

[0076] The file content index value can be an MD5 checksum.

[0077] Specifically, the master node can determine the fault type of the target service by following these steps:

[0078] Step 1: Based on the pre-built target algorithm, process the configuration file of the target service in the current period to obtain the file content index value of the target service in the current period.

[0079] The target algorithm can be the MD5 algorithm.

[0080] Step 2: Determine the fault type of the target service based on the file content indicator values ​​corresponding to the target service in the previous cycle and the current cycle.

[0081] Specifically, it determines whether the file content metric values ​​of the target service in the previous period and the current period are consistent. When the master node determines that the file content metric values ​​of the target service in the previous period and the current period are inconsistent, the fault type of the target service can be determined as the first fault type, where the first fault type indicates that the fault of the target service is due to the modification of the target service's configuration file. Alternatively, when the master node determines that the file content metric values ​​of the target service in the previous period and the current period are consistent, the fault type of the target service is determined as the second fault type, where the second fault type indicates that the fault of the target service is not due to the modification of the target service's configuration file.

[0082] After calculating the file content metric value of the target service in the current period, the identification information of the target service and its corresponding file content metric value in the current period can be recorded for the purpose of determining the fault type in the next period.

[0083] In some optional implementations, once the master node determines that the file content metric values ​​of the target service in the previous period and the current period are consistent, it can also perform the following operations:

[0084] Determine if the failure type of the service preceding the target service in the startup dependency order is the first failure type. If so, the failure type of the target service can be determined as the first sub-failure type within the second failure type, where the first sub-failure type indicates that the failure of the target service is due to a modification of the configuration file of its dependent services. If not, the failure cause of the target service can be determined as the second sub-failure type within the second failure type, where the second sub-failure type indicates that the failure cause of the target service is an operating system failure or hardware failure on the master node.

[0085] This allows technicians to pinpoint the specific causes of the malfunctions, thus speeding up troubleshooting.

[0086] Step S205: Generate an alarm notification based on the identification information of the target service and the fault type, and send it to the client.

[0087] Specifically, after determining the fault type of the target service, the master node can generate an alarm notification corresponding to the target service based on the service's identification information and fault type, and send it to the client. Upon receiving the alarm notification, the client can display it directly, allowing technical personnel to understand the faulty service and its specific fault type, and then take steps to resolve the issue. This reduces the downtime of the target service.

[0088] In some alternative implementations, the master node can determine whether each service has failed and the type of failure for each failed service, and then generate alarm notifications and send them to the clients based on the identification information and failure type of each failed service. This can reduce the waste of network resources.

[0089] In some optional implementations, after determining whether each service has failed and the type of failure for each failed service, the master node can first count the number of failed services and obtain the corresponding level for each failed service (a higher level indicates a greater impact on the master node's operation). Then, based on the number of failed services and their corresponding levels, it can determine an alarm level and generate an alarm notification based on the alarm level, the identifier information of each failed service, and the fault type, sending it to the client. Additionally, if the master node determines that the alarm level is greater than a preset alarm level, it can shut down the network. In this way, the backup node cannot receive heartbeat signals from the master node and will become the master node, providing services externally.

[0090] The alarm level can be determined based on the number of faulty services and the corresponding level of each faulty service using the following expression:

[0091]

[0092] Where L is the alarm level, N is the number of fault services, k is a preset value greater than 0 and less than 1, and G... i The service level for the i-th fault.

[0093] In this way, when a serious fault occurs in the master node (the alarm level is greater than the preset alarm level), remedial measures can be taken automatically, and alarm notifications can be sent to the client in a timely manner so that technicians can resolve the fault and restore the normal operation of the master node.

[0094] The fault alarm method provided in this embodiment periodically obtains the identification information and startup dependency order of services running on the master node, and uses this information to obtain the service status. When a service status is determined to be abnormal or no service status is obtained, the method further obtains the service's configuration file for the current period and the file content indicator values ​​of the service in the previous period based on the service's identification information, and determines the fault type. Finally, an alarm notification is generated based on the service's identification information and the fault type and sent to the client. In this way, technicians can understand which specific part of the fault occurred and the specific cause (i.e., the fault type) without actively querying and analyzing. This results in high fault diagnosis efficiency, facilitates timely resolution of related faults by technicians, and reduces the impact on running services.

[0095] In some optional implementations, the detection script described above may further include a network communication link detection step. Thus, when the master node runs a service that includes a data synchronization service, the master node may also perform the following steps:

[0096] Step 1: Detect the network communication link between the master node and the corresponding backup node.

[0097] Step 2: When a network communication link failure is detected, determine whether the master node has mounted the data synchronization service.

[0098] The data synchronization service can be a Distributed Replicated Block Device (DRBD) service.

[0099] Step 3: Once it is determined that the master node has mounted the data synchronization service, obtain the target time for mounting the data synchronization service.

[0100] Step 4: Add the target time as the target identifier to the target log corresponding to the data synchronization service.

[0101] The target identifier is used to instruct the master node to mount a data synchronization service during network communication link failures.

[0102] Specifically, the master node can periodically check the network communication link between itself and the backup node. This can be done using the ping command, for example, "ping + backup node communication address -c100 -i0.001", which means pinging 100 times per second to obtain the results and determine if a network communication link failure has occurred. Alternatively, the grep command can be used to check for packet loss events; if packet loss occurs, a network communication link failure is considered detected.

[0103] When the primary node detects a network communication link failure, it can determine whether it has mounted a data synchronization service. If so, it can obtain the target time for mounting the data synchronization service and add it to the target field in the target log (e.g., / var / log / drbd_state.log). If not, no action is required. Similarly, the standby node can periodically check the network communication link between itself and the primary node. When a network communication link failure is detected, it can also execute steps one through four.

[0104] In this way, by periodically checking the network communication link between the primary and backup nodes, a response can be initiated immediately upon network failure, maintaining a certain level of service continuity. Furthermore, when a network failure occurs, it checks whether a data synchronization service (such as DRBD) is mounted and records the mounting time. This time is added as an identifier to the target log, providing a clear timeline for subsequent troubleshooting. This facilitates analysis of the data status during the failure period, thereby quickly pinpointing the root cause of the problem. Using this identifier, technicians can identify which node recorded more data, allowing them to choose which node's data to retain.

[0105] In some optional implementations, after adding the target time as a target identifier to the target log corresponding to the data synchronization service, the master node may also perform the following steps:

[0106] Step 1: When the network communication link is detected to be restored to normal and a network fault check command is received from the client, determine whether the target identifier is included in the target log.

[0107] Step two: When it is determined that the target log includes the target identifier, the target identifier is sent to the client so that the client can determine whether there is an inconsistency between the data of the primary node and the data of the backup node during the network communication link failure.

[0108] Specifically, refer to Figure 3After detecting that the network communication link has been restored, both the primary and backup nodes can send a notification to the client that the network communication link has been restored. Upon receiving these notifications, the client can send network fault check commands (e.g., grep commands) to both nodes. Upon receiving these commands, the primary and backup nodes can parse the target logs corresponding to the data synchronization service, determining whether the target fields include an identifier. If so, the identifier is sent to the client as a return result. If not, a check completion indication is sent to the client. After receiving the return results from both nodes, the client can determine whether both results contain the identifier. If so, it indicates that during the network communication link failure, both nodes considered themselves the primary node and responded to external requests, leading to data inconsistency (commonly known as data split-brain). The client can then display target alarm information to indicate that the target system has experienced data split-brain. If only one node's response includes an identifier, it's assumed that no data inconsistency occurred during the network communication link failure, and no action is required. If neither node's response includes an identifier, it's assumed that neither node responded to external requests during the network communication link failure, and the data remains consistent. However, the data synchronization service's operational status may be problematic. In this case, the client can send restart commands to both nodes. Upon receiving the restart commands, the primary and backup nodes can execute restart operations to re-run the data synchronization service.

[0109] In some optional implementations, if neither node returns an identifier, the client can first check the mount status of the data synchronization service on both nodes. If both nodes are unmounted, it indicates an error in the mount status of the two nodes. Therefore, a restart command can be sent to each node. This will restore the normal mount status of the data synchronization service on both nodes after a restart.

[0110] In some optional implementations, after seeing the target alarm information displayed on the client, technicians can use the DRBD recovery command to select which node's data to retain and which node's data to delete. Accordingly, both the primary and backup nodes can perform the following steps:

[0111] Step 1: Upon receiving the target data processing instruction from the client, delete the target identifier from the target log.

[0112] The target data processing instruction is the instruction obtained by the client when it determines that there is an inconsistency between the data of the primary node and the data of the backup node.

[0113] Step two: parse the target data processing instructions to obtain the operation type.

[0114] Step 3: When the operation type is determined to be a deletion operation, delete the data generated by the data synchronization service during the mounting period.

[0115] or,

[0116] Step 4: When the operation type is determined to be a retention operation, the data generated by the data synchronization service during the mounting period is retained.

[0117] For example, when the target data processor instruction is "drbdadm connect r0" and the operation type is a retain operation, the target data processor instruction is "drbdadm–discard-my-data connect r0" and the operation type is a delete operation.

[0118] In this way, upon receiving the target data processing instruction, the master node can delete the target identifier from the target log. This allows for the direct addition of a new time when a network communication link failure is detected subsequently, preventing multiple identifiers from existing simultaneously and thus avoiding the inability to correctly identify data inconsistencies. Furthermore, deleting or retaining data based on the target data processing instructions sent by the client can eliminate data inconsistency issues.

[0119] In some optional implementations, after receiving an alarm notification from the master node, the client can parse the alarm notification to determine the fault type. If the fault type is determined to be an operating system fault or a hardware fault, the client can send an operating system reinstallation command to the master node. Upon receiving the operating system reinstallation command, the master node can first perform the operating system reinstallation operation, and then retrieve the latest configuration files for each service from the standby node using the `drbdadminvalidate r0` command to complete the configuration operation. Alternatively, before sending the operating system reinstallation command to the master node, a configuration file check command (e.g., `icenter recovery check`, mainly checking the existence of dual-machine configuration files such as `ha.cf`, `haservice.xml`, and `r0.res`) can be sent to the standby node to obtain the feedback result. If the result indicates that the configuration files on the standby node are complete, the client then sends the operating system reinstallation command to the master node (e.g., `icenter recovery`). Alternatively, if the result indicates that the configuration files on the standby node are incomplete, a complete configuration file can be obtained and sent to the standby node before sending the operating system reinstallation command to the master node. The standby node can also use a similar method to perform the operating system reinstallation operation, which will not be elaborated here.

[0120] In this way, after receiving the alarm notification, the client can quickly analyze and determine the fault type, take corresponding measures in a timely manner, and shorten the fault response time.

[0121] This embodiment also provides a fault alarm device for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that performs a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0122] This embodiment provides a fault alarm device, such as Figure 4 Shown, including:

[0123] The acquisition module 401 is used to acquire, in the current cycle, the identification information corresponding to each service among at least one service running on the master node, and the startup dependency order corresponding to each service; based on the identification information and startup dependency order corresponding to each service, acquire the service status corresponding to each service; when it is determined that the service status corresponding to the target service is abnormal, or when the service status corresponding to the target service is not acquired, based on the identification information corresponding to the target service, acquire the configuration file of the target service in the current cycle, and the file content indicator value of the target service in the previous cycle corresponding to the current cycle, wherein the target service is any one of at least one services;

[0124] The determination module 402 is used to determine the fault type of the target service based on the configuration file of the target service in the current period and the file content indicator value of the target service in the previous period.

[0125] The generation module 403 is used to generate an alarm notification based on the identification information and fault type of the target service and send it to the client.

[0126] In some optional implementations, the acquisition module 401 is specifically used for:

[0127] The order in which service status is obtained is determined based on the startup dependency order corresponding to each service.

[0128] Based on the order in which the service status of each service is obtained, the identification information corresponding to each service is traversed.

[0129] For each service's identifier information traversed, the service status corresponding to the traversed service is obtained based on the identifier information of the traversed service.

[0130] After traversing through the identification information corresponding to all services in at least one service, the operation of obtaining the service status corresponding to each service in the current cycle is completed.

[0131] In some alternative implementations, the determining module 402 is specifically used for:

[0132] Based on the pre-built target algorithm, the configuration file of the target service in the current period is processed to obtain the file content index value of the target service in the current period.

[0133] The fault type of the target service is determined based on the file content metric values ​​of the target service in the previous period and the current period, respectively.

[0134] In some alternative implementations, the determining module 402 is specifically used for:

[0135] Determine whether the file content metric value of the target service in the previous period is consistent with the file content metric value in the current period;

[0136] When it is determined that the file content indicator value of the target service in the previous period is inconsistent with the file content indicator value in the current period, the fault type of the target service is determined to be the first fault type. The first fault type is used to indicate that the fault of the target service is that the configuration file of the target service has been modified.

[0137] or,

[0138] When it is determined that the file content indicator value of the target service in the previous period is consistent with the file content indicator value in the current period, the fault type of the target service is determined to be the second fault type. The second fault type is used to indicate that the cause of the fault of the target service is not that the configuration file of the target service has been modified.

[0139] In some alternative embodiments, the device further includes a detection module 404, which is used for:

[0140] When the services running on the master node include data synchronization services, the network communication link between the master node and the corresponding backup node is detected.

[0141] When a network communication link failure is detected, determine whether the master node has mounted the data synchronization service;

[0142] Once it is determined that the master node has mounted the data synchronization service, obtain the target time for mounting the data synchronization service.

[0143] Add the target time as the target identifier to the target log corresponding to the data synchronization service. The target identifier is used to instruct the master node to mount the data synchronization service during network communication link failures.

[0144] In some alternative implementations, the detection module 404 is further configured to:

[0145] When the network communication link is detected to have returned to normal and a network fault check command is received from the client, determine whether the target identifier is included in the target log.

[0146] When the target log is found to contain a target identifier, the target identifier is sent to the client so that the client can determine whether there is an inconsistency between the data of the primary node and the data of the backup node during the network communication link failure.

[0147] In some alternative embodiments, the device further includes a receiving module 405, which is also configured to:

[0148] Upon receiving the target data processing instruction sent by the client, the target identifier is deleted from the target log. The target data processing instruction is the instruction obtained by the client when it determines that there is an inconsistency between the data of the primary node and the data of the backup node.

[0149] Parse the target data processing instructions to obtain the operation type;

[0150] When the operation type is determined to be a deletion operation, the data generated by the data synchronization service during the mounting period is deleted;

[0151] or,

[0152] When the operation type is determined to be a retention operation, the data generated by the data synchronization service during the mounting process is retained.

[0153] Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0154] In this embodiment, the fault alarm device is presented in the form of a functional unit. Here, a unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0155] This invention also provides a computer device having the above-described features. Figure 4 The fault alarm device shown.

[0156] Please see Figure 5 , Figure 5 This is a schematic diagram of the structure of a computer device provided in an optional embodiment of the present invention, such as... Figure 5 As shown, the computer device includes one or more processors 10, memory 20, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple computer devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system). Figure 5 Take a processor 10 as an example.

[0157] Processor 10 may be a central processing unit, a network processor, or a combination thereof. Processor 10 may further include a hardware integrated circuit. The aforementioned hardware integrated circuit may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The aforementioned programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GDA), or any combination thereof.

[0158] The memory 20 stores instructions executable by at least one processor 10 to cause the at least one processor 10 to perform the method shown in the above embodiments.

[0159] The memory 20 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the computer device. Furthermore, the memory 20 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, the memory 20 may optionally include memory remotely located relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0160] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, hard disk or solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0161] The computer device also includes a communication interface 30 for communicating with other devices or communication networks.

[0162] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0163] A portion of this invention can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to the invention through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0164] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A fault alarm method, characterized in that, The method includes: In the current cycle, obtain the identification information corresponding to each of the at least one services running on the master node, as well as the startup dependency order corresponding to each of the services; Based on the identification information and startup dependency order corresponding to each service, obtain the service status corresponding to each service; When it is determined that the service status corresponding to the target service is abnormal, or when the service status corresponding to the target service is not obtained, the configuration file of the target service in the current period and the file content index value of the target service in the previous period corresponding to the current period are obtained according to the identification information corresponding to the target service, wherein the target service is any one of at least one of the services. The fault type of the target service is determined based on the configuration file of the target service in the current period and the file content indicator value of the target service in the previous period. Based on the identification information and fault type of the target service, an alarm notification is generated and sent to the client.

2. The method according to claim 1, characterized in that, The step of obtaining the service status corresponding to each service based on the identification information and startup dependency order corresponding to each service includes: The order in which the service status is obtained for each service is determined based on the startup dependency order corresponding to each service. Based on the order in which the service status of each service is obtained, the identification information corresponding to each service is traversed. For each service's identifier information traversed, the service status corresponding to the traversed service is obtained based on the identifier information of the traversed service. After traversing through the identification information corresponding to all services in at least one of the services, the operation of obtaining the service status corresponding to each service in the current cycle is completed.

3. The method according to claim 1 or 2, characterized in that, The step of determining the fault type of the target service based on the configuration file of the target service in the current period and the file content indicator value of the target service in the previous period includes: Based on the pre-built target algorithm, the configuration file of the target service in the current period is processed to obtain the file content index value of the target service in the current period; The fault type of the target service is determined based on the file content index values ​​corresponding to the target service in the previous period and the current period, respectively.

4. The method according to claim 3, characterized in that, The step of determining the fault type of the target service based on the file content indicator values ​​corresponding to the target service in the previous period and the current period includes: Determine whether the file content indicator value of the target service in the previous period is consistent with the file content indicator value in the current period; When it is determined that the file content indicator value of the target service in the previous period is inconsistent with the file content indicator value in the current period, the fault type of the target service is determined to be the first fault type, wherein the first fault type is used to indicate that the fault of the target service is that the configuration file of the target service has been modified. or, When it is determined that the file content indicator value of the target service in the previous period is consistent with the file content indicator value in the current period, the fault type of the target service is determined to be the second fault type, wherein the second fault type is used to indicate that the fault cause of the target service is not that the configuration file of the target service has been modified.

5. The method according to claim 1 or 2, characterized in that, When the services running on the master node include a data synchronization service, the method further includes: The network communication link between the master node and the backup node corresponding to the master node is detected. When a network communication link failure is detected, it is determined whether the master node has mounted the data synchronization service; When it is determined that the master node has mounted the data synchronization service, obtain the target time for mounting the data synchronization service; The target time is added as a target identifier to the target log corresponding to the data synchronization service, wherein the target identifier is used to instruct the master node to mount the data synchronization service during the network communication link failure.

6. The method according to claim 5, characterized in that, After adding the target time as a target identifier to the target log corresponding to the data synchronization service, the method further includes: When the network communication link is detected to have returned to normal and a network fault check instruction sent by the client is received, it is determined whether the target identifier is included in the target log; When it is determined that the target log includes the target identifier, the target identifier is sent to the client so that the client can determine whether there is an inconsistency between the data of the primary node and the data of the backup node during the network communication link failure.

7. The method according to claim 6, characterized in that, After determining that the target log includes the target identifier, and sending the target identifier to the client, the method further includes: Upon receiving the target data processing instruction sent by the client, the target identifier is deleted from the target log. The target data processing instruction is the instruction obtained by the client when it determines that there is an inconsistency between the data of the master node and the data of the backup node. The target data processing instructions are parsed to obtain the operation type; When the operation type is determined to be a deletion operation, the data generated by the data synchronization service during the mounting period is deleted; or, When the operation type is determined to be a retention operation, the data generated by the data synchronization service during the mounting process is retained.

8. A device for determining the type of fault, characterized in that, The device comprises: The acquisition module is configured to, in the current cycle, acquire the identification information corresponding to each of the at least one services running on the master node, and the startup dependency order corresponding to each of the services; acquire the service status corresponding to each of the services based on the identification information and startup dependency order corresponding to each service; when it is determined that the service status corresponding to the target service is abnormal, or when the service status corresponding to the target service is not acquired, acquire the configuration file of the target service in the current cycle, and the file content indicator value of the target service in the previous cycle corresponding to the current cycle, based on the identification information corresponding to the target service, wherein the target service is any one of the at least one of the services; The determination module is used to determine the fault type of the target service based on the configuration file of the target service in the current period and the file content indicator value of the target service in the previous period. The generation module is used to generate an alarm notification based on the identification information and fault type of the target service, and send it to the client.

9. A computer device, characterized in that, include: A memory and a processor are communicatively connected, the memory stores computer instructions, and the processor executes the computer instructions to perform the fault alarm method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to execute the fault alarm method according to any one of claims 1 to 7.

Images