Health Check Concepts

Overview

A health checker polls instances at specified intervals. Instances that do not respond successfully to a specified number of consecutive probes are marked as UNHEALTHY. No new connections are sent to such instances, though existing connections are allowed to continue. The health checker continues to poll unhealthy instances. If an instance later responds successfully to a specified number of consecutive probes, it is marked HEALTHY again and can receive new connections.

Supported protocols

Newer-style health checks support the following protocols:

HTTP, HTTPS, and HTTP/2 health checks

If traffic from the load balancer to your instances uses the HTTP, HTTPS, or HTTP/2 protocol, then HTTP, HTTPS, and HTTP/2 health checks verify that the instance is healthy and the web server is up and serving traffic.

For an HTTP(S) or HTTP/2 health check probe to be deemed successful, the instance must return a valid HTTP response with code 200 and close the connection normally within the configured period. If it does this a specified number of times in a row, the health check returns a status of HEALTHY for that instance. If an instance fails a specified number of health check probes in a row, it is marked UNHEALTHY without any notification being sent. UNHEALTHY instances do not receive new connections, but existing connections are allowed to continue. UNHEALTHY instances continue to receive health check probes. If an instance later passes a health check by successfully responding to a specified number of consecutive health check probes, it is marked HEALTHY and starts receiving new connections, again without any notification.

An HTTP(S) or HTTP/2 health check probe can either check the status code or the content of the response.

The status code check is the default health check. The health checker send an HTTP, HTTPS, or HTTP/2 probe to the configured request path, then checks the status code of the health check response. If the status code of the response is 200 ("OK"), the instance passes that round of the probe.

In a content-based HTTP(S) or HTTP/2 health check, the health checker first checks the status code returned. After checking the status code, the health checker checks the content of the health check response to see whether the string you specify in the --response field is found in anywhere in the first 1024 characters of the body of the response to the health check probe.

The following conditions apply:

  • The response string must consist of alphanumeric ASCII and spaces.

  • Content-based health checks do not support wildcard matching.

  • Content-based health checks do not support inversion, for example, the ! operator of HAProxy.

For more information on HTTP(S) health checks, see the documentation for gcloud beta compute health-checks create.

TCP and SSL health checks

TCP and SSL health checks can be used when the service expects a TCP or SSL connection that is not HTTP(S) or HTTP/2. When you configure the health check to be of type SSL, an SSL connection is used to connect to the instances. When you configure the health check to be of type TCP, a TCP connection is used. An instance passes the health check if a specified number of probes in a row are successful, and it fails the health check if a specified number of probes in a row are unsuccessful.

Existing connections are allowed to continue on instances that have failed their health check. A TCP or SSL health check probe can use one of the following checks:

  • Simple handshake (default): The health checker attempts only a simple TCP or SSL handshake. If it is successful, the instance passes that round of the probe.
  • Request/response: You provide a request string for the health checker to send after completing the TCP or SSL handshake. If the instance returns the response string you've configured, the instance passes that round of the probe. Both the request and response strings can be up to 1024 bytes.

Existing connections are allowed to continue on instances that have failed their health check. A TCP or SSL health check probe can use a simple handshake or a request/response health check.

The simple handshake is the default health check. The health checker attempts only a simple TCP or SSL handshake. If it is successful, the instance passes that round of the probe.

In a request/response health check, you provide a request string for the health checker to send after completing the TCP or SSL handshake. If the instance returns the response string you configured in the --response field, the instance passes that round of the probe. Both the request and response strings can be up to 1024 bytes. The --response field must match the first 1024 bytes of response from the VM.

Note that if the response is not received exactly, the health check probe fails. If --response is configured, but --request is not configured, the health checker still waits for a response. Unless your system automatically sends out a message in response to a successful handshake, configure --response only to match an explicit --request.

For more information on TCP and SSL health checks, see the documentation for gcloud compute health-checks create.

Content-based (request/response) health checks example

HTTP(S), TCP, and SSL health checks can be content-based (request/response), in which an instance is configured to respond to a health check probe with text that you specify. The following graphics illustrate this type of health check.

In the first graphic, the health check responses contains the expected text, "Everything OK," so this health check probe passes. The instance is marked healthy.

Health check probe receives the expected response. (click to enlarge)
Health check probe receives the expected response. (click to enlarge)

In the second graphic, the content of the response, "Looks like we are having problems," does not match the expected text, "Everything OK," so this probe does not pass. The instance is marked unhealthy.

Health check probe does not receive the expected response. (click to enlarge)
Health check probe does not receive the expected response. (click to enlarge)

A network administrator fixes the failing health check by updating the response served by the unhealthy instance.

Updating the response served (click to enlarge)
Updating the response served (click to enlarge)

In the last graphic, both instances are marked healthy because they are both serving the content expected by the configured health check.

Instances are marked healthy (click to enlarge)
Instances are marked healthy (click to enlarge)

Health check frequency

To ensure high availability, GCP creates redundant copies of each health checker. These redundant health checkers also probe your instances. If any health checker fails, a redundant one can take over with no delay.

If you examine the logs on your instance, you might see health check polling happening more frequently than than you have configured. This is because the redundant health checkers are also following your settings. These redundant health checkers are created automatically and are not separately user configurable.

What's next

For information on configuring health checks, see Adding Health Checks.

Was this page helpful? Let us know how we did:

Send feedback about...

Load Balancing