Fault alarm method and device, computer equipment and storage medium

Abstract

The invention relates to the technical field of computers, and discloses a fault alarm method and device, computer equipment and a storage medium, and the method comprises the steps: obtaining identification information and a starting dependency sequence of each service operated by a main node in a current period; obtaining the service state of each service according to the identification information of each service and the starting dependency sequence; when it is determined that the service state of the target service is abnormal or the service state of the target service is not obtained, a configuration file of the target service in the current period and a file content index value of the target service in a previous period corresponding to the current period are obtained according to the identification information of the target service, and the target service is any service; determining the fault type of the target service according to 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; and generating an alarm notification according to the identification information of the target service and the fault type, and sending the alarm notification to the client. According to the invention, the troubleshooting efficiency can be improved.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a fault alarm method, device, computer equipment and storage medium. Background Art

[0002] In the field of computer technology, service platforms often use a dual-machine hot standby system. The dual-machine hot standby system includes a master node and a standby node. The relevant configurations of the two nodes are exactly the same. Under normal reset, there is only one node as the master node to provide services to the outside world. When the master node fails, the standby node can immediately start the service to respond to external data requests.

[0003] However, after a node fails, technicians need to use complex query operations to troubleshoot related fault issues, 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, obtaining identification information corresponding to each of the at least one service running on the master node, and a startup dependency sequence corresponding to each of the services;

[0007] Acquire the service status corresponding to each of the services according to the identification information corresponding to each of the services and the startup dependency sequence;

[0008] 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, obtaining, according to the identification information corresponding to the target service, a configuration file of the target service in the current cycle and a file content index value of the target service in a previous cycle corresponding to the current cycle, wherein the target service is any one of at least one of the services;

[0009] Determine the fault type of the target service according to the configuration file of the target service in the current cycle and the file content index value of the target service in the previous cycle;

[0010] An alarm notification is generated according to the identification information and fault type of the target service and sent to the client.

[0011] A fault alarm method provided by the present invention has the following advantages:

[0012] This solution periodically obtains the identification information and startup dependency sequence of the services running on the master node, and uses this as a basis to obtain the service status of the service. When it is determined that the service status is abnormal or the service status is not obtained, the configuration file of the service in the current cycle and the file content index value of the service in the previous cycle are further obtained based on the identification information of the service, and the type of fault is determined. Finally, an alarm notification is generated based on the identification information and fault type of the service and sent to the client. In this way, the technical staff can understand which specific part the fault occurred in and the specific cause of the fault (that is, the type of fault) without actively querying and analyzing. In this way, the efficiency of troubleshooting is high, which is convenient for technical staff to solve related faults in a timely manner and reduce the impact on the running services of the master node.

[0013] In an optional implementation, acquiring the service status corresponding to each of the services according to the identification information corresponding to each of the services and the startup dependency sequence includes:

[0014] Determine a service status acquisition order corresponding to each of the services according to a startup dependency order corresponding to each of the services;

[0015] According to the order of obtaining the service status corresponding to each of the services, traversing the identification information corresponding to each of the services;

[0016] Each time identification information of a service is traversed, the service status corresponding to the traversed service is obtained according to the identification information corresponding to the traversed service;

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

[0018] Specifically, obtaining the service status in the startup dependency order can ensure that before checking a service, all its dependent services have been checked. This helps to identify problems caused by dependent service failures, thereby more accurately determining the service status.

[0019] In an optional implementation, determining the fault type of the target service according to the configuration file of the target service in the current cycle and the file content index value of the target service in the previous cycle includes:

[0020] After processing the configuration file of the target service in the current period according to the pre-built target algorithm, a file content index value of the target service in the current period is obtained;

[0021] The fault type of the target service is determined according to the file content indicator values ​​corresponding to the target service in the previous cycle and the current cycle respectively.

[0022] Specifically, in the related art, all configuration parameters in the configuration file are generally traversed, and each configuration parameter is determined to determine whether it is possible that the fault is caused by the configuration change. Since the configuration file includes other codes in addition to the configuration parameters, changes in these codes may also cause faults. Therefore, this solution directly determines the fault type by checking whether the file content index values ​​corresponding to the service in two adjacent cycles are the same. In this way, the accuracy of the fault type can be guaranteed, and the efficiency of determining the fault type can also be improved.

[0023] In an optional implementation manner, determining the fault type of the target service according to the file content indicator values ​​corresponding to the target service in the previous cycle and the current cycle respectively includes:

[0024] Determine whether the file content index value corresponding to the target service in the previous cycle is consistent with the file content index value corresponding to the current cycle;

[0025] When it is determined that the file content index value corresponding to the target service in the previous cycle and the file content index values ​​respectively corresponding to the current cycle are inconsistent, determining that the fault type of the target service is a first fault type, wherein the first fault type is used to indicate that the cause of the fault of the target service is that the configuration file of the target service is modified;

[0026] or,

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

[0028] Specifically, when it is determined that the file content index values ​​of the target service in two adjacent cycles are consistent, it can be explained that the configuration file has not changed, indicating that the cause of the target service failure is not a failure of the configuration file, but a failure of the master node, such as a hardware failure, or a change in the operating system or other configuration files. When it is determined that the file content index values ​​of the target service in two adjacent cycles are inconsistent, it can be explained that the cause of the target service failure is a change in its own configuration file.

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

[0030] Detecting a network communication link between the master node and a standby node corresponding to the master node;

[0031] When a failure of the network communication link is detected, determining 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, obtaining a target time for mounting the data synchronization service;

[0033] The target time is added as a target identifier to a 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 failure of the network communication link.

[0034] Specifically, by regularly checking the network communication link between the master node and the backup node, we can respond to network failures as soon as they occur, maintaining a certain degree of service continuity. In addition, when a network failure occurs, we check whether the data synchronization service is mounted, record the time of mounting, and add the target time as an identifier to the log, providing a clear time clue for subsequent troubleshooting, facilitating the analysis of the data status during the failure, and thus locating the root cause of the problem more quickly.

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

[0036] When it is detected that the network communication link is restored to normal and a network fault checking instruction sent by the client is received, determining whether the target log includes the target identifier;

[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 inconsistency occurs 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 is possible to clearly know whether the primary node has mounted the data synchronization service during the communication link failure. This allows the client to evaluate and repair data inconsistencies based on the received target identifier, thereby ensuring data synchronization between the primary and standby nodes.

[0039] In an optional implementation, when it is determined that the target log includes the target identifier, after sending the target identifier to the client, the method further includes:

[0040] After receiving the target data processing instruction sent by the client, deleting the target identifier from the target log, wherein the target data processing instruction is an instruction obtained when the client determines that the data of the primary node and the data of the standby node are inconsistent;

[0041] Parsing the target data processing instruction to obtain an operation type;

[0042] When it is determined that the operation type is a deletion operation, deleting the data generated by the data synchronization service during the mounting period;

[0043] or,

[0044] When it is determined that the operation type is a retain operation, the data generated by the data synchronization service during the mounting period is retained.

[0045] Specifically, after receiving the target data processing instruction, the master node can delete the target identifier from the target log. In this way, when the network communication link failure is detected again in the future, the new time can be directly added to avoid the problem of multiple identifiers existing at the same time, which leads to the inability to correctly identify data inconsistency in the future. In addition, deleting or retaining data based on the target data processing instruction sent by the client can eliminate the problem of data inconsistency.

[0046] In a second aspect, the present invention provides a fault alarm device, the device comprising:

[0047] An acquisition module is used to acquire, in the current cycle, identification information corresponding to each of the at least one service run by the master node, and a startup dependency sequence corresponding to each of the services; acquire the service status corresponding to each of the services according to the identification information and the startup dependency sequence corresponding to each of the services; 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 acquired, acquire the configuration file of the target service in the current cycle according to the identification information corresponding to the target service, and the file content index value of the target service in the previous cycle corresponding to the current cycle, wherein the target service is any one of the at least one services;

[0048] A determination module, configured to determine a fault type of the target service according to a configuration file of the target service in the current cycle and a file content index value of the target service in the previous cycle;

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

[0050] In a third aspect, the present invention provides a computer device, comprising: a memory and a processor, the memory and the processor are communicatively connected to each other, computer instructions are stored in the memory, and the processor executes the fault alarm method of the first aspect or any corresponding embodiment thereof by executing the computer instructions.

[0051] In a fourth aspect, the present invention provides a computer-readable storage medium having computer instructions stored thereon, the computer instructions being used to enable a computer to execute the fault alarm method of the first aspect or any corresponding embodiment thereof.

[0052] In a fifth aspect, the present invention provides a computer program product, including computer instructions, which are used to enable a computer to execute the fault alarm method of the first aspect or any corresponding embodiment thereof. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in the related technologies, the drawings required for use in the specific embodiments or the related technical descriptions will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

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

[0055] Figure 2 is a flow chart of a fault alarm method according to an embodiment of the present invention;

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

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

[0058] Figure 5 It is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0059] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.

[0060] The present invention can be implemented by a target system, such as Figure 1 As shown, the target system may include multiple nodes and clients, wherein the multiple nodes include a master node and a backup node. The master node and the backup node may be servers, and the client may be a computer, a mobile phone, etc.

[0061] The embodiment of the present invention provides a fault alarm method, which is highly efficient by automatically giving an alarm and generating a fault type.

[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 of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0063] In this embodiment, a fault alarm method is provided, which can be executed by the master node. Figure 2 is a flow chart of a fault alarm method according to an embodiment of the present invention. Figure 2 As shown, the process includes the following steps:

[0064] Step S201, in the current cycle, obtain identification information corresponding to each service in at least one service running on the master node, and a startup dependency sequence corresponding to each service.

[0065] The identification information of the service may be the name, number, etc. of the service. For example, the service may include a database service, a memory data structure service, a request processing service, etc. The startup dependency sequence of the database service may be 1, the startup dependency sequence of the memory data structure service may be 2, and the startup dependency sequence of the request processing service may be 3.

[0066] Specifically, when any node in the target system becomes the master node, it can start to periodically call the detection script. According to the execution steps in the detection script, it first obtains the identification information and startup dependency sequence of the currently running services to check whether there is any service failure.

[0067] Step S202: acquiring the service status corresponding to each service according to the identification information and the startup dependency sequence corresponding to each service.

[0068] The service status may be normal or abnormal.

[0069] Specifically, the master node may first determine the order of obtaining the service status corresponding to each service according to the startup dependency order corresponding to each service. Then, according to the order of obtaining the service status corresponding to each service, the identification information corresponding to each service is traversed. Each time the identification information of a service is traversed, the service status corresponding to the traversed service is obtained according to the identification information corresponding to the traversed service. In this way, after traversing 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.

[0070] In some optional implementations, according to the identification information corresponding to the traversed service, obtaining the service status corresponding to the traversed service may specifically be:

[0071] First, obtain the pre-built acquisition instruction template, and then, based on the acquisition instruction template and the identification information of the traversed service, generate and execute the acquisition instruction corresponding to the identification information of the traversed service. After the execution is completed, the service status can be obtained. For example, the acquisition instruction template can 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 cycle and the file content index value of the target service in the previous cycle corresponding to the current cycle are obtained according to the identification information corresponding to the target service.

[0073] The target service may be any one of the at least one service.

[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 processing is required. If it is abnormal, the fault type can be further determined. Alternatively, after executing the acquisition instruction corresponding to the identification information of the target service, when the return result is that the service status acquisition failed (that is, 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 from itself according to the identification information of the target service, as well as the file content indicator value of the target service in the previous cycle. For example, the configuration file of the database service can be "mariadb-server.conf", and the configuration file of the request processing service can be "httpd.conf".

[0075] Step S204: determine the fault type of the target service according to the configuration file of the target service in the current cycle and the file content index value of the target service in the previous cycle.

[0076] The file content indicator value may be an MD5 checksum value.

[0077] Specifically, the master node can determine the failure type of the target service according to the following steps:

[0078] Step 1: After processing the configuration file of the target service in the current period according to the pre-built target algorithm, the file content index value of the target service in the current period is obtained.

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

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

[0081] Specifically, determine whether the file content index value corresponding to the target service in the previous cycle is consistent with the file content index value corresponding to the current cycle. When the master node determines that the file content index value corresponding to the target service in the previous cycle and the file content index value corresponding to the current cycle are inconsistent, it can be determined that the fault type of the target service is a first fault type, wherein the first fault type is used to indicate that the cause of the failure of the target service is that the configuration file of the target service has been modified. Alternatively, when the master node determines that the file content index value corresponding to the target service in the previous cycle and the file content index value corresponding to the current cycle are consistent, it is determined that the fault type of the target service is a second fault type, wherein the second fault type is used to indicate that the cause of the failure of the target service is not that the configuration file of the target service has been modified.

[0082] After calculating the file content index value corresponding to the target service in the current cycle, the identification information of the target service and the file content index value corresponding to the current cycle may be recorded accordingly for determining the fault type in the next cycle.

[0083] In some optional implementations, after the master node determines that the file content index value corresponding to the target service in the previous cycle is consistent with the file content index value corresponding to the current cycle, the following operations may be performed:

[0084] Determine whether the failure type of the previous service that starts the dependency sequence before the target service is the first failure type. If so, determine that the failure type of the target service is the first sub-failure type in the second failure type, where the first sub-failure type is used to indicate that the failure of the target service is caused by the modification of the configuration file of the service on which it depends. If not, determine that the failure cause of the target service is the second sub-failure type in the second failure type, where the second sub-failure type is used to indicate that the failure cause of the target service is an operating system failure or a hardware failure of the primary node.

[0085] In this way, more specific fault causes can be indicated to technicians, speeding up the efficiency of troubleshooting.

[0086] Step S205: Generate an alarm notification based on the identification information and fault type of the target service 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 identification information and fault type of the target service and send it to the client. After receiving the alarm notification, the client can directly display it, and the technician can understand the faulty service and the specific fault type, and perform operations to solve the fault problem. In this way, the fault duration of the target service can be reduced.

[0088] In some optional implementations, after determining whether each service fails and the failure type of each failed service, the master node can generate an alarm notification and send it to the client according to the identification information and failure type corresponding to all failed services. In this way, the waste of network resources can be reduced.

[0089] In some optional implementations, after determining whether each service has failed and the type of failure of each failed service, the master node can first count the number of failed services and obtain the level corresponding to each failed service (the higher the level of the failed service, the greater the impact on the operation of the master node after the failure), and then determine the alarm level according to the number of failed services and the level corresponding to each failed service, and generate an alarm notification to the client according to the alarm level, identification information of each failed service and the type of failure. In addition, when the master node determines that the alarm level is greater than the preset alarm level, it can shut down the network. In this way, the standby node cannot receive the heartbeat signal from the master node, and it will become the master node to provide services to the outside world.

[0090] The following expression can be used to determine the alarm level according to the number of faulty services and the level corresponding to each faulty service:

[0091]

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

[0093] In this way, when a serious failure 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 solve the failure in time 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 sequence of the service running on the master node, and obtains the service status of the service based on this. When it is determined that the service status is abnormal or the service status is not obtained, the configuration file of the service in the current cycle and the file content index value of the service in the previous cycle are further obtained based on the identification information of the service, and the fault type is determined. Finally, an alarm notification is generated based on the identification information and fault type of the service and sent to the client. In this way, the technical staff can understand which specific part the fault occurs in and the specific cause of the fault (i.e., the fault type) without actively querying and analyzing. In this way, the troubleshooting efficiency is high, which is convenient for technical staff to solve related faults in a timely manner and reduce the impact on the running service.

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

[0096] Step 1: Detect the network communication link between the master node and the backup node corresponding to the master 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 may be a distributed replicated block device service (Distributed Replicated Block Device, DRBD).

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

[0100] Step 4: Add the target time as a 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 the data synchronization service during a network communication link failure.

[0102] Specifically, the master node can periodically detect the network communication link between itself and the standby node. The detection can be checked by using the ping command. For example, "ping+standby node communication address-c100-i0.001" means pinging 100 times within 1 second to obtain the inspection result, and determine whether the network communication link fails according to the inspection result. Alternatively, the grep command can be used to check whether a packet loss event occurs. If so, it is considered that the network communication link is detected to be faulty.

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

[0104] In this way, by regularly checking the network communication link between the primary node and the backup node, you can respond to network failures as soon as they occur, maintaining a certain degree of service continuity. In addition, when a network failure occurs, check whether the data synchronization service (such as DRBD) is mounted, record the time of mounting, and add the time as an identifier to the target log, providing a clear time clue for subsequent troubleshooting, facilitating the analysis of the data status during the failure, and thus locating the root cause of the problem more quickly. Through the identifier, technicians can understand which node records more data 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 further perform the following steps:

[0106] Step 1: When it is detected that the network communication link is restored to normal and a network fault checking instruction sent by the client is received, it is determined whether the target log includes a target identifier.

[0107] Step 2: When it is determined that the target log includes a target identifier, the target identifier is sent to the client, so that the client can determine whether there is 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 returned to normal, both the master node and the standby node can send a notification to the client that the network communication link has returned to normal. After receiving the notification that the network communication link has returned to normal sent by the master node and the standby node, the client can send a network fault check instruction (for example, a grep instruction) to the two nodes respectively. In this way, after receiving the network fault check instruction, the master node and the standby node can parse the target log corresponding to the data synchronization service stored in themselves to determine whether its target field includes an identifier. If so, the identifier is sent to the client as a return result. If not, the indication information of the completion of the check is sent to the client as a return result. After receiving the return results fed back by the master node and the standby node respectively, the client can determine whether the return results fed back by the two nodes include an identifier. If so, it is determined that during the network communication link failure, both nodes considered themselves to be the master node and responded to external requests, resulting in inconsistency in the data of the two nodes (generally also called data brain split). The client can display the target alarm information to indicate that the target system has a data brain split. If only one node includes an identifier in the feedback result, it is considered that there is no data inconsistency problem during the network communication link failure, and no processing is required. If there is no identifier in the feedback results of both nodes, it is considered that during the network communication link failure, both nodes did not respond to external requests, the data remains consistent, but there may be a problem with the running status of the data synchronization service. At this time, the client can send a restart instruction to each of the two nodes. After receiving the restart instruction, the primary node and the backup node can perform a restart operation and re-run the data synchronization service.

[0109] In some optional implementations, if there is no identifier in the results fed back by the two nodes, the client can first detect the mounting status of the data synchronization services of the two nodes. If the mounting status of the data synchronization services of the two nodes is not mounted, it means that the mounting status of the two nodes is wrong. Therefore, a restart instruction can be sent to the two nodes respectively. In this way, the normal mounting status of the data synchronization services of the two nodes can be restored after the restart.

[0110] In some optional implementations, after seeing the target alarm information displayed by the client, the technician 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 node and the standby node can perform the following steps:

[0111] Step 1: After receiving the target data processing instruction sent by the client, the target identifier is deleted from the target log.

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

[0113] Step 2: parse the target data processing instruction to obtain the operation type.

[0114] Step three: when it is determined that the operation type is a deletion operation, the data generated by the data synchronization service during the mounting period is deleted.

[0115] or,

[0116] Step 4: When it is determined that the operation type is a retain 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", the operation type is a retain operation, and when the target data processor instruction is "drbdadm-discard-my-data connect r0", the operation type is a delete operation.

[0118] In this way, after receiving the target data processing instruction, the master node can delete the target identifier from the target log. In this way, when the network communication link failure is detected again in the future, the new time can be directly added to avoid the problem of multiple identifiers existing at the same time, which leads to the inability to correctly identify data inconsistency in the future. In addition, deleting or retaining data based on the target data processing instruction sent by the client can eliminate the problem of data inconsistency.

[0119] In some optional implementations, after receiving the alarm notification sent by the master node, the client can parse the alarm notification to obtain the fault type. When it is determined that the fault type is an operating system fault or a hardware fault, an operating system reinstallation instruction can be sent to the master node. After receiving the operating system reinstallation instruction, the master node can first perform the operation of reinstalling the operating system, and then obtain the latest configuration files of each service from the standby node according to the drbdadminvalidate r0 command to complete the configuration operation. In addition, before sending the operating system reinstallation instruction to the master node, a configuration file check instruction (for example, icenter recovery check, mainly checking whether the dual-machine configuration files such as ha.cf, haservice.xml, and r0.res exist) can be sent to the standby node first to obtain the result of the standby node feedback. When the result is used to indicate that the configuration file on the standby node is complete, the client sends the operating system reinstallation instruction (for example, icenter recovery) to the master node. Alternatively, when the result is used to indicate that the configuration file on the standby node is incomplete, a complete configuration file can be obtained and sent to the standby node first, and then the operating system reinstallation instruction can be sent to the master node. The standby node can also perform the reinstallation operation of the operating system in a similar manner, which will not be repeated here.

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

[0121] In this embodiment, a fault alarm device is also provided, which is used to implement the above-mentioned embodiments and preferred implementation modes, and the descriptions that have been made will not be repeated. As used below, the term "module" can implement a combination of software and / or hardware of a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceivable.

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

[0123] The acquisition module 401 is used to acquire, in the current cycle, the identification information corresponding to each service of at least one service run by the master node, and the startup dependency sequence corresponding to each service; acquire the service status corresponding to each service according to the identification information and the startup dependency sequence corresponding to each service; 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 acquired, acquire the configuration file of the target service in the current cycle according to the identification information corresponding to the target service, and the file content index value of the target service in the previous cycle corresponding to the current cycle, wherein the target service is any one of the at least one service;

[0124] The determination module 402 is used to determine the fault type of the target service according to the configuration file of the target service in the current cycle and the file content index value of the target service in the previous cycle;

[0125] The generating module 403 is used to generate an alarm notification according to the identification information and the fault type of the target service, and send the alarm notification to the client.

[0126] In some optional implementations, the acquisition module 401 is specifically configured to:

[0127] Determine the order of obtaining the service status corresponding to each service according to the startup dependency order corresponding to each service;

[0128] According to the order of obtaining the service status corresponding to each service, traverse the identification information corresponding to each service;

[0129] Each time identification information of a service is traversed, the service status corresponding to the traversed service is obtained according to the identification information corresponding to the traversed service;

[0130] After traversing 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 optional implementations, the determination module 402 is specifically configured to:

[0132] According to the pre-built target algorithm, after processing the configuration file of the target service in the current cycle, the file content index value of the target service in the current cycle is obtained;

[0133] The fault type of the target service is determined according to the file content indicator values ​​corresponding to the target service in the previous cycle and the current cycle respectively.

[0134] In some optional implementations, the determination module 402 is specifically configured to:

[0135] Determine whether the file content index value corresponding to the target service in the previous cycle is consistent with the file content index value corresponding to the current cycle;

[0136] When it is determined that the file content index value corresponding to the target service in the previous cycle and the file content index values ​​respectively corresponding to the current cycle are inconsistent, determining that the fault type of the target service is a first fault type, wherein the first fault type is used to indicate that the cause of the fault of the target service is that the configuration file of the target service is modified;

[0137] or,

[0138] When it is determined that the file content index value corresponding to the target service in the previous cycle is consistent with the file content index value corresponding to the current cycle, 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 cause of the failure of the target service is not that the configuration file of the target service has been modified.

[0139] In some optional implementations, the device further includes a detection module 404, and the detection module 404 is used to:

[0140] When the services running in the master node include a data synchronization service, a network communication link between the master node and a standby node corresponding to the master node is detected;

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

[0142] When it is determined that the data synchronization service has been mounted on the master node, the target time for mounting the data synchronization service is obtained;

[0143] The target time is added as a target identifier to a 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 a network communication link failure.

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

[0145] When it is detected that the network communication link is restored to normal and a network fault checking instruction sent by the client is received, determining whether the target log includes a target identifier;

[0146] 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 inconsistency occurs between the data of the primary node and the data of the standby node during the network communication link failure.

[0147] In some optional implementations, the device further includes a receiving module 405, and the receiving module 405 is further configured to:

[0148] After receiving the target data processing instruction sent by the client, the target identifier is deleted from the target log, wherein the target data processing instruction is an instruction obtained when the client determines that the data of the primary node and the data of the standby node are inconsistent;

[0149] Parse the target data processing instruction 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 period is retained.

[0153] The further functional description of each of the above modules and units is the same as that of the above corresponding embodiments and will not be repeated here.

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

[0155] The embodiment of the present invention also provides a computer device having the above Figure 4 The fault warning device shown.

[0156] See also Figure 5 , Figure 5 is a schematic diagram of the structure of a computer device provided by an optional embodiment of the present invention, such as Figure 5 As shown, the computer device includes: one or more processors 10, a memory 20, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. Various components are connected to each other using different buses for communication, and can be installed on a common mainboard or installed in other ways as needed. The processor can process the instructions executed in the computer device, including instructions stored in or on the memory to display the graphical information of the GUI on an external input / output device (such as, a display device coupled to the interface). In some optional embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple computer devices can be connected, and each device provides some necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system). Figure 5 A processor 10 is taken as an example.

[0157] The processor 10 may be a central processing unit, a network processor or a combination thereof. The processor 10 may further include a hardware integrated circuit. The hardware integrated circuit may be a dedicated integrated circuit, a programmable logic device or a combination thereof. The programmable logic device may be a complex programmable logic device, a field programmable logic gate array, a general purpose array logic or any combination thereof.

[0158] The memory 20 stores instructions executable by at least one processor 10, so that the at least one processor 10 executes the method shown in the above embodiment.

[0159] The memory 20 may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; the data storage area may store data created according to the use of the computer device, etc. In addition, the memory 20 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some optional embodiments, the memory 20 may optionally include a memory remotely arranged relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

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

[0161] The computer device further comprises a communication interface 30 for the computer device to communicate with other devices or a communication network.

[0162] The embodiment of the present invention also provides a computer-readable storage medium. The method according to the embodiment of the present invention can be implemented in hardware, firmware, or can be implemented as a computer code that can be recorded in a storage medium, or can be implemented as a computer code that is originally stored in a remote storage medium or a non-temporary machine-readable storage medium and will be stored in a local storage medium through a network download, so that the method described herein can be stored in such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only storage memory, a random access memory, a flash memory, a hard disk or a solid-state hard disk, etc.; further, the storage medium can also include a combination of the above types of memories. It can be understood that a computer, a processor, a microprocessor controller, or programmable hardware includes a storage component that can store or receive software or computer code. When the software or computer code is accessed and executed by a computer, a processor, or hardware, the method shown in the above embodiment is implemented.

[0163] A part of the present invention may be applied as a computer program product, such as a computer program instruction, which, when executed by a computer, can call or provide the method and / or technical solution according to the present invention through the operation of the computer. Those skilled in the art should understand that the existence of the computer program instruction in a computer-readable medium includes, but is not limited to, a source file, an executable file, an installation package file, etc., and accordingly, the way in which the computer program instruction is executed by the computer includes, but is not limited to: the computer directly executes the instruction, or the computer compiles the instruction and then executes the corresponding compiled program, or the computer reads and executes the instruction, or the computer reads and installs the instruction and then executes the corresponding installed program. Here, the computer-readable medium may be any available computer-readable storage medium or communication medium accessible to the computer.

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

Claims

1. A fault alarm method, characterized in that: The method comprises: In the current cycle, obtaining identification information corresponding to each of the at least one service running on the master node, and a startup dependency sequence corresponding to each of the services; Acquire the service status corresponding to each of the services according to the identification information corresponding to each of the services and the startup dependency sequence; 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, obtaining, according to the identification information corresponding to the target service, a configuration file of the target service in the current cycle and a file content index value of the target service in a previous cycle corresponding to the current cycle, wherein the target service is any one of at least one of the services; Determine the fault type of the target service according to the configuration file of the target service in the current cycle and the file content index value of the target service in the previous cycle; An alarm notification is generated according to the identification information and fault type of the target service and sent to the client.

2. The method according to claim 1, characterized in that The acquiring the service status corresponding to each of the services according to the identification information corresponding to each of the services and the startup dependency sequence includes: Determine a service status acquisition order corresponding to each of the services according to a startup dependency order corresponding to each of the services; According to the order of obtaining the service status corresponding to each of the services, traversing the identification information corresponding to each of the services; Each time identification information of a service is traversed, the service status corresponding to the traversed service is obtained according to the identification information corresponding to the traversed service; After traversing the identification information corresponding to all services in at least one of the services, the operation of acquiring the service status corresponding to each of the services in the current cycle is completed.

3. The method according to claim 1 or 2, characterized in that: The determining the fault type of the target service according to 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 includes: After processing the configuration file of the target service in the current period according to the pre-built target algorithm, a file content index value of the target service in the current period is obtained; The fault type of the target service is determined according to the file content indicator values ​​corresponding to the target service in the previous cycle and the current cycle respectively.

4. The method according to claim 3, characterized in that: The determining the fault type of the target service according to the file content indicator values ​​corresponding to the target service in the previous cycle and the current cycle respectively includes: Determine whether the file content index value corresponding to the target service in the previous cycle is consistent with the file content index value corresponding to the current cycle; When it is determined that the file content index value corresponding to the target service in the previous cycle and the file content index values ​​respectively corresponding to the current cycle are inconsistent, determining that the fault type of the target service is a first fault type, wherein the first fault type is used to indicate that the cause of the fault of the target service is that the configuration file of the target service is modified; or, When it is determined that the file content index value corresponding to the target service in the previous period is consistent with the file content index value corresponding to the current period, it is determined that the failure type of the target service is the second failure type, wherein the second failure type is used to indicate that the cause of the failure 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 service running in the master node includes a data synchronization service, the method further includes: Detecting a network communication link between the master node and a standby node corresponding to the master node; When a failure of the network communication link is detected, determining whether the master node has mounted the data synchronization service; When it is determined that the master node has mounted the data synchronization service, obtaining a target time for mounting the data synchronization service; The target time is added as a target identifier to a 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 failure of the network communication link.

6. The method according to claim 5, characterized in that After adding the target time as a target identifier to a target log corresponding to the data synchronization service, the method further includes: When it is detected that the network communication link is restored to normal and a network fault checking instruction sent by the client is received, determining whether the target log includes the target identifier; 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 inconsistency occurs 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 When it is determined that the target log includes the target identifier, after sending the target identifier to the client, the method further includes: After receiving the target data processing instruction sent by the client, deleting the target identifier from the target log, wherein the target data processing instruction is an instruction obtained when the client determines that the data of the primary node and the data of the standby node are inconsistent; Parsing the target data processing instruction to obtain an operation type; When it is determined that the operation type is a deletion operation, deleting the data generated by the data synchronization service during the mounting period; or, When it is determined that the operation type is a retain operation, the data generated by the data synchronization service during the mounting period is retained.

8. A device for determining a fault type, characterized in that: The device comprises: An acquisition module is used to acquire, in the current cycle, identification information corresponding to each of the at least one service run by the master node, and a startup dependency sequence corresponding to each of the services; acquire the service status corresponding to each of the services according to the identification information and the startup dependency sequence corresponding to each of the services; 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 acquired, acquire the configuration file of the target service in the current cycle according to the identification information corresponding to the target service, and the file content index value of the target service in the previous cycle corresponding to the current cycle, wherein the target service is any one of the at least one services; A determination module, configured to determine a fault type of the target service according to a configuration file of the target service in the current cycle and a file content index value of the target service in the previous cycle; The generating module is used to generate an alarm notification according to the identification information and the fault type of the target service, and send the alarm notification to the client.

9. A computer device, characterized in that: include: 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 fault alarm method according to any one of claims 1 to 7 by executing the computer instructions.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a computer to execute the fault alarm method according to any one of claims 1 to 7.

Images