Configuring Health Check

Updated on 2024-12-16 GMT+08:00

View PDF

Health check periodically checks container health status during running of container-deployed components. If health check is not configured, a pod cannot detect application exceptions or automatically restart the application to restore it. This will result in a situation where the pod status is normal but the application in the pod is abnormal.

ServiceStage provides the following health check methods:

Component Liveness Probe: checks whether an application component exists. It is similar to the ps command that checks whether a process exists. If the liveness check of an application component fails, the cluster restarts the application component. If the liveness check is successful, no operation is executed.
Component Service Probe: checks whether an application component is ready to process user requests. It may take a long time for some applications to start before they can provide services. This is because that they need to load disk data or rely on startup of an external module. In this case, the application process exists, but the application cannot provide services. This check method is useful in this scenario. If the application component readiness check fails, the cluster masks all requests sent to the application component. If the application component readiness check is successful, the application component can be accessed.
Component Startup Probe: checks whether an application has been started. After the control container is successfully started, the system checks the liveness and services to ensure that the liveness and service probes do not affect application startup. This can be used to perform liveness checks on slow starting containers to prevent them from getting terminated before they are started.

Health Check Modes

HTTP request-based check
This health check mode is applicable to application components that provide HTTP/HTTPS services. The cluster periodically sends an HTTP/HTTPS GET request to such application components. If the return code of the HTTP/HTTPS response is within 200–399, the check is successful. Otherwise, the check fails. In this health check mode, you must specify an application listening port and an HTTP/HTTPS request path.

For example, if the application component provides the HTTP service, the port number is 80, the HTTP check path is /health-check, and the host address is containerIP, the cluster periodically initiates the following request to the application:
```
GET http://containerIP:80/health-check
```
NOTE:

If the host address is not set, the instance IP address is used by default.
TCP port-based check
For applications that provide a TCP communication service, the cluster periodically establishes a TCP connection to the application. If the connection is successful, the probe is successful. Otherwise, the probe fails. In this health check mode, you must specify an application listening port. For example, if you have a Nginx application component with service port 80, after you configure a TCP port-based check for the application component and specify port 80 for the check, the cluster periodically establishes a TCP connection with port 80 of the application component. If the connection is successful, the check is successful. Otherwise, the check fails.
CLI-based check
In this mode, you must specify an executable command in an application component. The cluster will periodically execute the command in the application component. If the command output is 0, the health check is successful. Otherwise, the health check fails.

The CLI mode can be used to replace the following modes:
- TCP port-based check: Write a program script to connect to an application component port. If the connection is successful, the script returns 0. Otherwise, the script returns –1.
- HTTP request-based check: Write a program script to run the wget command for an application component.
  wget http://127.0.0.1:80/health-check
  
  Check the return code of the response. If the return code is within 200–399, the script returns 0. Otherwise, the script returns –1.
  NOTICE:
  - Put the program to be executed in the application component image so that the program can be executed.
  - If the command to be executed is a shell script, add a script interpreter instead of specifying the script as the command. For example, if the script is /data/scripts/health_check.sh, you must specify sh/data/scripts/health_check.sh for command execution. The reason is that the cluster is not in the terminal environment when executing programs in an application component.

Common Parameter Description

**Table 1** Common parameter description
Parameter	Description
Latency (s)	Check delay time. Unit: second. Set this parameter according to the normal startup time of services. For example, if this parameter is set to 30, the health check will be started 30 seconds after the application starts. The time is reserved for containerized services to start.
Timeout Period (s)	Timeout duration. Unit: second. If the time exceeds this value, the health check fails. For example, setting this parameter to 10 indicates that the health check timeout period is 10s. If the parameter is left blank or set to 0, the default timeout time is 1s.

Configuring Health Check

Choose Container Settings.
Click Health Check, and set health check parameters based on service requirements.

For details about common parameters, see Table 1.

Parent topic: Managing Container Settings of a Container-Deployed Component

Previous topic: Configuring a Log Policy of an Application

Next topic: Managing Application Settings of a Container-Deployed Component

Feedback

Was this page helpful?

Helpful Not helpful

Provide feedback

Thank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.

The system is busy. Please try again later.

Which of the following issues have you encountered?

Content is inconsistent with the product UI

Unclear descriptions

Lack of examples or code

Incorrect steps

Can't find what I need

Lack of best practices

Feedback (optional)

0/500

Select at least one type of issue, and enter your comments or suggestions.

Enter a maximum of 500 characters.

Submit Cancel

For any further questions, feel free to contact us through the chatbot.

Chatbot