|
|
|
@ -16,12 +16,12 @@ or added at runtime over the HTTP interface.
|
|
|
|
|
There are two different kinds of checks: |
|
|
|
|
|
|
|
|
|
* Script + Interval - These checks depend on invoking an external application |
|
|
|
|
which does the health check and exits with an appropriate exit code, potentially |
|
|
|
|
that does the health check and exits with an appropriate exit code, potentially |
|
|
|
|
generating some output. A script is paired with an invocation interval (e.g. |
|
|
|
|
every 30 seconds). This is similar to the Nagios plugin system. |
|
|
|
|
|
|
|
|
|
* 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 |
|
|
|
|
* 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 |
|
|
|
|
external system fails to update the status within a given TTL, the check is |
|
|
|
|
set to the failed state. This mechanism is used to allow an application to |
|
|
|
|
directly report its health. For example, a web app can periodically curl the |
|
|
|
@ -75,7 +75,7 @@ check can be registered dynamically using the [HTTP API](/docs/agent/http.html).
|
|
|
|
|
## Check Scripts |
|
|
|
|
|
|
|
|
|
A check script is generally free to do anything to determine the status |
|
|
|
|
of the check. The only limitations placed are the exit codes must convey |
|
|
|
|
of the check. The only limitations placed are that the exit codes must convey |
|
|
|
|
a specific meaning. Specifically: |
|
|
|
|
|
|
|
|
|
* Exit code 0 - Check is passing |
|
|
|
|