luxolus/open-consul
2
0
Fork 0
Code Issues 1 Pull requests Packages Releases Wiki Activity

Merge pull request #722 from ryanbreen/checks

Browse source 
Website: cleanup for getting-started/checks
This commit is contained in:
Ryan Breen 2015-02-20 18:35:31 -05:00
parent a9f23a9154 65c23a5f4f
commit c15029dc30
1 changed files with 27 additions and 25 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

52
website/source/intro/getting-started/checks.html.markdown
View file

@ -3,32 +3,31 @@ layout: "intro"
page_title: "Registering Health Checks" page_title: "Registering Health Checks"
sidebar_current: "gettingstarted-checks" sidebar_current: "gettingstarted-checks"
description: |- description: |-
We've now seen how simple it is to run Consul, add nodes and services, and query those nodes and services. In this section we will continue by adding health checks to both nodes and services, a critical component of service discovery that prevents using services that are unhealthy. We've now seen how simple it is to run Consul, add nodes and services, and query those nodes and services. In this section, we will continue our tour by adding health checks to both nodes and services. Health checks are a critical component of service discovery that prevents using services that are unhealthy.
--- ---
# Health Checks # Health Checks
We've now seen how simple it is to run Consul, add nodes and services, and We've now seen how simple it is to run Consul, add nodes and services, and
query those nodes and services. In this section we will continue by adding query those nodes and services. In this section, we will continue our tour
health checks to both nodes and services, a critical component of service by adding health checks to both nodes and services. Health checks are a
discovery that prevents using services that are unhealthy. critical component of service discovery that prevents using services that
are unhealthy.
This page will build upon the previous page and assumes you have a This page will build upon the previous page and assumes you have a
two node cluster running. two node cluster running.
## Defining Checks ## Defining Checks
Similarly to a service, a check can be registered either by providing a Similar to a service, a check can be registered either by providing a
[check definition](/docs/agent/checks.html), or by making the [check definition](/docs/agent/checks.html) or by making the
appropriate calls to the [HTTP API](/docs/agent/http.html). appropriate calls to the [HTTP API](/docs/agent/http.html).
We will use the check definition, because just like services, definitions We will use the check definition because, just like with services, definitions
are the most common way to setup checks. are the most common way to set up checks.
Create two definition files in the Consul configuration directory of Create two definition files in the Consul configuration directory of
the second node. the second node:
The first file will add a host-level check, and the second will modify the web
service definition to add a service-level check.
```text ```text
$ echo '{"check": {"name": "ping", "script": "ping -c1 google.com >/dev/null", "interval": "30s"}}' >/etc/consul.d/ping.json $ echo '{"check": {"name": "ping", "script": "ping -c1 google.com >/dev/null", "interval": "30s"}}' >/etc/consul.d/ping.json
@ -40,11 +39,14 @@ $ echo '{"service": {"name": "web", "tags": ["rails"], "port": 80,
The first definition adds a host-level check named "ping". This check runs The first definition adds a host-level check named "ping". This check runs
on a 30 second interval, invoking `ping -c1 google.com`. If the command on a 30 second interval, invoking `ping -c1 google.com`. If the command
exits with a non-zero exit code, then the node will be flagged unhealthy. exits with a non-zero exit code, then the node will be flagged unhealthy.
This is the contract for any `script`-based health check.
The second command modifies the web service and adds a check that uses The second command modifies the service named `web`, adding a check that sends a
curl every 10 seconds to verify that the web server is running. request every 10 seconds via curl to verify that the web server is accessible.
As with the host-level health check, if the script exits with a non-zero exit code,
the service will be flagged unhealthy.
Restart the second agent, or send a `SIGHUP` to it. We should now see the Now restart the second agent or send it a `SIGHUP` signal. You should now see the
following log lines: following log lines:
```text ```text
@ -59,24 +61,24 @@ following log lines:
The first few log lines indicate that the agent has synced the new The first few log lines indicate that the agent has synced the new
definitions. The last line indicates that the check we added for definitions. The last line indicates that the check we added for
the `web` service is critical. This is because we're not actually running the `web` service is critical. This is because we're not actually running
a web server and the curl test is failing! a web server, so the curl test is failing!
## Checking Health Status ## Checking Health Status
Now that we've added some simple checks, we can use the HTTP API to check Now that we've added some simple checks, we can use the HTTP API to inspect
them. First, we can look for any failing checks. You can run this curl them. First, we can look for any failing checks using this command (note, this
on either node: can be run on either node):
```text ```text
$ curl http://localhost:8500/v1/health/state/critical $ curl http://localhost:8500/v1/health/state/critical
[{"Node":"agent-two","CheckID":"service:web","Name":"Service 'web' check","Status":"critical","Notes":"","ServiceID":"web","ServiceName":"web"}] [{"Node":"agent-two","CheckID":"service:web","Name":"Service 'web' check","Status":"critical","Notes":"","ServiceID":"web","ServiceName":"web"}]
``` ```
We can see that there is only a single check in the `critical` state, which is We can see that there is only a single check, our `web` service check, in the
our `web` service check. `critical` state.
Additionally, we can attempt to query the web service using DNS. Consul Additionally, we can attempt to query the web service using DNS. Consul
will not return any results, since the service is unhealthy: will not return any results since the service is unhealthy:
```text ```text
dig @127.0.0.1 -p 8600 web.service.consul dig @127.0.0.1 -p 8600 web.service.consul
@ -86,9 +88,9 @@ dig @127.0.0.1 -p 8600 web.service.consul
;web.service.consul. IN A ;web.service.consul. IN A
``` ```
This section should have shown that checks can be easily added. Check definitions In this section, you learned how easy it is to add health checks. Check definitions
can be updated by changing configuration files and sending a `SIGHUP` to the agent. can be updated by changing configuration files and sending a `SIGHUP` to the agent.
Alternatively the HTTP API can be used to add, remove and modify checks dynamically. Alternatively, the HTTP API can be used to add, remove, and modify checks dynamically.
The API allows for a "dead man's switch" or [TTL based check](/docs/agent/checks.html). The API also allows for a "dead man's switch", a [TTL-based check](/docs/agent/checks.html).
TTL checks can be used to integrate an application more tightly with Consul, enabling TTL checks can be used to integrate an application more tightly with Consul, enabling
business logic to be evaluated as part of passing a check. business logic to be evaluated as part of assessing the state of the check.