Health Check Concepts

Google Cloud Platform (GCP) provides health checking mechanisms that determine if VM instances properly respond to traffic. This document discusses health checking concepts specific to GCP and its load balancers.

Overview

GCP provides health check systems that connect to virtual machine (VM) instances on a configurable, periodic basis. Each connection attempt is called a probe. GCP records the success or failure of each probe.

Health checks and load balancers work together. Based on a configurable number of sequential successful or failed probes, GCP computes an overall health state for each VM in the load balancer. VMs that respond successfully for the configured number of times are considered healthy. VMs that fail to respond successfully for a separate number of times are unhealthy.

GCP uses the overall health state of each VM to determine its eligibility for receiving new requests. In addition to being able to configure probe frequency and health state thresholds, you can configure the criteria that define a successful probe. This document describes how health checks work in detail.

Health check categories, protocols, and ports

GCP organizes health checks by category and protocol.

There are two health check categories: health checks and legacy health checks. Each category supports a different set of protocols and a means for specifying the port used for health checking. The protocol and port determine how GCP health check systems contact your VMs. For example, you can create a health check that uses the HTTP protocol on TCP port 80, or you can create a health check that uses the TCP protocol for a named port configured on an instance group.

Most load balancers use non-legacy health checks, but Network Load Balancing requires that you use legacy health checks. Refer to Selecting a health check for specific guidance on selecting the category and the protocol, and specifying the ports.

You cannot convert a legacy health check to a health check or vice versa.

Selecting a health check

Health checks must be compatible with the type of load balancer and the types of backends (instance groups or network endpoint groups) it uses. The three factors you must specify when you create a health check are:

  • Category: health check or legacy health check, which must be compatible with the load balancer
  • Protocol: defines what protocol the GCP systems use to periodically probe your VMs
  • Port specification: defines which ports are used for the health check's protocol

The guide at the end of this section summaries valid combinations of health check category, protocol, and port specification based on a given type of load balancer and backend type.

Category and protocol

The type of load balancer and the types of backends it uses determine the health check's category. Network Load Balancing requires legacy health checks, but you should use health checks for all other GCP load balancers.

You must select a protocol from the list of protocols supported by the health check's category. It's a best practice to use the same protocol as the load balancer itself; however, this is not a requirement, nor is it always possible. For example, legacy health checks only support the HTTP and HTTPS protocols, though Network Load Balancing supports TCP and UDP in general. For Network Load Balancers, you might have to run an HTTP server on your VMs just so that they can respond to health check probes.

The following table lists the health check categories and the protocols each category supports.

Health check category Supported protocols
Health check • HTTP
• HTTPS
• HTTP/2 (Beta)
• SSL
• TCP
Legacy health check • HTTP
• HTTPS

Category and port specification

In addition to a protocol, you must select a port specification for your health check. Health checks provide three port specification methods, and legacy health checks provide one method. Not all port specification methods are applicable to each type of load balancer. The type of load balancer and the types of backends it uses determine which port specification method you can use.

Health check category Port specification methods and meanings
Health check --port: specify a TCP port number
--port-name: specify any named port set on an instance group
--use-serving-port: for instance groups, use the same named port used by the backend service; for network endpoint groups, use the port defined on each endpoint
Legacy health check --port: specify a TCP port number

Note here and below: The flag --use-serving-port is implemented with gcloud beta compute health-checks create, but not with gcloud beta compute health-checks update.

Load balancer guide

Use this table to choose the correct category and protocol of health check for a given load balancer.

Load balancer Backends Category Port specification
Internal Instance Groups
on a backend service
Health check Port number (--port) or named port (--port-name). You cannot use the --use-serving-port flag because backend services with internal load balancing schemes do not have an associated named port.
Network Instance Groups
using target pools
Legacy health check Legacy health checks only support port specification by port number (--port).
TCP Proxy
SSL Proxy
HTTP(S) 1
Network Endpoint Groups
on a backend service
Health check Port number (--port) or --use-serving-port
Instance Groups
on a backend service
Health check Port number (--port), named port (--port-name), or --use-serving-port

1It is possible, but not recommended, to use a legacy health check for backend services associated with HTTP(S) load balancers under the following circumstances:

  • The backends used by the backend service are instance groups, not network endpoint groups.
  • The backend VMs can be probed using either HTTP or HTTPS.

How health checks work

Probes

When you create a health check or create a legacy health check, you specify the following flags or accept their default values. These flags control how frequently each GCP health check system probes your VM instances. GCP implements probes using multiple systems.

Configuration flag Purpose Default value
Check interval
check-interval
The check interval is the amount of time from the start of one probe issued by one probing system to the start of the next probe issued by the same system. Units are seconds. If omitted, GCP uses 5s (5 seconds).
Timeout
timeout
The timeout is the amount of time that GCP will wait for a response to a probe. Its value must be less than or equal to the check interval. Units are seconds. If omitted, GCP uses 5s (5 seconds).

Probe IP ranges

The source IP addresses for GCP probe systems depend on the type of load balancer. Use the following table to create ingress allow firewall rules that allow traffic from GCP probe systems to your VMs.

Load Balancer Probe IP ranges Firewall rule example
Internal
TCP Proxy
SSL Proxy
HTTP(S)
35.191.0.0/16
130.211.0.0/22
Firewall rules for all load balancers except network load balancers
Network 35.191.0.0/16
209.85.152.0/22
209.85.204.0/22
Firewall rules for network load balancers

Multiple probes and frequency

Probes are sent from multiple redundant systems from the appropriate source IP ranges. No single system is responsible for all of the probes. Multiple systems issue probes simultaneously so that failure of one probing system does not cause GCP to lose track of VM health states.

For a given VM instance, if you examine software access logs or inspect incoming traffic with a tool such as tcpdump, you'll notice multiple systems simultaneously contacting your VM from the probe source IP ranges. The total number of probes will be more numerous, and you will see probe requests more frequently, than if there were just one probing system used. Each probing system issues probes according to the interval and timeout settings you configured, but multiple systems do this simultaneously.

This is expected behavior, and you cannot configure the number of systems that GCP uses to implement health check probes.

Content-based health checks

HTTP(S), TCP, and SSL health checks can optionally be content-based (request/response). In a content-based health check, the health check prober sends a request string to the VM. The health check is configured to expect a particular response to the probe.

Success criteria for HTTP, HTTPS, and HTTP/2

Responses from probes for health checks using HTTP, HTTPS, or HTTP/2 protocols are successful only if GCP receives an HTTP 200 (OK) response to the request it sends and that response is delivered before the probe timeout.

Requests are sent to a configurable request path, or /, if unspecified. Any response is accepted, unless you use content-based checking to provide an expected response string. The flags available to control success criteria for HTTP, HTTPS, and HTTP/2 health checks are:

Configuration flag Purpose
Request path
request-path
Specify the URL path to which GCP sends health check probe requests.
If omitted, GCP sends probe requests to the root path, /.
Response
response
The optional response flag allows you to configure a content-based health check. The expected response string must be less than or equal to 1,024 ASCII (single byte) characters. When configured, GCP expects this string within the first 1,024 bytes of the response in addition to receiving HTTP 200 (OK) status.

Use of a content-based health check is optional. Whether or not you specify an expected response string, GCP expects the VM instance being checked to respond with HTTP 200 (OK). When you supply an expected response, each GCP health check prober searches the response provided by your VMs, looking for the expected response string within the first 1,024 bytes returned. A content-based HTTP health check is considered successful if both HTTP 200 (OK) is received and the expected response is found in the first 1,024 bytes of the returned response.

Success criteria for SSL and TCP

By default, responses from probes for health checks using SSL and TCP protocols are successful only if GCP is able to successfully complete a SSL or TCP handshake to establish a session before the probe timeout.

Optionally, in addition to completing a handshake, you can provide a request string and an expected response string, each up to 1,024 ASCII (single byte) characters in length. When an expected response string is configured, GCP considers a probe successful only if the SSL or TCP handshake completes and the response string returned exactly matches the expected response string. The following combinations of request and response flags are available for health checks using the SSL and TCP protocols:

Configuration flags Behavior
Neither request nor response specified
Neither flag specified: --request, --response
GCP considers the probe successful if the TCP or SSL session is established before the probe timeout.
Both request and response specified
Both flags specified: --request, --response
GCP sends your configured request string and waits for the expected response string. The probe is successful if the TCP or SSL session is established and the response string returned exactly matches the expected response string before the probe timeout.
Only response specified
Flags specified: only --response
GCP waits for the expected response string. The probe is successful if the TCP or SSL session is established and the response string returned exactly matches the expected response string before the probe timeout.
You should only use --response by itself if your VMs being load balanced would automatically send a response string as part of the handshake.
Only request specified
Flags specified: only --request
GCP sends your configured request string. The probe is successful if a TCP or SSL session is established before the probe timeout. The response, if any, is not checked.

Health state

GCP uses the following configuration flags and whether or not probes were successful to determine the overall health state of each VM instance being load balanced:

Configuration flag Purpose Default value
Healthy threshold
healthy-threshold
The healthy threshold specifies the number of sequential successful probe results for a VM instance to be considered healthy. If omitted, GCP uses a threshold of 2 probes.
Unhealthy threshold
unhealthy-threshold
The unhealthy threshold specifies the number of sequential failed probe results for a VM instance to be considered unhealthy. If omitted, GCP uses a threshold of 2 probes.

GCP considers instances to be healthy once this healthy threshold has been met. Healthy VMs are eligible to receive new connections.

GCP considers instances to be unhealthy when the unhealthy threshold has been met. Unhealthy VMs are not eligible to receive new connections; however, existing connections are not terminated. Existing connections might fail to return responses, depending on the cause for failing the probe.

An unhealthy VM can become healthy if it is able to meet the healthy threshold again.

What's next

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

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

Send feedback about...

Load Balancing