tencent cloud

Feedback

Health Check Policies

Last updated: 2024-05-29 10:33:37
    This document introduces the probe methods and their principles within health checks, the origin health determination criteria and the calculation methods.
    Note:
    EdgeOne Load Balancing feature is in beta testing. If you want to use it, you can Contact Us.

    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.

    More Information

    Introduction to Principle of Probe Method

    ICMP Ping
    HTTP/HTTPS
    TCP
    UDP
    
    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.
    
    Contact Us

    Contact our sales team or business advisors to help your business.

    Technical Support

    Open a ticket if you're looking for further assistance. Our Ticket is 7x24 avaliable.

    7x24 Phone Support