Google cloud loadbalancer health checks cause a load on servers

kr flag

I have configured a load balancer https on google cloud with a health check having following parameters:

healthcheck :

Interval : 30 seconds
Timeout : 15 seconds
Healthy threshold:  1 success
Unhealthy threshold : 2 consecutive failures

I have noticed that the health check cause a lot of requests and the server scale to 6VM without a real traffic from user. Is the health check cause an internal traffic wich slow the server?

John Hanley avatar
cn flag
The health checks are not causing the scale up. Check Cloud Logging for details on why the scale up occurs. Edit your question with details on the autoscaling settings, VM instance details, etc.
pe flag

With these settings, the health check behaves as follows:

Interval : 30 seconds
Timeout : 15 seconds
Healthy threshold:  1 success
Unhealthy threshold : 2 consecutive failures

  1. Multiple redundant systems are simultaneously configured with the health check parameters. Interval and timeout settings are applied to each system.

  2. Each health check prober does the following:

2a. Initiates an HTTP connection from one of the source IP addresses to the backend instance every 30 seconds.

2b. Waits up to fifteen seconds for an HTTP 200 (OK) response code.

  1. A backend is considered unhealthy when at least one health check probe system does the following:

3a. Does not receive an HTTP 200 (OK) response code for one probes. For example, the connection might be refused, or there might be a connection or socket timeout.

3b. Receives two consecutive responses that don't match the protocol-specific success criteria.

  1. A backend is considered healthy when at least one health check probe system receives one responses that match the protocol-specific success criteria.

In this example, each prober initiates a connection every 30 seconds. Thirty seconds elapses between a prober's connection attempts regardless of the duration of the timeout (whether or not the connection timed out). In other words, the timeout must always be less than or equal to the interval, and the timeout never increases the interval.*

In this example, each prober's timing looks like the following, in seconds:

t=0: Start probe A.

t=15: Stop probe A.

t=30: Start probe B.

t=45: Stop probe B.

t=60: Start probe C.

t=75: Stop probe C.

Health checks determine if backends respond to traffic.

I suggest you change these values to :

Timeout : 5 seconds

Healthy threshold: 2 success

kg flag

Possible causes of unhealhy or failing heath check:

  • Firewall rules are blocking access for source IP ranges for health checks
  • Instance is not listening on the destination port
  • Guest Environment is not installed
  1. Confirm Firewall Rules are allowing the source IP ranges for health checks to connect to instances: Rules for health checks
  2. Ensure you can telnet to port used for health checking from another instance in the same network:
    telnet <instance-ip> <dst-port>
  3. Ensure TCP segments from IP ranges for health checks are reaching the instance:
    tcpdump -i any -ttn 'host <ilb-ip> and (net or net'
  4. Ensure the Guest Environment is installed so the NIC is configured to listen on the ILB IP address: Validating the guest environment

Kindly refer on link below:
What makes a good autohealing health check
Importance of firewall rules

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.