From 1b94c804f3094cf5c9a0ac9dca313e2e8a10a0c3 Mon Sep 17 00:00:00 2001 From: Dan Frost Date: Wed, 26 Nov 2014 13:42:53 +0000 Subject: [PATCH] docs: agent/checks: minor fixes --- website/source/docs/agent/checks.html.markdown | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/website/source/docs/agent/checks.html.markdown b/website/source/docs/agent/checks.html.markdown index a5a4bdb566..8a31a04620 100644 --- a/website/source/docs/agent/checks.html.markdown +++ b/website/source/docs/agent/checks.html.markdown @@ -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