After you deploy an application to SAE, you can use the health check feature to verify that your application is running properly and to identify issues when exceptions occur.SAE supports health check configuration during application creation and deployment. This topic describes how to configure health checks in the SAE console.
Background
How health checks work
A health check uses a liveness, readiness, or startup probe to periodically check an application instance and report the results to the SAE console. This helps you understand the overall health of your service in a cluster environment and locate issues.
SAE is built on Kubernetes and provides the following types of health checks.
-
Liveness probe: Determines if an application instance is running.
-
If the probe succeeds: The application instance is healthy, and SAE takes no action.
-
If the probe fails: The application instance is unhealthy, and SAE restarts the instance.
-
-
Readiness probe: Determines if an application instance is ready to process incoming traffic.
-
If the probe succeeds: The application instance is ready, and SAE allocates traffic to the instance.
-
If the probe fails: The application instance is not ready. SAE reports an exception for the instance and does not allocate traffic to it.
-
-
Startup probe: Determines if an application instance has started successfully.
-
If the probe succeeds: The application instance has started successfully. The liveness and readiness probes, if configured, begin only after the startup probe succeeds.
-
If the probe fails: The application instance has failed to start. SAE reports an exception and automatically restarts the instance.
-
Success and failure criteria
-
Success: A probe succeeds when the number of consecutive successful checks reaches the specified healthy threshold.
-
Failure: If a single health check fails, SAE continues to perform checks at the configured interval. If the number of consecutive failures reaches the specified unhealthy threshold, SAE takes action. For a failed liveness probe, SAE restarts the application instance. For a failed readiness probe, SAE removes the instance from the service endpoint so that it no longer receives traffic.
Health check parameters
SAE uses the following parameters to check the status of applications and application instances.
-
Initial delay
The delay in seconds after an application starts before the first probe begins. This value must be greater than the application's startup time to prevent probe failures and subsequent restarts during deployment.
-
Timeout
The timeout for a single probe, in seconds. The default value is 1. For example, if you set this value to 10, a probe fails if it does not receive a response within 10 seconds. If you set this parameter to 0 or leave it empty, the default timeout of 1 second is used.
-
Period
The interval between health checks, in seconds. The default value is 30. For example, if you set this value to 5, a check is performed every 5 seconds. To accelerate startup, SAE may run the readiness probe more frequently than the configured period immediately after an instance starts, allowing it to receive traffic sooner.
Procedure
-
Create an application
In the SAE application list, select the target region and namespace at the top, and then click Create Application. After you configure the settings on the basic information page, click Next: advanced settings.
Modify a running application
WarningRedeploying an application restarts it. To avoid service interruptions or other unexpected errors, perform deployment operations during off-peak hours.
In the SAE application list, select the target region and namespace at the top, and then click the Application ID of your application to go to its details page. In the left-side navigation pane, click basic information, and then click deploy application in the upper-right corner.
Modify a stopped application
In the SAE application list, select the target region and namespace at the top, and then click the Application ID of your application to go to its details page. Click basic information, and then click Modify Application Configuration.
-
Expand the Application health check settings section and configure the parameters as needed.
Configuration
-
As needed, enable Enable application instance liveness check (Liveness configuration), Enable application readiness probe (Readiness configuration), or Enable startup probe configuration. The configuration parameters are the same for all three probe types.
Note-
You can configure liveness, readiness, and startup probes individually or in any combination. We recommend configuring all three.
-
When all three health checks are configured, the startup probe runs first. The liveness and readiness probes begin only after the startup probe succeeds, each respecting its configured initial delay.
-
-
Select a Check method and configure its parameters.
-
HTTP request check: Checks instance health by sending an HTTP request. The instance is healthy if the status code is between 200 and 399; otherwise, it is unhealthy.
-
TCP port check: Checks instance health by establishing a TCP socket connection. The instance is healthy if the connection succeeds; otherwise, it is unhealthy.
-
Executable command check: Checks instance health by executing a command inside it. The instance is healthy if the command returns an exit code of 0; otherwise, it is unhealthy.
HTTP request
Parameter
Description
Path
The path to access on the HTTP server.
Port
The port to access on the HTTP server.
Advanced settings
Expand advanced settings to configure an optional check that verifies whether the response body contains a specified keyword.
Protocol
Select HTTP or HTTPS.
initial delay (seconds)
The delay in seconds after an application starts before the first probe begins. This value must be greater than the application's startup time to prevent probe failures and subsequent restarts during deployment.
timeout (seconds)
The timeout for a single probe, in seconds. The default value is 1. For example, if you set this value to 10, a probe fails if it does not receive a response within 10 seconds. If you set this parameter to 0 or leave it empty, the default timeout of 1 second is used.
period (seconds)
The interval between health checks, in seconds. The default value is 30. For example, if you set this value to 5, a check is performed every 5 seconds. To accelerate startup, SAE may run the readiness probe more frequently than the configured period immediately after an instance starts, allowing it to receive traffic sooner.
healthy threshold (times)
The minimum number of consecutive successes required for a probe to be considered successful after it has failed. For a liveness probe, this value must be 1.
unhealthy threshold (times)
The number of consecutive failures after which a probe is considered to have failed.
TCP port
Parameter
Description
TCP port
The TCP port to access for the health check.
initial delay (seconds)
The delay in seconds after an application starts before the first probe begins. This value must be greater than the application's startup time to prevent probe failures and subsequent restarts during deployment.
timeout (seconds)
The timeout for a single probe, in seconds. The default value is 1. For example, if you set this value to 10, a probe fails if it does not receive a response within 10 seconds. If you set this parameter to 0 or leave it empty, the default timeout of 1 second is used.
period (seconds)
The interval between health checks, in seconds. The default value is 30. For example, if you set this value to 5, a check is performed every 5 seconds. To accelerate startup, SAE may run the readiness probe more frequently than the configured period immediately after an instance starts, allowing it to receive traffic sooner.
healthy threshold (times)
The minimum number of consecutive successes required for a probe to be considered successful after it has failed. For a liveness probe, this value must be 1.
unhealthy threshold (times)
The number of consecutive failures after which a probe is considered to have failed.
Executable command
Parameter
Description
initial delay (seconds)
The delay in seconds after an application starts before the first probe begins. This value must be greater than the application's startup time to prevent probe failures and subsequent restarts during deployment.
timeout (seconds)
The timeout for a single probe, in seconds. The default value is 1. For example, if you set this value to 10, a probe fails if it does not receive a response within 10 seconds. If you set this parameter to 0 or leave it empty, the default timeout of 1 second is used.
period (seconds)
The interval between health checks, in seconds. The default value is 30. For example, if you set this value to 5, a check is performed every 5 seconds. To accelerate startup, SAE may run the readiness probe more frequently than the configured period immediately after an instance starts, allowing it to receive traffic sooner.
healthy threshold (times)
The minimum number of consecutive successes required for a probe to be considered successful after it has failed. For a liveness probe, this value must be 1.
unhealthy threshold (times)
The number of consecutive failures after which a probe is considered to have failed.
Command
The command to run inside the instance. For more information about probe commands, see Configure Probes in the Kubernetes documentation.
NoteSAE provides two shell interpreters:
-
>_ /bin/sh
-
>_ /bin/bash
Example: The command
cat /tmp/healthyperiodically checks for the existence of the/tmp/healthyfile. The check succeeds (returns 0) if the file exists. -
Verify the results
After configuring health checks, go to the basic information page of the application and click the Instances tab. In the Default Group area, you can view the running status of each instance. Hover over the status icon to view details about the health check configuration.
|
Running status |
Description |
|
Indicates that no health check is configured for the instance. Note
|
|
Liveness and readiness health checks failed The instance status is Running, but a red Health check failed message is displayed. |
Indicates that the health check failed and the instance is unhealthy. Note
Hover over the instance status to view the failure reason. For resolution steps, click Troubleshooting Guide. |
|
Health check passed The instance status is a green Running with no warning messages. |
Indicates that the health check passed and the instance is healthy. |
Common causes for health check failures
-
The initial delay is too short, causing the health check to start before the application is fully initialized. Increase the delay and try again.
-
The health check configuration is incorrect. Verify the port and path.
-
The service is under excessive load. Check the application monitoring data to confirm. If this is the cause, increase the number of instances, use a larger instance type, or decrease the JVM heap size.
-
The application fails to start. Try disabling the health checks to diagnose the problem. If the application still fails to start, you may need to optimize your code.