After you deploy an application in SAE, you can use the health check feature to check the running statuses of your application instances and identify faults. This topic describes how to configure application health checks in the SAE console.
Background information
In a health check, a liveness probe or a readiness probe regularly checks application instances and applications, and sends the check results to the SAE console. This helps you understand the running status of the entire service in the cluster environment and identify problems.
SAE provides the following health check methods based on Kubernetes:
Application Instance Liveness Check (Liveness Configuration): checks whether a single application instance is started.
Successful: The application instance is healthy and no operation is required in the SAE console.
Failed: The application instance is unhealthy. SAE restarts the application instance.
Application Business Readiness Check (Readiness Configuration): checks the health status of the application business and checks whether the application that processes customer requests is ready.
Successful: The application is ready. SAE assigns business traffic to the application to process requests.
Failed: The application is not ready. SAE reports an application exception and does not assign business traffic to the application.
Description of health check results:
A successful health check indicates that the application passes the health check and the health check is not performed again.
If the health check fails, SAE performs the health check again at the interval that you specify. If the health check fails for three times in a row, SAE restarts the application instance or stops assigning business traffic to the application.
Scenarios
Disk data is loaded when an application starts.
An application takes a long time to start due to dependent external modules.
Procedure
Configure health checks during application creation
Log on to the SAE console.
In the left-side navigation pane, click Applications. In the top navigation bar, select a region. Then, click Create Application.
In the Basic Information step, configure the parameters and click Next: Application Deployment Configurations.
In the Deployment Configurations step, configure the Technology Stack Programming Language and Application Deployment Method parameters and the corresponding settings.
In the Application Health Check section, select a Method and set the parameters.
NoteThe parameters of Application Instance Liveness Check and Application Business Readiness Check are the same.
You can configure either Application Instance Liveness Check (Liveness Configuration) or Application Business Readiness Check (Readiness Configuration). We recommend that you set both checks. If you set both checks, SAE performs health checks based on the latency that you specify.
HTTP Request Check: checks the health status of an instance by sending an HTTP request to the instance. If the HTTP status code that is returned for the HTTP request is 200 or larger but smaller than or equal to 399, the access succeeds and the instance is healthy. Otherwise, the access fails and the instance is unhealthy.
The following table describes the parameters that you must specify for an HTTP request check.
Parameter
Description
Path
The URL that is used to send the HTTP request.
Port
The port that is used to send the HTTP request.
Advanced Settings
Specifies whether the returned string must contain the keyword that you enter.
Protocol
Valid values: HTTP and HTTPS.
Latency (Seconds)
The health check latency. Unit: seconds. Default value: 10. If you set this parameter to 5, the health check starts 5 seconds after the instance is started.
NoteIf the application startup takes 60 seconds, we recommend that you set the Latency (Seconds) parameter to 70.
Timeout Period (Seconds)
The health check timeout period. Unit: seconds. Default value: 1. If you set this parameter to 10, the health check fails after a timeout period of 10 seconds, and a timeout message is reported. If you set this parameter to 0 or leave this parameter empty, the default value 1 is used.
Check Interval (Seconds)
The health check interval. Unit: seconds. Default value: 30. If you set this parameter to 5, the health check is performed every 5 seconds.
TCP Port Check: checks the health status of an instance by sending a TCP socket to the instance. If the TCP connection is established, the instance is healthy. If the TCP connection fails to be established, the instance is unhealthy.
The following table describes the parameters that you must specify for a TCP port check.
Parameter
Description
TCP Port
The TCP port that is used to send the TCP socket.
Latency (Seconds)
The health check latency. Unit: seconds. Default value: 10. If you set this parameter to 5, the health check starts 5 seconds after the instance is started.
NoteIf the application startup takes 60 seconds, we recommend that you set the Latency (Seconds) parameter to 70.
Timeout Period (Seconds)
The health check timeout period. Unit: seconds. Default value: 1. If you set this parameter to 10, the health check fails after a timeout period of 10 seconds, and a timeout message is reported. If you set this parameter to 0 or leave this parameter empty, the default value 1 is used.
Check Interval (Seconds)
The health check interval. Unit: seconds. Default value: 30. If you set this parameter to 5, the health check is performed every 5 seconds.
Check by Command Execution: checks the health status of an instance by running the probe detection command on the instance. If the returned status code is 0, the execution succeeds and the instance is healthy. Otherwise, the execution fails and the instance is unhealthy.
The following table describes the parameters that you must specify for a check by command execution.
Parameter
Description
Latency (Seconds)
The health check latency. Unit: seconds. Default value: 10. If you set this parameter to 5, the health check starts 5 seconds after the instance is started.
NoteIf the application startup takes 60 seconds, we recommend that you set the Latency (Seconds) parameter to 70.
Timeout Period (Seconds)
The health check timeout period. Unit: seconds. Default value: 1. If you set this parameter to 10, the health check fails after a timeout period of 10 seconds, and a timeout message is reported. If you set this parameter to 0 or leave this parameter empty, the default value 1 is used.
Check Interval (Seconds)
The health check interval. Unit: seconds. Default value: 30. If you set this parameter to 5, the health check is performed every 5 seconds.
Command
The health check command to be executed on the application instance or process. If the returned code is 0, the application is healthy.
For the command format, see Sample Command Execution in the console. For more information about health check commands, see Configure Liveness, Readiness and Startup Probes on the Kubernetes official website.
NoteEnter the command that you want to run in the first row and enter the parameters from the second row. Set one parameter in a row and do not leave empty rows.
Click Next: Confirm Specifications.
In the Specification Confirmation step, view the details of the application and the fee for the selected specifications. Then, click Confirm.
The Creation Completed step appears. You can click Application Details to go to the Basic Information page of the application.
Verify the results.
On the Applications page, click the Instance Deployment Information tab. In the Default Group section, view the running status of the instance. Move the pointer next to the status to view details.
The following table describes the instance statuses.
Status
Description
Liveness health check not configured
Readiness health check not configured
Liveness and readiness health checks not configured
Indicates that no health check is configured for the instance.
NoteWe recommend that you set both the liveness and readiness health checks.
For more information about the health check configuration, click View Details to view the configuration documentation.
Indicates that the instance is being checked or is waiting for a health check.
NoteAfter an instance is started, the health check starts after the latency that you specify for the health check.
Liveness health check failed
Readiness health check failed
Liveness and readiness health checks failed
Indicates that the health check fails, and the instance is unhealthy.
NoteIf you want to view the cause of the failure, click failed. On the Application Events page that appears, the details of the health check are displayed.
Indicates that the health check succeeds, and the instance is healthy.
Configure health checks during application deployment
After you redeploy an application, the application is restarted. To prevent unpredictable errors such as business interruptions, we recommend that you deploy applications during off-peak hours.
The procedure that can be performed to update an application varies based on the number of instances in the application. This section provides an example on how to configure the required features for an application in which the number of instances is greater than or equal to 1. For information about how to update an application in which the number of instances is 0, see Update an application.
Log on to the SAE console.
In the left-side navigation pane, click Applications. In the top navigation bar, select a region. Then, click the name of an application.
In the upper-right corner of the Basic Information page, click Deploy Application.
In the Application Health Check section, select a Method and set the parameters.
NoteThe parameters of Application Instance Liveness Check and Application Business Readiness Check are the same.
You can configure either Application Instance Liveness Check (Liveness Configuration) or Application Business Readiness Check (Readiness Configuration). We recommend that you set both checks. If you set both checks, SAE performs health checks based on the latency that you specify.
HTTP Request Check: checks the health status of an instance by sending an HTTP request to the instance. If the HTTP status code that is returned for the HTTP request is 200 or larger but smaller than or equal to 399, the access succeeds and the instance is healthy. Otherwise, the access fails and the instance is unhealthy.
The following table describes the parameters that you must specify for an HTTP request check.
Parameter
Description
Path
The URL that is used to send the HTTP request.
Port
The port that is used to send the HTTP request.
Advanced Settings
Specifies whether the returned string must contain the keyword that you enter.
Protocol
Valid values: HTTP and HTTPS.
Latency (Seconds)
The health check latency. Unit: seconds. Default value: 10. If you set this parameter to 5, the health check starts 5 seconds after the instance is started.
NoteIf the application startup takes 60 seconds, we recommend that you set the Latency (Seconds) parameter to 70.
Timeout Period (Seconds)
The health check timeout period. Unit: seconds. Default value: 1. If you set this parameter to 10, the health check fails after a timeout period of 10 seconds, and a timeout message is reported. If you set this parameter to 0 or leave this parameter empty, the default value 1 is used.
Check Interval (Seconds)
The health check interval. Unit: seconds. Default value: 30. If you set this parameter to 5, the health check is performed every 5 seconds.
TCP Port Check: checks the health status of an instance by sending a TCP socket to the instance. If the TCP connection is established, the instance is healthy. If the TCP connection fails to be established, the instance is unhealthy.
The following table describes the parameters that you must specify for a TCP port check.
Parameter
Description
TCP Port
The TCP port that is used to send the TCP socket.
Latency (Seconds)
The health check latency. Unit: seconds. Default value: 10. If you set this parameter to 5, the health check starts 5 seconds after the instance is started.
NoteIf the application startup takes 60 seconds, we recommend that you set the Latency (Seconds) parameter to 70.
Timeout Period (Seconds)
The health check timeout period. Unit: seconds. Default value: 1. If you set this parameter to 10, the health check fails after a timeout period of 10 seconds, and a timeout message is reported. If you set this parameter to 0 or leave this parameter empty, the default value 1 is used.
Check Interval (Seconds)
The health check interval. Unit: seconds. Default value: 30. If you set this parameter to 5, the health check is performed every 5 seconds.
Check by Command Execution: checks the health status of an instance by running the probe detection command on the instance. If the returned status code is 0, the execution succeeds and the instance is healthy. Otherwise, the execution fails and the instance is unhealthy.
The following table describes the parameters that you must specify for a check by command execution.
Parameter
Description
Latency (Seconds)
The health check latency. Unit: seconds. Default value: 10. If you set this parameter to 5, the health check starts 5 seconds after the instance is started.
NoteIf the application startup takes 60 seconds, we recommend that you set the Latency (Seconds) parameter to 70.
Timeout Period (Seconds)
The health check timeout period. Unit: seconds. Default value: 1. If you set this parameter to 10, the health check fails after a timeout period of 10 seconds, and a timeout message is reported. If you set this parameter to 0 or leave this parameter empty, the default value 1 is used.
Check Interval (Seconds)
The health check interval. Unit: seconds. Default value: 30. If you set this parameter to 5, the health check is performed every 5 seconds.
Command
The health check command to be executed on the application instance or process. If the returned code is 0, the application is healthy.
For the command format, see Sample Command Execution in the console. For more information about health check commands, see Configure Liveness, Readiness and Startup Probes on the Kubernetes official website.
NoteEnter the command that you want to run in the first row and enter the parameters from the second row. Set one parameter in a row and do not leave empty rows.
After you configure the settings, click Confirm.
Verify the results.
On the Applications page, click the Instance Deployment Information tab. In the Default Group section, view the running status of the instance. Move the pointer next to the status to view details.
The following table describes the instance statuses.
Status
Description
Liveness health check not configured
Readiness health check not configured
Liveness and readiness health checks not configured
Indicates that no health check is configured for the instance.
NoteWe recommend that you set both the liveness and readiness health checks.
For more information about the health check configuration, click View Details to view the configuration documentation.
Indicates that the instance is being checked or is waiting for a health check.
NoteAfter an instance is started, the health check starts after the latency that you specify for the health check.
Liveness health check failed
Readiness health check failed
Liveness and readiness health checks failed
Indicates that the health check fails, and the instance is unhealthy.
NoteIf you want to view the cause of the failure, click failed. On the Application Events page that appears, the details of the health check are displayed.
Indicates that the health check succeeds, and the instance is healthy.
Troubleshoot errors that occur in the health check configuration process
This section uses the liveness health check as an example to describe how to troubleshoot errors that occur in the health check configuration process.
Delete the liveness health check configurations.
Check whether the application starts as expected.
Check the time that is required to start the application.
If the application startup takes 60 seconds and the Latency (Seconds) that you set is 10, the health check fails. We recommend that you set Latency (Seconds) to 70.
Reconfigure the health check parameters. For more information, see Procedure.