Monitors¶

Show health monitor configuration
Update health monitor
Delete health monitor

The load balancing service includes a health monitoring operation that periodically checks your back-end nodes to ensure they are responding correctly. If a node does not respond, it is removed from rotation until the health monitor determines that the node is functional. In addition to being performed periodically, the health check also is performed against every node that is added to ensure that the node is operating properly before allowing it to service traffic. Only one health monitor is allowed to be enabled on a load balancer at a time.

As part of your strategy for monitoring connections, you should consider defining secondary nodes that provide failover for effectively routing traffic in case the primary node fails. This is an additional feature that ensures that you remain up in case your primary node fails.

Every health monitor has a type attribute to signify what kind of monitor it is, as shown in the following table:

Name	Description
CONNECT	Health monitor is a connect monitor.
HTTP	Health monitor is an HTTP monitor.
HTTPS	Health monitor is an HTTPS monitor.

For more information about the three types of monitors, including required and optional parameters, see Show health monitor configuration.

Note

When deleting a health monitor of any type, every node on that load balancer that is enabled or has failed and is in OFFLINE status has its status updated to ONLINE regardless of the health of the node.

Show health monitor configuration ¶

GET /v1.0/{account}/loadbalancers/{loadBalancerId}/healthmonitor

Shows the health monitor configuration, if one exists.

Connect Monitor

The monitor connects to each node on its defined port to ensure that the service is listening properly. The connect monitor is the most basic type of health check and does no post-processing or protocol-specific health checks. It includes several configurable properties, as shown in the following Monitor Attributes section.

Monitor HTTP and HTTPS

The HTTP and HTTPS monitor is more intelligent than the connect monitor. It is capable of processing an HTTP or HTTPS response to determine the condition of a node. It supports the same basic properties as the connect monitor and includes additional attributes that are used to evaluate the HTTP response. You can supply an optional hostHeader attribute for the HTTP and HTTPS health monitor to specify a host for which the health monitors should check. See the following Monitor Attributes section.

Monitor Attributes

The following table lists the required and optional attributes for both Monitor Connections and Monitor HTTP and HTTPS:

Attributes for Connect Monitor and Monitor HTTP and HTTPS¶
Name	Description	Required
attemptsBeforeDeactivation	Number of permissible monitor failures before removing a node from rotation. Must be a number between 1 and 10.	Yes
delay	The minimum number of seconds to wait before executing the health monitor. Must be a number between 1 and 3600.	Yes
timeout	Maximum number of seconds to wait for a connection to be established before timing out. Must be a number between 1 and 300.	Yes
type	Type of the health monitor. Must be specified as “CONNECT” to monitor connections.	Yes

The following table lists the additional required and optional attributes for Monitor HTTP and HTTPS:

**Attributes for HTTP and HTTPS Monitor**¶
Name	Description	Required
attemptsBeforeDeactivation	Number of permissible monitor failures before removing a node from rotation. Must be a number between 1 and 10.	Yes
bodyRegex	A regular expression that will be used to evaluate the contents of the body of the response. For example you could use the regular expression “^.(Unauthorized\|Forbidden\| Not Found\|Timeout\|Server Error).$” to look for any of those problematic strings. in the body of the response or use the regular expression “^success$” to look for the string “success”. Note The system only evaluates the first 2048 bytes of the response against the bodyRegex that is specified, so you will want to test accordingly. To debug the HTTP/HTTPS health monitoring you will want to test the bodyRegex against the IP of the node(s) that are being disabled. You can use the following cURL command to see what the health monitoring analyzes: curl -s -r 0-2048 https://YOUR_IP_ADDRESS \| head -c2048 \| egrep “YOUR_REGULAR_EXPRESSION”	No
delay	The minimum number of seconds to wait before executing the health monitor. Must be a number between 1 and 3600.	Yes
hostHeader	The name of a host for which the health monitors will check.	No
path	The HTTP path that will be used in the sample request.	Yes
statusRegex	A regular expression that will be used to evaluate the HTTP status code returned in the response.	Yes
timeout	Maximum number of seconds to wait for a connection to be established before timing out. Must be a number between 1 and 300.	Yes
type	Type of the health monitor. Must be specified as “HTTP” to monitor an HTTP response or “HTTPS” to monitor an HTTPS response.	Yes

Response codes¶

The following table shows the possible response codes for this operation:

Response Code	Name	Description
200	Success	Request succeeded.
400	Bad Request	The request is missing one or more elements, or the values of some elements are invalid.
401	Unauthorized	You are not authorized to complete this operation. This error can occur if the request is submitted with an invalid authentication token.
404	Not Found	The requested item was not found.
413	Over Limit	The number of items returned is above the allowed limit.
422	ImmutableEntity	This fault is returned when a user attempts to modify an item that is not currently in a state that allows modification. For example, load balancers in a status of PENDING_UPDATE,BUILD, or DELETED may not be modified.
500	Load Balancer Fault	The load balancer has experienced a fault.
503	Service Unavailable	The service is not available.

Request¶

The following table shows the URI parameters for the request:

Name	Type	Description
{account}	String	The ID for the tenant or account in a multi- tenancy cloud.
{loadBalancerId}	String	The ID for the load balancer.

This operation does not accept a request body.

Response¶

Example Show connect monitor configuration: XML response

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<healthMonitor xmlns="http://docs.openstack.org/loadbalancers/api/v1.0"
    type="CONNECT"
    delay="10"
    timeout="10"
    attemptsBeforeDeactivation="3" />

Example Show connect monitor configuration: JSON response

{
    "healthMonitor":{
        "type": "CONNECT",
        "delay": 10,
        "timeout": 10,
        "attemptsBeforeDeactivation": 3
    }
}

Example Show http monitor configuration: ATOM/XML response

<?xml version='1.0' encoding='UTF-8'?>
<feed xmlns="http://www.w3.org/2005/Atom">
    <link rel="next"
          href="https://ord.loadbalancers.api.rackspacecloud.com/v1.0/1234/loadbalancers/141/healthmonitor.atom?page=2"/>
    <title type="text">Health Monitor Feed</title>
    <id>1234-loadbalancers-141-healthmonitor</id>
    <author>
        <name>Rackspace Cloud</name>
    </author>
    <entry>
        <title type="text">Health Monitor Successfully Updated</title>
        <summary
                type="text">Health monitor successfully updated with type: 'HTTP', delay: '10', timeout: '10', attemptsBeforeDeactivation: '3', path: '/', statusRegex: '^[234][0-9][0-9]$', bodyRegex: '^[234][0-9][0-9]$'
        </summary>
        <author>
            <name>tvardema</name>
        </author>
        <link href="https://ord.loadbalancers.api.rackspacecloud.com/v1.0/1234/loadbalancers/141/healthmonitor/"/>
        <id>1234-loadbalancers-141-healthmonitor-201142022120</id>
        <category term="UPDATE"/>
        <updated>2011-02-11T00:22:12.000Z</updated>
    </entry>
</feed>

Example Show http monitor configuration: JSON response

{
    "healthMonitor": {
        "type": "HTTP",
        "delay": 10,
        "timeout":10,
        "attemptsBeforeDeactivation": 3,
        "path": "/",
        "statusRegex":"^[234][0-9][0-9]$",
        "bodyRegex": "^[234][0-9][0-9]$",
        "hostHeader": "myrack.com"
    }
}

Example Show http monitor configuration: XML response

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<healthMonitor xmlns="http://docs.openstack.org/loadbalancers/api/v1.0"
    type="HTTP"
    delay="10"
    timeout="10"
    attemptsBeforeDeactivation="3"
    path="/"
    statusRegex="^[234][0-9][0-9]$"
    bodyRegex="^[234][0-9][0-9]$"
    hostHeader="myrack.com"/>

Example Show https monitor configuration: JSON response

{
    "healthMonitor": {
        "type": "HTTPS",
        "delay": 10,
        "timeout":10,
        "attemptsBeforeDeactivation": 3,
        "path": "/",
        "statusRegex":"^[234][0-9][0-9]$",
        "bodyRegex": "^[234][0-9][0-9]$",
        "hostHeader": "myrack.com"
    }
}

Example Show https monitor configuration: XML response

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<healthMonitor xmlns="http://docs.openstack.org/loadbalancers/api/v1.0"
    type="HTTPS"
    delay="10"
    timeout="10"
    attemptsBeforeDeactivation="3"
    path="/"
    statusRegex="^[234][0-9][0-9]$"
    bodyRegex=""
    hostHeader="myrack.com"/>

Update health monitor ¶

PUT /v1.0/{account}/loadbalancers/{loadBalancerId}/healthmonitor

Updates the settings for a health monitor.

Every health monitor has a type attribute to signify what kind of monitor it is.

The following table lists the health monitor types:

Health monitor types¶
Name	Description
CONNECT	Health monitor is a connect monitor.
HTTP	Health monitor is a HTTP monitor.
HTTPS	Health monitor is a HTTPS monitor.

Note

When deleting a health monitor of any type, every node on that load balancer that is enabled or has failed and is in OFFLINE status has its status updated to ONLINE regardless of the health of the node.

Connect Monitor The monitor connects to each node on its defined port to ensure that the service is listening properly. The connect monitor is the most basic type of health check and does no post-processing or protocol specific health checks. It includes several configurable properties. The following table lists the required and optional attributes for Monitor Connections:

Required and Optional Attributes for Monitor Connections¶
Name	Description	Required
attemptsBeforeDeactivation	Number of permissible monitor failures before removing a node from rotation. Must be a number between 1 and 10.	Yes
delay	The minimum number of seconds to wait before executing the health monitor. Must be a number between 1 and 3600.	Yes
timeout	Maximum number of seconds to wait for a connection to be established before timing out. Must be a number between 1 and 300.	Yes
type	Type of the health monitor. Must be specified as “CONNECT” to monitor connections.	Yes

Monitor HTTP and HTTPS The HTTP and HTTPS monitor is more intelligent than the connect monitor. It is capable of processing a HTTP or HTTPS response to determine the condition of a node. It supports the same basic properties as the connect monitor and includes additional attributes that are used to evaluate the HTTP response. The user can supply an optional hostHeader attribute for the HTTP and HTTPS health monitor to specify a host for which the health monitors will check. The following table lists the required and optional attributes for Monitor HTTP and HTTPS:

Required and Optional Attributes for Monitor HTTP and HTTPS¶
Name	Description	Required
attemptsBeforeDeactivation	Number of permissible monitor failures before removing a node from rotation. Must be a number between 1 and 10.	Yes
bodyRegex	A regular expression that will be used to evaluate the contents of the body of the response. For example you could use the regular expression “^.(Unauthorized\|Forbidden\|Not Found\|Timeout\|Server Error).$” to look for any of those potentially problematic strings in the body of the response or use the regular expression “^success$” to look for the string “success”. Note: The system only evaluates the first 2048 bytes of the response against the bodyRegex that is specified, so you will want to test accordingly. To debug the HTTP/HTTPS health monitoring you will want to test the bodyRegex against the IP of the node(s) that are being disabled. You can use the following cURL command to see what the health monitoring analyzes: curl -s -r 0-2048 https://YOUR_IP_ADDRESS \| head -c 2048 \| egrep “YOUR_REGULAR_EXPRESSION”	No
delay	The minimum number of seconds to wait before executing the health monitor. Must be a number between 1 and 3600.	Yes
hostHeader	The name of a host for which the health monitors will check.	No
path	The HTTP path that will be used in the sample request.	Yes
statusRegex	A regular expression that will be used to evaluate the HTTP status code returned in the response.	Yes
timeout	Maximum number of seconds to wait for a connection to be established before timing out. Must be a number between 1 and 300.	Yes
type	Type of the health monitor. Must be specified as “HTTP” to monitor a HTTP response or “HTTPS” to monitor a HTTPS response.	Yes

The following table shows the possible response codes for this operation:

Response Code	Name	Description
202	Success	Request succeeded.
400	Bad Request	The request is missing one or more elements, or the values of some elements are invalid.
401	Unauthorized	You are not authorized to complete this operation. This error can occur if the request is submitted with an invalid authentication token.
404	Not Found	The requested item was not found.
413	Over Limit	The number of items returned is above the allowed limit.
422	ImmutableEntity	This fault is returned when a user attempts to modify an item that is not currently in a state that allows modification. For example, load balancers in a status of PENDING_UPDATE,BUILD, or DELETED may not be modified.
500	Load Balancer Fault	The load balancer has experienced a fault.
503	Service Unavailable	The service is not available.

Request¶

The following table shows the URI parameters for the request:

Name	Type	Description
{account}	String	The ID for the tenant or account in a multi- tenancy cloud.
{loadBalancerId}	String	The ID for the load balancer.

Example Update Connect health monitor: XML request

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<healthMonitor xmlns="http://docs.openstack.org/loadbalancers/api/v1.0"
    type="CONNECT"
    delay="10"
    timeout="10"
    attemptsBeforeDeactivation="3" />

Example Update Connect health monitor: JSON request

{
    "healthMonitor":{
        "type": "CONNECT",
        "delay": 10,
        "timeout": 10,
        "attemptsBeforeDeactivation": 3
    }
}

Example Update HTTP health monitor: XML request

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<healthMonitor xmlns="http://docs.openstack.org/loadbalancers/api/v1.0"
    type="HTTP"
    delay="10"
    timeout="10"
    attemptsBeforeDeactivation="3"
    path="/"
    statusRegex="^[234][0-9][0-9]$"
    bodyRegex="^[234][0-9][0-9]$"
    hostHeader="mysite.com"/>

Example Update HTTP health monitor: JSON request

{
    "healthMonitor": {
        "type": "HTTP",
        "delay": 10,
        "timeout":10,
        "attemptsBeforeDeactivation": 3,
        "path": "/",
        "statusRegex":"^[234][0-9][0-9]$",
        "bodyRegex": "^[234][0-9][0-9]$",
        "hostHeader": "mysite.com"
    }
}

Response¶

This operation does not return a response body.

Delete health monitor ¶

DELETE /v1.0/{account}/loadbalancers/{loadBalancerId}/healthmonitor

Deletes a health monitor.

The following table shows the possible response codes for this operation:

Response Code	Name	Description
202	Success	Request succeeded.
400	Bad Request	The request is missing one or more elements, or the values of some elements are invalid.
401	Unauthorized	You are not authorized to complete this operation. This error can occur if the request is submitted with an invalid authentication token.
404	Not Found	The requested item was not found.
413	Over Limit	The number of items returned is above the allowed limit.
422	ImmutableEntity	This fault is returned when a user attempts to modify an item that is not currently in a state that allows modification. For example, load balancers in a status of PENDING_UPDATE,BUILD, or DELETED may not be modified.
500	Load Balancer Fault	The load balancer has experienced a fault.
503	Service Unavailable	The service is not available.

Request¶

The following table shows the URI parameters for the request:

Name	Type	Description
{account}	String	The ID for the tenant or account in a multi- tenancy cloud.
{loadBalancerId}	String	The ID for the load balancer.

This operation does not accept a request body.

Response¶

This operation does not return a response body.

Monitors¶

Show health monitor configuration¶

Response codes¶

Request¶

Response¶

Update health monitor¶

Request¶

Response¶

Delete health monitor¶

Request¶

Response¶

Show health monitor configuration ¶

Update health monitor ¶

Delete health monitor ¶