Health Check Policies
This document introduces the probe methods and their principles within health checks, the origin health determination criteria and the calculation methods.
Note:
Principle of Health Checks
After configuring health check policies, EdgeOne's probe nodes in different regions will send probe requests to your origin and determine the health status of the origin based on the response results. Health check policies consist of probe methods and origin health determination criteria. The probe method determines the type of probe request, while the origin health determination criteria determine how the response results are processed.
Probe Method
Currently, supports for ICMP Ping, HTTP/HTTPS, TCP, and UDP as the four methods of probe. For more details, see The Principle Introduction of Probe Methods. The following are the explanations for the corresponding configuration items:
Probe Method | Applicable Scenario | Configuration Item | Description |
ICMP Ping | Only probes network connectivity, and host reachability. | Probe Frequency | Required, with optional intervals of every 30 seconds, every 60 seconds, every 3 minutes, every 5 minutes, or every 10 minutes. |
HTTP/HTTPS | Applicable for applications that require content recognition in requests, such as web applications and app services. | Probe Frequency | Required, with optional intervals of every 30 seconds, every 60 seconds, every 3 minutes, every 5 minutes, or every 10 minutes. |
| | URL | Required, the full URL for health checks, for example: www.example.com/test. |
| | Probe Port | Required, defaulting to port 80. It is recommended not to modify this unless a specific port needs to be designated. |
| | HTTP Method | Required, the HTTP method for health checks is by default HEAD, with options including GET or HEAD. If the HEAD method is used, the server returns only HTTP header information, which can reduce backend overhead and enhance request efficiency. The corresponding origin service must support HEAD. If the GET method is used, the origin service simply needs to support GET. |
| | HTTP Status Code | Required, the origin is considered healthy when the status code matches the selected status codes. By default, this includes 2XX, with options to select: 1XX, 2XX, 3XX, 4XX, 5XX. |
| | Follow Redirects | Disabled by default. When enabled, the probe node will initiate another probe based on the 301/302 redirect address responded by the origin. It Uses the status code of the final redirection response as the determination result for the health status. Up to 3 redirects are supported. |
| | Custom Request Headers | Optional, custom request headers can be configured to be sent with the health check requests to the origin, with a maximum of 8 configurations allowed, for example: host: www.example.com. |
TCP | Suitable for scenarios where high reliability and data accuracy are essential, but transmission speed is of lesser importance, such as file transfers and remote log-ins. | Probe Frequency | Required, with optional intervals of every 30 seconds, every 60 seconds, every 3 minutes, every 5 minutes, or every 10 minutes. |
| | Probe Port | Required, defaulting to port 80. It is recommended not to modify this unless a specific port needs to be designated. |
UDP | Suitable for scenarios where high transmission efficiency is crucial and a relatively lower level of accuracy is acceptable, such as instant messaging and online video streaming. | Probe Frequency | Required, with optional intervals of every 30 seconds, every 60 seconds, every 3 minutes, every 5 minutes, or every 10 minutes. |
| | Probe Port | Required, defaulting to port 80. It is recommended not to modify this unless a specific port needs to be designated. |
| | Probe Request | Required, customize the content of the health check request, with a limit of 500 characters. |
| | Probe Response Result | Required, customize the content of the health check request, with a limit of 500 characters. |
Origin Health Determination Criteria
Choose any of the probe policies: ICMP Ping, HTTP/HTTPS, TCP, and UDP. Click Show Advanced Configuration to configure origin health determination criteria. The following are the descriptions for each configuration item:
Configuration Item | Description |
Timeout | The allowed timeout duration for a single health check request to the origin. If no response is received within this period, the origin is considered Unhealthy. The default is 5 seconds, with a configurable range of [1, 30] seconds. |
Unhealthy Threshold | The number of consecutive probe failures required to determine an origin Unhealthy. Once this threshold is reached, the origin is considered Unhealthy. The default is 2 times, with a configurable range of [1, 5]. For example, if this value is set to 2, and an origin is initially Healthy, upon receiving two consecutive Unhealthy probe results, the origin will be considered Unhealthy. |
Healthy Threshold | The number of consecutive successful probes required to restore an origin to a Healthy state, making it available again. The default is 3 times, with a configurable range of [1, 5]. For example, if this value is set to 3, and an origin is Unhealthy, after three consecutive Healthy probe results, the origin will be restored to a Healthy status. |
Active Probing Cycle for Origin Health Status Change
For example, suppose the health determination conditions for the origin are set as follows: timeout of 5 seconds, unhealthy threshold of 3 times, healthy threshold of 3 times, and a probe interval of every 30 seconds.
The time required to consider an origin Unhealthy would then be: 5+30+5+30+5=75 seconds.
The time required to restore the origin to a Healthy state (assuming a successful active probe response takes 1 second) would be: 1+30+1+30+1=63 seconds.
More Information
Introduction to Principle of Probe Method
The ICMP Ping health check mechanism is as follows:
1. EdgeOne probe node sends a Ping command to your origin.
2. If the Ping is successful, and within the backsource timeout period, the origin receives an ICMP reply, the service is considered normal, and the result of this check is considered healthy.
3. If the Ping fails, and within the backsource timeout period, the probe node does not receive an ICMP reply from the origin, the service is considered abnormal, and the result of this check is considered unhealthy.
Note:
ICMP Ping requires your origin to support Ping.
The HTTP/HTTPS health check mechanism is as follows:
1. EdgeOne probe node sends an HTTP request to your origin. It requires configuration of the corresponding URL and port, with the option to include a custom HOST header.
2. If, within the backsource timeout period, the EO probe node receives an HTTP status code from the origin that successfully matches the configured HTTP status codes, the result of this check is considered healthy.
3. If, within the backsource timeout period, the EO probe node does not receive a response from the origin or receives a status code that does not match the configured codes, the result of this check is considered unhealthy.
The TCP health check mechanism is as follows:
1. EdgeOne probe node sends a SYN connection request packet to a specific port (configurable) on your origin.
2. Upon receiving the SYN request packet, if the corresponding port on the origin is in a normal listening state, it will respond with a SYN+ACK packet.
3. If, within the backsource timeout period, the probe node receives a SYN+ACK response packet from the origin, it indicates that the service is running normally. The result of this check is considered healthy. The probe node then replies with an ACK packet to the origin and sends an RST reset packet to terminate the TCP connection.
4. If, within the backsource timeout period, the probe node does not receive a SYN+ACK response packet from the origin, it indicates that the service is running abnormally. The result of this check is considered unhealthy. The probe node sends an RST reset packet to the origin to terminate the TCP connection.
The UDP health check mechanism is as follows:
1. EdgeOne probe node sends a customized probe packet to a specific port (configurable) on your origin.
2. If, within the backsource timeout period, the probe node receives a customized response packet from the origin, it indicates that the service is running normally. The result of this check is considered healthy.
3. If, within the backsource timeout period, the probe node does not receive a customized response packet from the origin or receives a response packet that does not conform to the defined content, it indicates that the service is running abnormally. The result of this check is considered unhealthy.
Note:
Both the request content and response content are customized, and you need to configure the corresponding request-response content on your origin.
Probe Request Identification
Active probes do not carry special request identifiers. When you choose ICMP Ping or TCP probes, there are no related features. When you choose UDP probes, customized content can be configured to serve as identifiers. For HTTP/HTTPS probes, separate customized request headers can be configured to serve as identifiers.