Clarify that hostname defaults to localhost for tcp

This commit is contained in:
Seth Vargo 2016-09-21 12:20:36 -04:00
parent 6b06fd04d3
commit e1c8b14a6b
No known key found for this signature in database
GPG Key ID: 905A90C2949E8787

View File

@ -23,7 +23,7 @@ There are five different kinds of checks:
every 30 seconds). This is similar to the Nagios plugin system. The output of
a script check is limited to 4K. Output larger than this will be truncated.
By default, Script checks will be configured with a timeout equal to 30 seconds.
It is possible to configure a custom Script check timeout value by specifying the
It is possible to configure a custom Script check timeout value by specifying the
`timeout` field in the check definition.
* HTTP + Interval - These checks make an HTTP `GET` request every Interval (e.g.
@ -37,18 +37,19 @@ There are five different kinds of checks:
limited to roughly 4K. Responses larger than this will be truncated.
* TCP + Interval - These checks make an TCP connection attempt every Interval
(e.g. every 30 seconds) to the specified IP/hostname and port. The status of
the service depends on whether the connection attempt is successful (ie - the
port is currently accepting connections). If the connection is accepted, the
status is `success`, otherwise the status is `critical`. In the case of a
hostname that resolves to both IPv4 and IPv6 addresses, an attempt will be
made to both addresses, and the first successful connection attempt will
result in a successful check. This type of check should be preferred over a
script that uses `netcat` or another external process to check a simple socket
operation. By default, TCP checks will be configured with a request timeout
equal to the check interval, with a max of 10 seconds. It is possible to
configure a custom TCP check timeout value by specifying the `timeout` field
in the check definition.
(e.g. every 30 seconds) to the specified IP/hostname and port. If no hostname
is specified, it defaults to "localhost". The status of the service depends on
whether the connection attempt is successful (ie - the port is currently
accepting connections). If the connection is accepted, the status is
`success`, otherwise the status is `critical`. In the case of a hostname that
resolves to both IPv4 and IPv6 addresses, an attempt will be made to both
addresses, and the first successful connection attempt will result in a
successful check. This type of check should be preferred over a script that
uses `netcat` or another external process to check a simple socket operation.
By default, TCP checks will be configured with a request timeout equal to the
check interval, with a max of 10 seconds. It is possible to configure a custom
TCP check timeout value by specifying the `timeout` field in the check
definition.
* <a name="TTL"></a>Time to Live (TTL) - These checks retain their last known state for a given TTL.
The state of the check must be updated periodically over the HTTP interface. If an
@ -65,14 +66,14 @@ There are five different kinds of checks:
last known status of the check across restarts. Persisted check status is
valid through the end of the TTL from the time of the last check.
* Docker + Interval - These checks depend on invoking an external application which
is packaged within a Docker Container. The application is triggered within the running
container via the Docker Exec API. We expect that the Consul agent user has access
to either the Docker HTTP API or the unix socket. Consul uses ```$DOCKER_HOST``` to
determine the Docker API endpoint. The application is expected to run, perform a health
check of the service running inside the container, and exit with an appropriate exit code.
The check should be paired with an invocation interval. The shell on which the check
has to be performed is configurable which makes it possible to run containers which
* Docker + Interval - These checks depend on invoking an external application which
is packaged within a Docker Container. The application is triggered within the running
container via the Docker Exec API. We expect that the Consul agent user has access
to either the Docker HTTP API or the unix socket. Consul uses ```$DOCKER_HOST``` to
determine the Docker API endpoint. The application is expected to run, perform a health
check of the service running inside the container, and exit with an appropriate exit code.
The check should be paired with an invocation interval. The shell on which the check
has to be performed is configurable which makes it possible to run containers which
have different shells on the same host. Check output for Docker is limited to
4K. Any output larger than this will be truncated.