We usually check the health check log when there is an endpoint change in health status, but you should ensure that you do not have any log exclusion that applies to health checks. Here you will see how to perform a health check for load balancing.
You will require the need of health check when there is a purpose for an audit and compliance, live debugging & troubleshooting endpoint health status, and gain visibility into your endpoint’s health status.
There are a few limitations you need to consider, such as;
Health check logging on interfaces, other than nic0 of VMs connected to internal TCP / UDP load balancers is not supported.
Logs will be generated for endpoint health transition only. The legacy health checks and target pools will not be supported.
How to enable & disable logging
You can now enable or disable logging to a new or existing health check by following the below-given instructions.
Enable logging on to a new health check:
Head to the Google Cloud Console’s health check page and select the ‘create a health check’ option.
Then set the Logs radio button to ‘ON’ and continue to set up your health check.
To enable logging on to an existing health check:
Head to the Google Cloud Console’s health check page and select the name of your health check page. You will see an ‘edit’ click that and set the Logs radio button to ‘ON’ and then ‘Save’.
How to disable / modify logging on an existing health check
Similar to the above steps in the Google Cloud Console’s health check page you will have to set the Logs radio button to ‘OFF’ and ‘Save’.
How to View logs:
In order to view logs, you need to head to the Logs explorer. The Health check logs will be indexed by the instance group or by the network endpoint group. You can view the entire log in the Resource menu – GCE Instance Group or Network Endpoint Group (depending on the backend you have).
What is logged
The information included in health check log entries will be used to monitor and debug the state of your endpoints. The following information is available in log entries:
- Most of the logs display general information like severity, project ID, project number, timestamp, and so on.
- Specific fields for health checks are described below.,
States of Health Check
An endpoint is determined as either HEALTHY or UNHEALTHY and they are basic states. Each of the basic states has several more detailed states.
Detailed state of HEALTHY – Healthy, Draining & UNHEALTHY- Unknown, Unhealthy, Timeout.
The behavior of the load balancer will not always be affected by state changes. Let’s see the following scenario:
- Since the server returns an incorrect response, the endpoint is classified as UNHEALTHY.
- When the server fails to respond, then the new state is TIMEOUT.
- The load balancer continues to consider the endpoint as UNHEALTHY because the detailed state of Time Out is a map to the basic state of UNHEALTHY.
Now, let us see the detailed definition of each health state:
- HEALTHY – The endpoint is achieved and also endpoint satisfies the health check’s requirements. Then, the basic state is considered as HEALTHY.
- UNHEALTHY – The endpoint is reachable, but it does not meet the health check’s requirements. Then, the basic state is considered UNHEALTHY.
- DRAINING – The endpoint is currently being drained. Existing connections to the endpoint are allowed to complete, but new ones are rejected. The basic state is considered as HEALTHY.
- TIMEOUT – The endpoint cannot be reached. Depending on the type of health check, either a connection to the endpoint could not be established or the server did not respond within the timeout specified. The basic state is considered UNHEALTHY.
- UNKNOWN – The endpoint is known to the health check system, but its health is unknown. The basic state is considered UNHEALTHY.
Each endpoint will be prob by multiple health checkers. Google Cloud de-duplicates log entries before logging in to ensure that only unique logs are generated. If a health checker restarts, the logged health state may occasionally change from UNKNOWN to one of the known states listed earlier, even if the endpoint’s health state has not changed.
If you use connection draining, a health check log with the endpoint health status DRAINING will not be generated. Connection draining does not directly affect the endpoint’s true health state as seen by the health checkers. Instead, connection draining simply informs the load balancer of the endpoint’s new state, which effectively negates the endpoint’s true health state.
Health Check – Log Entry
The LogEntry jsonPayload contains the following information in the field healthCheckProbeResult:
- ipAddress – string The primary internal IP address associated with each backend VM’s primary network interface and this string can be read by humans.
- healthCheckProtocol – HealthCheckProtocol It is used to check the endpoint’s health. Eg: TCP, HTT P, HTTPS.
- healthstate – Healthstate The endpoint’s current health status: HEALTHY or UNHEALTHY.
- previousDetailedHealthState – Detailedhealthstate The endpoint’s previous detailed health status
- probeRequest – string This is the URL request path for HTTP, HTTPS, and HTTP / 2 (requestPath field in the resource config). This is configured optional string that is sent once the health check connection is established for TCP / SSL (request field in the resource config).
- probeCompletionTimestamp – Timestamp Timestamp of probe completion.
- connectLatency – Duration Time spent configuring connections for connection-oriented health check protocols such as TCP, SSL, HTTP, HTTPS, and HTTP / 2.
- responseLatency – Duration The prober measures the time elapsed between a request and a response.
We help our customers efficiently distribute their incoming traffic across the backend servers and improve their server uptime and assist with checks for Load Balancing. If you need any assistance, feel free to get support.
Also check: How to setup SSL for Elastic Load Balancer in AWS
To get more updates you can follow us on Facebook, Twitter, LinkedIn
Subscribe to get free blog content to your Inbox
