osc load-balancer healthmonitor create

Creates a health monitor on a pool.

Health monitors define how the load balancer monitors backend servers to determine if they are available to service requests.

This operation provisions a new health monitor by using the configuration that you define in the request object. After the API validates the request and starts the provisioning process, the API returns a response object that contains a unique ID and the status of provisioning the health monitor.

In the response, the health monitor provisioning status is ACTIVE, PENDING_CREATE, or ERROR.

If the status is PENDING_CREATE, issue GET /v2/lbaas/healthmonitors/{healthmonitor_id} to view the progress of the provisioning operation. When the health monitor status changes to ACTIVE, the health monitor is successfully provisioned and is ready for further configuration.

If the API cannot fulfill the request due to insufficient data or data that is not valid, the service returns the HTTP Bad Request (400) response code with information about the failure in the response body. Validation errors require that you correct the error and submit the request again.

Specifying a project_id is deprecated. The health monitor will inherit the project_id of the parent load balancer.

At a minimum, you must specify these health monitor attributes:

Some attributes receive default values if you omit them from the request:

To create a health monitor, the parent load balancer must have an ACTIVE provisioning status.

Usage: osc load-balancer healthmonitor create [OPTIONS] --delay <DELAY> --max-retries <MAX_RETRIES> --pool-id <POOL_ID> --timeout <TIMEOUT> --type <TYPE>

Options:

  • --admin-state-up <ADMIN_STATE_UP> — The administrative state of the resource, which is up (true) or down (false). Default is true

    Possible values: true, false

  • --delay <DELAY> — The time, in seconds, between sending probes to members

  • --domain-name <DOMAIN_NAME> — The domain name, which be injected into the HTTP Host Header to the backend server for HTTP health check.

    New in version 2.10

  • --expected-codes <EXPECTED_CODES> — The list of HTTP status codes expected in response from the member to declare it healthy. Specify one of the following values:

    • A single value, such as 200 - A list, such as 200, 202 - A range, such as 200-204

    The default is 200.

  • --http-method <HTTP_METHOD> — The HTTP method that the health monitor uses for requests. One of CONNECT, DELETE, GET, HEAD, OPTIONS, PATCH, POST, PUT, or TRACE. The default is GET

    Possible values: connect, delete, get, head, options, patch, post, put, trace

  • --http-version <HTTP_VERSION> — The HTTP version. One of 1.0 or 1.1. The default is 1.0.

    New in version 2.10

  • --max-retries <MAX_RETRIES> — The number of successful checks before changing the operating status of the member to ONLINE. A valid value is from 1 to 10

  • --max-retries-down <MAX_RETRIES_DOWN> — The number of allowed check failures before changing the operating status of the member to ERROR. A valid value is from 1 to 10. The default is 3

  • --name <NAME> — Human-readable name of the resource

  • --pool-id <POOL_ID> — The ID of the pool

  • --project-id <PROJECT_ID> — The ID of the project owning this resource. (deprecated)

  • --tags <TAGS> — A list of simple strings assigned to the resource.

    New in version 2.5

  • --tenant-id <TENANT_ID>

  • --timeout <TIMEOUT> — The maximum time, in seconds, that a monitor waits to connect before it times out. This value must be less than the delay value

  • --type <TYPE> — The type of health monitor. One of HTTP, HTTPS, PING, SCTP, TCP, TLS-HELLO, or UDP-CONNECT

    Possible values: http, https, ping, sctp, tcp, tls-hello, udp-connect

  • --url-path <URL_PATH> — The HTTP URL path of the request sent by the monitor to test the health of a backend member. Must be a string that begins with a forward slash (/). The default URL path is /