Health monitoring method and device for server

Abstract

The invention relates to a health monitoring method and device for a server. The method comprises the steps of determining a target server according to a traffic scheduling algorithm when load balancing equipment acquires traffic data; sending a TCP (Transmission Control Protocol) message for establishing connection to the target server, and recording message sending time; obtaining a return message of the target server, and recording a message return time and a message return type; and performing health monitoring on the target server according to the message sending time, the message return time and the message return type. According to the health monitoring method and device for the server, the problems that faults cannot be found in time and burdens of the server and the load equipment are increased in traditional active health monitoring are solved, the pressure of the server and the load equipment can be effectively relieved, the load equipment can find the faults of the server in time, and the risk of network abnormity is reduced.

Description

Technical Field

[0001] The present disclosure relates to the field of computer information processing, and in particular to a health monitoring method and device for a server. Background Art

[0002] Health check is a technology used to monitor network failures. It is usually configured on network devices to detect and respond to link failures in the network. For example, load balancing devices will redistribute network traffic based on health monitoring results to ensure that traffic is sent to normal links to avoid network outages caused by sending traffic to faulty links.

[0003] With the rapid development of the network, the number of services continues to increase, and the scale of health monitoring traffic has also increased dramatically, bringing a lot of additional burden to servers and load devices, affecting the overall performance of the system.

[0004] In the prior art, the device will continuously send detection messages, such as ICMP or TCP messages, to the IP address (server_ip) of the target server. The interval of sending the detection message is usually configurable. If a response message is received from the server within the predetermined time, the server status is considered normal; otherwise, the server is considered unavailable.

[0005] In the existing technology, active health monitoring will increase the load on the server and load balancing equipment, and this burden will become more obvious as the business volume grows, which may cause high concurrency problems for the equipment even when there is no business traffic. Moreover, due to the fixed monitoring interval, active health monitoring cannot detect server failures in time. If a server fails briefly, active monitoring cannot guarantee that it can be accurately captured, which may lead to failure to respond to the problem in time.

[0006] Therefore, a new method and device for server health monitoring is needed.

[0007] The above information disclosed in the Background section is only for enhancement of understanding of the background of the present application and therefore it may contain information that does not constitute the prior art that is already known to a person of ordinary skill in the art. Summary of the invention

[0008] In view of this, the present application provides a health monitoring method and device for a server, which solves the problem that traditional active health monitoring cannot detect faults in time and increases the burden on servers and load devices. It can effectively reduce the pressure on servers and load devices, enable load devices to detect server faults in time, and reduce the risk of network abnormalities.

[0009] Other features and advantages of the present application will become apparent from the following detailed description, or may be learned in part by the practice of the present application.

[0010] According to one aspect of the present application, a health monitoring method for a server is proposed, the method comprising: when the load balancing device obtains traffic data, determining the target server according to a traffic scheduling algorithm; sending a TCP message for establishing a connection to the target server, and recording the message sending time; obtaining a return message from the target server, recording the message return time and the message return type; and performing health monitoring on the target server according to the message sending time, the message return time and the message return type.

[0011] In an exemplary embodiment of the present application, it also includes: when it is determined that the health status of the target server is normal, sending the traffic data to the target server for processing; when it is determined that the health status of the target server is abnormal, marking the target server as invalid.

[0012] In an exemplary embodiment of the present application, it also includes: regularly marking an invalid server as valid, and performing a retest verification to determine the health status of the server.

[0013] In an exemplary embodiment of the present application, a return message from the target server is obtained, and the message return time and the message return type are recorded, including: when the return message from the target server is of the SYN+ACK type, the message return time is recorded; when the return message from the target server is not of the SYN+ACK type, the message return time is not recorded.

[0014] In an exemplary embodiment of the present application, the health monitoring of the target server is performed according to the message sending time, the message return time and the message return type, including: updating the failure count corresponding to the target server according to the message sending time, the message return time and the message return type; when the failure count is less than a threshold, determining that the health status of the target server is normal; when the failure count is greater than or equal to a threshold, determining that the health status of the target server is abnormal.

[0015] In an exemplary embodiment of the present application, the failure count corresponding to the target server is updated according to the message sending time, the message return time and the message return type, including: when the return type of the message is not a SYN+ACK type, the failure count corresponding to the target server is increased by 1; when there is no return message, the failure count corresponding to the target server is increased by 1; when the return type of the message is a SYN+ACK type and the difference between the message return time and the message sending time is greater than a time threshold, the failure count corresponding to the target server is increased by 1.

[0016] In an exemplary embodiment of the present application, updating the failure count corresponding to the target server according to the message sending time, the message return time and the message return type also includes: regularly clearing the failure count corresponding to the target server.

[0017] In an exemplary embodiment of the present application, a retest verification is performed to determine the health status of the server, including: sending a TCP message for establishing a connection to the server undergoing the retest verification, and recording the message sending time; obtaining a return message from the server undergoing the retest verification, recording the message return time and the message return type; and performing health monitoring on the server undergoing the retest verification according to the message sending time, the message return time and the message return type.

[0018] In an exemplary embodiment of the present application, health monitoring is performed on the server for retest verification according to the message sending time, the message return time and the message return type, including: updating the failure count corresponding to the server for retest verification according to the message sending time, the message return time and the message return type; when the failure count is 0, resetting the server to valid; when the failure count is 1, continuing to set the server to invalid.

[0019] According to one aspect of the present application, a health monitoring device for a server is proposed, and the device includes: a scheduling module, which is used for the load balancing device to determine the target server according to the traffic scheduling algorithm when obtaining the traffic data; a sending module, which is used to send a TCP message for establishing a connection to the target server and record the message sending time; a return module, which is used to obtain the return message of the target server and record the message return time and the message return type; a monitoring module, which is used to perform health monitoring on the target server according to the message sending time, the message return time and the message return type.

[0020] According to one aspect of the present application, an electronic device is proposed, which includes: one or more processors; a storage device for storing one or more programs; when the one or more programs are executed by the one or more processors, the one or more processors implement the method as described above.

[0021] According to one aspect of the present application, a computer-readable medium is provided, on which a computer program is stored. When the program is executed by a processor, the method described above is implemented.

[0022] According to the server health monitoring method and device of the present application, when the load balancing device obtains traffic data, the target server is determined according to the traffic scheduling algorithm; a TCP message for establishing a connection is sent to the target server, and the message sending time is recorded; a return message from the target server is obtained, and the message return time and the message return type are recorded; and the health of the target server is monitored according to the message sending time, the message return time and the message return type. This solves the problem that traditional active health monitoring cannot detect faults in time and increases the burden on servers and load devices, can effectively reduce the pressure on servers and load devices, enable load devices to detect server faults in time, and reduce the risk of network abnormalities.

[0023] It should be understood that the foregoing general description and the following detailed description are exemplary only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] The above and other objects, features and advantages of the present application will become more apparent by describing in detail the exemplary embodiments thereof with reference to the accompanying drawings. The accompanying drawings described below are only some embodiments of the present application, and it is clear to a person skilled in the art that other accompanying drawings can be obtained from these accompanying drawings without creative effort.

[0025] Figure 1 The present invention is a system block diagram showing a method and device for health monitoring of a server according to an exemplary embodiment.

[0026] Figure 2 The figure is a flow chart of a method for health monitoring of a server according to an exemplary embodiment.

[0027] Figure 3 The figure is a flow chart of a method for health monitoring of a server according to another exemplary embodiment.

[0028] Figure 4 The figure is a flow chart of a method for health monitoring of a server according to another exemplary embodiment.

[0029] Figure 5The figure is a block diagram showing a health monitoring device for a server according to an exemplary embodiment.

[0030] Figure 6 It is a block diagram of an electronic device according to an exemplary embodiment.

[0031] Figure 7 It is a block diagram of a computer-readable medium according to an exemplary embodiment. DETAILED DESCRIPTION

[0032] Example embodiments will now be described more fully with reference to the accompanying drawings. However, example embodiments can be implemented in many forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this application will be comprehensive and complete and will fully convey the concepts of the example embodiments to those skilled in the art. The same reference numerals in the figures represent the same or similar parts, and thus their repeated description will be omitted.

[0033] In addition, described feature, structure or characteristic can be combined in one or more embodiments in any suitable manner. In the following description, many specific details are provided to provide a full understanding of the embodiments of the present application. However, those skilled in the art will appreciate that the technical scheme of the present application can be put into practice without one or more of the specific details, or other methods, components, devices, steps, etc. can be adopted. In other cases, known methods, devices, realizations or operations are not shown or described in detail to avoid blurring the various aspects of the application.

[0034] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities may be implemented in software form, or in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.

[0035] The flowcharts shown in the accompanying drawings are only exemplary and do not necessarily include all the contents and operations / steps, nor must they be executed in the order described. For example, some operations / steps can be decomposed, and some operations / steps can be combined or partially combined, so the actual execution order may change according to actual conditions.

[0036] It should be understood that although the terms first, second, third, etc. may be used herein to describe various components, these components should not be limited by these terms. These terms are used to distinguish one component from another component. Therefore, the first component discussed below can be referred to as the second component without departing from the teachings of the concepts of the present application. As used herein, the term "and / or" includes any one of the associated listed items and all combinations of one or more.

[0037] Those skilled in the art will appreciate that the drawings are merely schematic diagrams of example embodiments, and the modules or processes in the drawings are not necessarily necessary for implementing the present application, and therefore cannot be used to limit the scope of protection of the present application.

[0038] The technical abbreviations involved in this application are explained as follows:

[0039] Passive health monitoring does not actively send detection messages, but uses normal connection conditions or responses to business requests as indicators to measure the health status of the inspected object.

[0040] TCP protocol, Transmission Control Protocol (Transmission Control Protocol) is a connection-oriented, reliable, byte stream-based transport layer communication protocol defined by IETF's RFC 793. TCP is designed to adapt to a layered protocol hierarchy that supports multi-network applications. Pairs of processes in host computers connected to different but interconnected computer communication networks rely on TCP to provide reliable communication services. TCP assumes that it can obtain simple, possibly unreliable datagram services from lower-level protocols. In principle, TCP should be able to operate on a variety of communication systems from hard-wired connections to packet switching or circuit switching networks.

[0041] Response time: the time interval between the device sending a packet and the server responding.

[0042] Failure interval means that if the system reaches the specified number of failures within this period of time, the server is considered unavailable.

[0043] Number of failures: The number of failures allowed within the failure interval.

[0044] Retry time, the waiting time after marking the server as unavailable. After the waiting time is reached, an attempt will be made to mark the server as available again.

[0045] Figure 1 The present invention is a system block diagram showing a method and device for health monitoring of a server according to an exemplary embodiment.

[0046] like Figure 1 As shown, the system architecture 10 may include servers 101, 102, 103, a network 104, and a load balancing device 105. The network 104 is used to provide a medium for communication links between the servers 101, 102, 103 and the load balancing device 105. The network 104 may include various connection types, such as wired, wireless communication links, or optical fiber cables, etc.

[0047] After receiving the traffic data, the load balancing device 105 sends the traffic data to the servers 101, 102, and 103 for processing through the network 104. The servers 101, 102, and 103 may host various data processing applications, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, and social platform software.

[0048] For example, when the load balancing device 105 obtains the traffic data, it can determine the target server (server 101, or server 102, or server 103) according to the traffic scheduling algorithm; the load balancing device 105 can, for example, send a TCP message for establishing a connection to the target server, and record the message sending time; the load balancing device 105 can, for example, obtain the return message of the target server, record the message return time and the message return type; the load balancing device 105 can, for example, perform health monitoring on the target server according to the message sending time, the message return time and the message return type.

[0049] The load balancing device 105 may also, for example, send the traffic data to the target server for processing when determining that the health status of the target server is normal;

[0050] The load balancing device 105 may also mark the target server as invalid, for example, when determining that the health status of the target server is abnormal.

[0051] The load balancing device 105 may also, for example, periodically mark an invalid server as valid, and perform a retest verification to determine the health status of the server.

[0052] It should be noted that the health monitoring method for a server provided in the embodiment of the present application can be executed by the load balancing device 105 , and accordingly, the health monitoring device for a server can be set in the load balancing device 105 .

[0053] Figure 2 The flowchart of a method for monitoring the health of a server according to an exemplary embodiment is shown in FIG. 20. The method 20 for monitoring the health of a server includes at least steps S202 to S208.

[0054] like Figure 2 As shown, in S202, when the load balancing device obtains the traffic data, it determines the target server according to the traffic scheduling algorithm.

[0055] In actual applications, when a load balancing device receives traffic data, it will select a suitable target server based on a traffic scheduling algorithm. The scheduling algorithm can be based on a load balancing strategy, such as the minimum number of connections, round-robin, or weighted random selection, to ensure that network traffic is reasonably distributed to different servers.

[0056] In S204, a TCP message for establishing a connection is sent to the target server, and the message sending time is recorded. The load balancing device sends a TCP message (such as a SYN message) for establishing a connection to the selected target server, and records the sending time T1 of the message. The purpose of sending a TCP message is to verify the health status of the server through the TCP three-way handshake mechanism.

[0057] In S206, the return message of the target server is obtained, and the message return time and message return type are recorded. More specifically, when the return message of the target server is of SYN+ACK type, the message return time is recorded; when the return message of the target server is not of SYN+ACK type, the message return time is not recorded.

[0058] More specifically, the load balancing device receives the return message from the target server and records the time T2 of the return message and the type of the returned message. If the returned message is a SYN+ACK message, the return time T2 is recorded, indicating that the first step of establishing the connection is successful. If the return message is not of the SYN+ACK type (such as an RST message), the return time is not recorded, indicating that the server failed to respond successfully.

[0059] In S208, the health status of the target server is monitored according to the message sending time, the message return time and the message return type. For example, the failure count corresponding to the target server is updated according to the message sending time, the message return time and the message return type; when the failure count is less than a threshold, the health status of the target server is determined to be normal; when the failure count is greater than or equal to the threshold, the health status of the target server is determined to be abnormal.

[0060] More specifically, when the return type of the message is not the SYN+ACK type, the failure count corresponding to the target server increases by 1; when there is no return message, the failure count corresponding to the target server increases by 1; when the return type of the message is the SYN+ACK type, and the difference between the message return time and the message sending time is greater than the time threshold, the failure count corresponding to the target server increases by 1.

[0061] In actual situations, the load balancing device monitors the health of the target server based on the sending time T1, the return time T2, and the type of the returned message. The specific process is as follows:

[0062] The response time difference (T2-T1) is calculated based on T1 and T2, and the response speed of the server is determined based on the difference.

[0063] Update the target server's failure count:

[0064] If the returned message type is not SYN+ACK, the failure count increases by 1;

[0065] If the server does not return a message, the failure count increases by 1;

[0066] If a SYN+ACK message is returned but the response time exceeds the preset time threshold, 1 is also added.

[0067] In one embodiment, the method further includes: regularly clearing the failure count corresponding to the target server. A timer is set to periodically clear the failure count of the target server to prevent a temporary failure in a short period of time from affecting the long-term health of the server. This can prevent the server from being continuously marked as abnormal due to occasional network delays or short-term server problems.

[0068] In one embodiment, it also includes: when it is determined that the health status of the target server is normal, sending the traffic data to the target server for processing; when the failure count of the target server is lower than a preset threshold, the server health status is determined to be normal, and the load balancing device sends the traffic data to the server for processing.

[0069] In one embodiment, the method further includes: when determining that the health status of the target server is abnormal, marking the target server as invalid. When the failure count reaches or exceeds a threshold, the server health status is determined to be abnormal, and the load balancing device marks the server as invalid and stops sending traffic to the server until its health status returns to normal.

[0070] According to the server health monitoring method of the present application, when the load balancing device obtains traffic data, the target server is determined according to the traffic scheduling algorithm; a TCP message for establishing a connection is sent to the target server, and the message sending time is recorded; a return message from the target server is obtained, and the message return time and the message return type are recorded; and the health monitoring of the target server is performed according to the message sending time, the message return time and the message return type. This solves the problem that traditional active health monitoring cannot detect faults in time and increases the burden on servers and load devices, can effectively reduce the pressure on servers and load devices, enables load devices to detect server faults in time, and reduces the risk of network abnormalities.

[0071] It should be clearly understood that the present application describes how to form and use specific examples, but the principles of the present application are not limited to any details of these examples. On the contrary, based on the teaching of the content disclosed in the present application, these principles can be applied to many other embodiments.

[0072] In one embodiment, the process further includes: marking invalid servers as valid at regular intervals, and performing retest verification to determine the health status of the servers. The specific processing steps are as follows: Figure 3 shown. Figure 3 The process 30 shown is for Figure 2 Supplementary description of the process shown.

[0073] like Figure 3 As shown, in S302, the invalid server is marked as valid at a fixed time.

[0074] In S304, a TCP message for establishing a connection is sent to the server for retest verification, and the message sending time is recorded. The load balancing device sends a TCP message (such as a SYN message) for establishing a connection to the server that needs to be retested, and records the sending time T1.

[0075] In S306, a return message from the server of the retest verification is obtained, and the message return time and message return type are recorded.

[0076] The load balancing device receives the return message from the retry server and records the return time T2 and the type of the return message. The types of return messages include SYN+ACK (indicating a successful connection) or other types (such as RST messages, indicating a connection failure). If the server returns a SYN+ACK message, it means that the server has recovered its response capability and is capable of processing requests; if it returns other messages or no response, it means that the server is still faulty.

[0077] In S308, health monitoring is performed on the server of the retest verification according to the message sending time, the message return time and the message return type.

[0078] More specifically, the failure count corresponding to the server for retest verification can be updated according to the message sending time, the message return time and the message return type; when the failure count is 0, the server is set to valid again; when the failure count is 1, the server continues to be set to invalid.

[0079] The load balancing device evaluates the health status of the server based on the message sending time T1, return time T2, and return message type: by calculating the difference between the message return time and the sending time (T2-T1), it determines whether the server's response time is within the acceptable threshold. This process can help identify the server's response speed and ensure that it can process requests in a timely manner.

[0080] Update the server failure count based on the type of the returned message. If SYN+ACK is returned and the response time is within the threshold, it means that the server status is normal; otherwise, increase the server failure count.

[0081] More specific health monitoring steps include:

[0082] When the failure count is 0: If the server returns a SYN+ACK message during the retry process and the response time is within the predetermined threshold, it means that the server health status has returned to normal. At this time, the server's failure count is reset to 0 and reset to "valid", allowing traffic to be distributed to the server again.

[0083] When the failure count is 1: If the server returns an abnormal message (such as RST) or does not return any message within the specified time during the retry process, or even if it returns SYN+ACK but the response time exceeds the threshold, the server's failure count increases to 1. At this time, the server will continue to remain in the "invalid" state and cannot process traffic, and the load balancing device will not send new requests to the server.

[0084] In this application, the health status of the server is dynamically adjusted through the retest verification mechanism, and the server is promptly included in the normal traffic distribution range after the failure is restored, while ensuring that the server that is still in a failed state will not participate in traffic processing. This method effectively improves the stability of the system, avoids the impact of short-term failures on the overall performance of the system, and ensures the rationality of network traffic distribution.

[0085] Figure 4 The figure is a flow chart of a method for health monitoring of a server according to another exemplary embodiment. Figure 4 The process 40 shown is for Figure 2 Detailed description of S102 "" in the process shown.

[0086] like Figure 4 As shown, in S402, traffic access: After the load device obtains the traffic, it selects the real service according to the health monitoring result and the scheduling algorithm.

[0087] In S404, the server is in a valid state. In this application, passive health monitoring will not actively access the real service to obtain the status. The real service configured with passive health monitoring has a valid initial state by default. If no traffic passes through the server at this time, the state remains unchanged. Once traffic is forwarded here, the real service response device's TCP message handshake is judged to be successful or the response time is timed out to judge the status of the real service at this time.

[0088] In S406, a TCP message is sent and the time is recorded. After selecting the real service, the load balancing device sends a TCP message to the selected real service to establish a connection, checks whether the real service is configured with passive health monitoring according to its configuration, and records the time T1 when the TCP SYN message is sent if passive health monitoring is configured.

[0089] In S408, whether the server returns a message. If the server replies with a message, the message type needs to be determined.

[0090] In S410, whether it is a SYN+ACK packet. In the normal TCP three-way handshake process, the server only needs to reply with a SYN+ACK message, so if the message type is SYN+ACK, it means that the server has replied normally, and the time T2 at this time is recorded, and the difference between T2 and T1 (T2-T1) is calculated to determine whether the response time is exceeded. If the response time is exceeded, a failure count is recorded for the server; if the message type is RST or other abnormal messages, a failure count is recorded for the server.

[0091] In S412, whether it is within the time threshold. If the server does not reply to the message, the session enters the aging process and a failure count is recorded for the server.

[0092] In S414, normal processing is performed.

[0093] In S416, the failure count is incremented by 1.

[0094] In S418, whether the threshold is reached in this cycle. When recording the failure count, it is determined whether the failure count in the failure interval reaches the configured number of failures. If it exceeds, the server is marked as unavailable and enters the retry time. When the retry time is configured to 0, the server will be permanently marked as unavailable; if it does not exceed, the state will not be changed, and the failure count will be reset after the next time interval.

[0095] In S420, the server is marked as invalid and retried at regular intervals. When the retry time is reached, the server will be temporarily marked as available, and then it will be determined whether the server has recovered. The configuration of the number of failures in this stage will be invalid. If a failure occurs within this time period, it is considered that the server has not recovered. That is, if there is no failure count in the first failure interval after the retry time, the server will be marked as available again; if there is a failure count, the server will continue to be marked as unavailable and re-enter the retry time.

[0096] In S422, whether the failure count is 1. The failure interval is calculated from the first failure count. Each time a new failure count is added, it is determined whether the time interval between the current time and the first failure exceeds the failure interval. If not, the failure count is increased by 1, and then it is determined whether the configured number of failures is exceeded. If it exceeds the failure interval, it means that it is a new failure interval, the count will be reset, and the failure count time will be used as the initial time of the failure interval.

[0097] In this application, the health status of the inspection object is measured by the status and response time of the TCP connection, and the load device does not need to send a health monitoring detection message at intervals. This solves the problem that traditional active health monitoring cannot detect faults in time and will cause additional burden on the load and server, reduces the burden on the server and load devices, and enables the load to detect server faults in time, reducing the risk of network abnormalities.

[0098] Those skilled in the art will appreciate that all or part of the steps for implementing the above embodiments are implemented as a computer program executed by a CPU. When the computer program is executed by the CPU, the above functions defined by the above method provided in the present application are executed. The program may be stored in a computer-readable storage medium, which may be a read-only memory, a disk, or an optical disk, etc.

[0099] In addition, it should be noted that the above figures are only schematic illustrations of the processes included in the method according to the exemplary embodiments of the present application, and are not intended to be limiting. It is easy to understand that the processes shown in the above figures do not indicate or limit the time sequence of these processes. In addition, it is also easy to understand that these processes can be performed synchronously or asynchronously, for example, in multiple modules.

[0100] The following are device embodiments of the present application, which can be used to execute the method embodiments of the present application. For details not disclosed in the device embodiments of the present application, please refer to the method embodiments of the present application.

[0101] Figure 5 FIG. 1 is a block diagram of a health monitoring device for a server according to an exemplary embodiment. Figure 5 As shown, the health monitoring device 50 for a server includes: a scheduling module 502 , a sending module 504 , a returning module 506 , and a monitoring module 508 .

[0102] The scheduling module 502 is used for the load balancing device to determine the target server according to the traffic scheduling algorithm when the load balancing device obtains the traffic data;

[0103] The sending module 504 is used to send a TCP message for establishing a connection to the target server and record the message sending time;

[0104] The return module 506 is used to obtain the return message of the target server and record the message return time and message return type; the return module 506 is also used to record the message return time when the return message of the target server is of SYN+ACK type; when the return message of the target server is not of SYN+ACK type, the message return time is not recorded.

[0105] The monitoring module 508 is used to perform health monitoring on the target server according to the message sending time, the message return time and the message return type. The monitoring module 508 is also used to update the failure count corresponding to the target server according to the message sending time, the message return time and the message return type; when the failure count is less than a threshold, determine that the health status of the target server is normal; when the failure count is greater than or equal to the threshold, determine that the health status of the target server is abnormal.

[0106] According to the health monitoring device for a server of the present application, when the load balancing device obtains traffic data, the target server is determined according to the traffic scheduling algorithm; a TCP message for establishing a connection is sent to the target server, and the message sending time is recorded; a return message from the target server is obtained, and the message return time and the message return type are recorded; and the health monitoring of the target server is performed according to the message sending time, the message return time and the message return type. This solves the problem that traditional active health monitoring cannot detect faults in time and increases the burden on servers and load devices, can effectively reduce the pressure on servers and load devices, enables load devices to detect server faults in time, and reduces the risk of network abnormalities.

[0107] Figure 6 It is a block diagram of an electronic device according to an exemplary embodiment.

[0108] Refer to the following Figure 6 The electronic device 600 according to this embodiment of the present application is described. Figure 6 The electronic device 600 shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0109] like Figure 6 As shown, the electronic device 600 is in the form of a general computing device. The components of the electronic device 600 may include, but are not limited to: at least one processing unit 610, at least one storage unit 620, a bus 630 connecting different system components (including the storage unit 620 and the processing unit 610), a display unit 640, etc.

[0110] The storage unit stores a program code, which can be executed by the processing unit 610, so that the processing unit 610 performs the steps described in this specification according to various exemplary embodiments of the present application. For example, the processing unit 610 can perform the following steps: Figure 2 , Figure 3 , Figure 4 Follow the steps shown in .

[0111] The storage unit 620 may include a readable medium in the form of a volatile storage unit, such as a random access memory unit (RAM) 6201 and / or a cache memory unit 6202 , and may further include a read-only memory unit (ROM) 6203 .

[0112] The storage unit 620 may also include a program / utility 6204 having a set (at least one) of program modules 6205, such program modules 6205 including but not limited to: an operating system, one or more application programs, other program modules and program data, each of which or some combination may include the implementation of a network environment.

[0113] Bus 630 may represent one or more of several types of bus structures, including a memory unit bus or memory unit controller, a peripheral bus, an accelerated graphics port, a processing unit, or a local bus using any of a variety of bus architectures.

[0114] The electronic device 600 may also communicate with one or more external devices 600' (e.g., keyboards, pointing devices, Bluetooth devices, etc.) to enable a user to communicate with the electronic device 600, and / or any device (e.g., routers, modems, etc.) that the electronic device 600 can communicate with one or more other computing devices. Such communication may be performed via an input / output (I / O) interface 650. In addition, the electronic device 600 may also communicate with one or more networks (e.g., a local area network (LAN), a wide area network (WAN), and / or a public network, such as the Internet) via a network adapter 660. The network adapter 660 may communicate with other modules of the electronic device 600 via a bus 630. It should be understood that, although not shown in the figure, other hardware and / or software modules may be used in conjunction with the electronic device 600, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0115] Through the above description of the implementation, it is easy for those skilled in the art to understand that the example implementation described here can be implemented by software, or by combining software with necessary hardware. Figure 7 As shown, the technical solution according to the implementation mode of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, and includes a number of instructions to enable a computing device (which can be a personal computer, a server, or a network device, etc.) to execute the above method according to the implementation mode of the present application.

[0116] The software product may be any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium may be, for example, but not limited to, a system, device or component of electricity, magnetism, light, electromagnetic, infrared, or semiconductor, or any combination thereof. More specific examples (non-exhaustive list) of readable storage media include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof.

[0117] The computer readable storage medium may include a data signal propagated in a baseband or as part of a carrier wave, wherein a readable program code is carried. This propagated data signal may take a variety of forms, including but not limited to an electromagnetic signal, an optical signal, or any suitable combination of the above. The readable storage medium may also be any readable medium other than a readable storage medium, which may send, propagate, or transmit a program for use by an instruction execution system, an apparatus, or a device or used in combination with it. The program code contained on the readable storage medium may be transmitted with any appropriate medium, including but not limited to wireless, wired, optical cable, RF, etc., or any suitable combination of the above.

[0118] Program code for performing the operations of the present application may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, C++, etc., and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user computing device, partially on the user device, as a separate software package, partially on the user computing device and partially on a remote computing device, or entirely on a remote computing device or server. In the case of a remote computing device, the remote computing device may be connected to the user computing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computing device (e.g., using an Internet service provider to connect through the Internet).

[0119] The above-mentioned computer-readable medium carries one or more programs. When the above-mentioned one or more programs are executed by a device, the computer-readable medium realizes the following functions: when the load balancing device obtains traffic data, it determines the target server according to the traffic scheduling algorithm; sends a TCP message for establishing a connection to the target server, and records the message sending time; obtains the return message of the target server, records the message return time and the message return type; and performs health monitoring on the target server according to the message sending time, the message return time and the message return type.

[0120] Those skilled in the art will appreciate that the above modules can be distributed in the device according to the description of the embodiment, or can be changed accordingly and only used in one or more devices different from the embodiment. The modules of the above embodiments can be combined into one module, or further divided into multiple sub-modules.

[0121] Through the description of the above embodiments, it is easy for those skilled in the art to understand that the example embodiments described here can be implemented by software, or by software combined with necessary hardware. Therefore, the technical solution according to the embodiment of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, including several instructions to enable a computing device (which can be a personal computer, a server, a mobile terminal, or a network device, etc.) to execute the method according to the embodiment of the present application.

[0122] The exemplary embodiments of the present application are specifically shown and described above. It should be understood that the present application is not limited to the detailed structures, configurations or implementations described herein; on the contrary, the present application is intended to cover various modifications and equivalent configurations included in the spirit and scope of the appended claims.

Claims

1. A health monitoring method for a server, characterized in that: include: When the load balancing device obtains traffic data, it determines the target server based on the traffic scheduling algorithm; Sending a TCP message for establishing a connection to the target server, and recording the message sending time; Obtain a return message from the target server, and record the message return time and message return type; The health of the target server is monitored according to the message sending time, the message return time and the message return type.

2. The method according to claim 1, characterized in that Also includes: When it is determined that the health status of the target server is normal, sending the traffic data to the target server for processing; When it is determined that the health status of the target server is abnormal, the target server is marked as invalid.

3. The method according to claim 2, characterized in that Also includes: Invalid servers are marked as valid at regular intervals and retested to determine the health status of the servers.

4. The method according to claim 1, characterized in that Obtain the return message of the target server, record the message return time and message return type, including: When the return message from the target server is of SYN+ACK type, record the message return time; When the return message of the target server is not of the SYN+ACK type, the message return time is not recorded.

5. The method according to claim 1, characterized in that Performing health monitoring on the target server according to the message sending time, the message return time and the message return type includes: Update the failure count corresponding to the target server according to the message sending time, the message return time and the message return type; When the failure count is less than a threshold, determining that the health status of the target server is normal; When the failure count is greater than or equal to a threshold, it is determined that the health status of the target server is abnormal.

6. The method according to claim 5, characterized in that Updating the failure count corresponding to the target server according to the message sending time, the message return time and the message return type includes: When the return type of the message is not a SYN+ACK type, the failure count corresponding to the target server increases by 1; When there is no return message, the failure count corresponding to the target server increases by 1; When the return type of the message is a SYN+ACK type, and the difference between the message return time and the message sending time is greater than the time threshold, the failure count corresponding to the target server is increased by 1.

7. The method according to claim 6, characterized in that Updating the failure count corresponding to the target server according to the message sending time, the message return time and the message return type, further comprising: The failure count corresponding to the target server is cleared periodically.

8. The method according to claim 3, characterized in that A retest validation is performed to determine the health status of the server, including: Sending a TCP message for establishing a connection to the server performing the retest verification, and recording the message sending time; Obtain a return message from the server of the retest verification, and record the message return time and message return type; The health monitoring of the server of the retest verification is performed according to the message sending time, the message return time and the message return type.

9. The method according to claim 8, characterized in that Performing health monitoring on the server of the retest verification according to the message sending time, the message return time and the message return type, including: Update the failure count corresponding to the server of the retest verification according to the message sending time, the message return time and the message return type; When the failure count is 0, resetting the server to be valid; When the failure count is 1, the server is continuously set to be invalid.

10. A health monitoring device for a server, characterized in that: include: The scheduling module is used for the load balancing device to determine the target server according to the traffic scheduling algorithm when obtaining the traffic data; A sending module, used to send a TCP message for establishing a connection to the target server, and record the message sending time; A return module, used to obtain the return message of the target server, and record the message return time and message return type; A monitoring module is used to perform health monitoring on the target server according to the message sending time, the message return time and the message return type.

Images