Cloud Docs Home > F5 Application Services Proxy Index

Health Monitors

Health monitor enables the Application Services Proxy (ASP) to monitor the health of the endpoints associated with virtual servers and use the health information for load balancing traffic across healthy endpoints. By default, the ASP does not monitor the health of endpoints.

To turn on health monitors, add the health monitors section to the ASP virtual server configuration.

The ASP applies the defined set of health checks against each of the virtual server’s endpoints. If any of the checks fail, the ASP marks the endpoint as unhealthy and removes it from the pool available to the ASP load balancer. The endpoint will remain unavailable for load balancing until all health checks pass.

Types of Health Checks

The ASP supports two types of health checks: active and passive. You can set up one or both types for any virtual server the ASP manages.

Active Health Checks

Active health checks periodically probe the endpoints by sending out an HTTP request and expecting a specific response. The interval setting controls the probing interval. If the ASP doesn’t receive a proper response within the timeout period, the health check will consider that probe as “failed”. Each virtual server may have zero (0) or more active health checks.

There are several conditions that count towards a probe failure:

  • The probe connection to the backend encountered an error.
  • The HTTP response status did not match the expected value.
  • The request timed out.

When down-count consecutive probes to an endpoint have failed, the ASP marks the health check for the endpoint as unhealthy. Once the ASP has marked a health check as unhealthy, there must be up-count consecutive successful probes before the ASP will mark the health check healthy.

Tip

The ASP shares health check probes across virtual servers if the health checks are identically defined and the virtual servers share common endpoints. This reduces the number of probes each endpoint receives.

Share health check data across ASP instances

In environments where multiple client-side ASP instances run within the cluster, like Kubernetes, individual endpoints will receive identical health probes from all ASPs. To eliminate the duplicate probing of endpoints, the ASP has the ability to shard the responsibility of issuing health probes among all ASPs. Each ASP can store the results of their probes in a centrally located ephemeral data store. This data store will then be available for all other ASPs to query.

Passive Health Checks

Passive health checks monitor the client traffic. Performing passive health checks enables opportunistic health monitoring by observing client traffic to the load-balanced endpoint without overloading the endpoint with excessive health probes.

There are several conditions that count towards a passive health check failure:

  • The client connection to the backend encountered an error.
  • The HTTP response status is within the range considered to be invalid.
  • The request timed out.

When down-count consecutive failures have occurred, the ASP marks the health check for the endpoint as unhealthy. The ASP health check will remain unhealthy until the inactivity-timeout period expires. At that time, the health check will revert back to its default state.

If a client request was successful and the health check is not in the inactivity timeout period, the health check state for the endpoint is healthy.

The formula below can help you determine an optimal value for the inactivity-timeout for passive health checks.

inactivity-timeout >= max(interval * down-count)

In this formula, the passive health check inactivity-timeout value is greater than the product of any active health check’s interval and down-count values. This allows the ASP enough time to determine the success or failure of any active health check.

ASP handling of health checks

Default states

The ASP initially sets the state of all health checks to their default state. The ASP keeps the health check in the default state until it has enough information to determine otherwise. If the health check state is currently in the default state and that state is unknown, the ASP load balancer ignores the health check when determining the pool of healthy endpoints.

Multiple health checks

When there is one or more health checks defined for a virtual server, a failure in any of the health checks results in the ASP removing the endpoint from the pool available to the load balancer.

All virtual server endpoints are unhealthy

If the ASP determines all endpoints of a virtual server are unhealthy, it responds to client requests with a 503 (service unavailable) status code. This is the same error that occurs if the virtual server has no endpoints configured.

Example

The example below shows a health monitor configuration with one passive and one active health check.

The passive health check fails if three (3) consecutive HTTP responses have a HTTP status code greater than or equal to 500. It will also fail if three (3) consecutive connections fail (or any combination of three failed connections and bad responses). Once a failure occurs the health check remains in the failed state for 30 seconds before reverting back to its default state.

The active health check will fail for a particular endpoint if three (3) consecutive probes fail to return a HTTP status code of 200. Once the health check has failed, it will stay in the failed state until two (2) consecutive probes return a HTTP status code of 200.

{
 "health-monitor": {
   "health-checks": {
     "example-active-check": {
       "active": {
         "default-state": "unknown",
         "active": {
           "timeout": 10,
           "interval": 10,
           "up-count": 2,
           "down-count": 3,
           "http": {
             "response-status": 200,
             "path": "/healthz"
           }
         }
       }
     },
     "example-passive-check": {
       "passive": {
         "default-state": "healthy",
         "inactivity-timeout": 30,
         "down-count": 3,
         "invalid-http": [
           {
             "min": 500
           }
         ]
       }
     }
   }
 }
}