Active healthchecks are disabled by default and can be enabled for a server pool by binding a health monitor to the Group through the PolicyLbRule object. This represents active health monitoring over HTTPS. Active healthchecks are initiated periodically, at a configurable interval, to each member of the Group. Only if a healthcheck fails consecutively for a specified number of times (fall_count) to a member will the member status be marked DOWN. Once a member is DOWN, a specified number of consecutive successful healthchecks (rise_count) will bring the member back to UP state. After a healthcheck is initiated, if it does not complete within a certain period, then also the healthcheck is considered to be unsuccessful. Completing a healthcheck within timeout means establishing a connection (TCP or SSL), if applicable, sending the request and receiving the response, all within the configured timeout.
Timestamp of resource creation
ID of the user who created this resource
Timestamp of last modification
ID of the user who last modified this resource
|optional||_links||array of ResourceLink||
The server will populate this field when returing the resource. Ignored on PUT and POST.
Protection status is one of the following: PROTECTED - the client who retrieved the entity is not allowed to modify it. NOT_PROTECTED - the client who retrieved the entity is allowed to modify it REQUIRE_OVERRIDE - the client who retrieved the entity is a super user and can modify it, but only when providing the request header X-Allow-Overwrite=true. UNKNOWN - the _protection field could not be determined for this entity.
The _revision property describes the current revision of the resource. To prevent clients from overwriting each other’s changes, PUT operations must include the current _revision of the resource, which clients should obtain by issuing a GET operation. If the _revision provided in a PUT request is missing or stale, the operation will be rejected.
Schema for this resource
Link to this resource
Indicates system owned resource
|optional||children||array of ChildPolicyConfigResource||
subtree for this type within policy tree containing nested elements.
Description of this resource
Defaults to ID if not set
Only if a healthcheck fails consecutively for a specified number of times, given with fall_count, to a member will the member status be marked DOWN.
Unique identifier of this resource
Active healthchecks are initiated periodically, at a configurable interval (in seconds), to each member of the Group.
Intent objects are not directly deleted from the system when a delete is invoked on them. They are marked for deletion and only when all the realized entities for that intent object gets deleted, the intent object is deleted. Objects that are marked for deletion are not returned in GET call. One can use the search API to get these objects.
Typically, monitors perform healthchecks to Group members using the member IP address and pool_port. However, in some cases, customers prefer to run healthchecks against a different port than the pool member port which handles actual application traffic. In such cases, the port to run healthchecks against can be specified in the monitor_port value.
Path of its parent
Absolute path of this object
Path relative from its parent
The type of this resource.
Once a member is DOWN, a specified number of consecutive successful healthchecks specified by rise_count will bring the member back to UP state.
|optional||tags||array of Tag||
Opaque identifiers meaningful to the API user
Timeout specified in seconds. After a healthcheck is initiated, if it does not complete within a certain period, then also the healthcheck is considered to be unsuccessful. Completing a healthcheck within timeout means establishing a connection (TCP or SSL), if applicable, sending the request and receiving the response, all within the configured timeout.
For HTTP active healthchecks, the HTTP request url sent can be customized and can include query parameters.