Updating doc links to latest URLs

docs/custom_client_config.md

@@ -1,5 +1,5 @@
 # Custom Client Configuration
-When this Ansible role deploys the Sensu client configuration - defined in `client.json` in the Sensu configuration directory, it works out [subscriptions](https://sensuapp.org/docs/0.18/clients#definition-attributes) based on group membership within the Ansible inventory.
+When this Ansible role deploys the Sensu client configuration - defined in `client.json` in the Sensu configuration directory, it works out [subscriptions](https://sensuapp.org/docs/0.21/clients#definition-attributes) based on group membership within the Ansible inventory.
 For example, if you have a `webservers` group within your Ansible inventory, any nodes listed in that group will automatically gain a subscription to `webservers` within Sensu.
 This is quite a powerful, convenient feature. It's coupled with the deployment of [checks](https://sensuapp.org/docs/0.18/checks). If you add a new webserver to your infrastructure, Sensu will dynamically pick it up, subscribe it to 'webservers', and deploy webserver checks, without you having to do anything other than add that node into the `webservers` group within your Ansible inventory. Instantaneous monitoring of your web services!
 

docs/deploy_plugins.md

@@ -1,7 +1,7 @@
 # Deployment of Handlers, Filters, and Mutators
 _Note:_ _If you haven't familiarized yourself with the concept of the static data store please read_['_Dynamic check deployment'_](dynamic_checks.md)
 
-Deployment of [handlers](https://sensuapp.org/docs/0.18/handlers), [filters](https://sensuapp.org/docs/0.18/filters), and [mutators](https://sensuapp.org/docs/0.18/mutators) is handled by leveraging templates and other data placed in the static data store.
+Deployment of [handlers](https://sensuapp.org/docs/0.21/handlers), [filters](https://sensuapp.org/docs/0.18/filters), and [mutators](https://sensuapp.org/docs/0.18/mutators) is handled by leveraging templates and other data placed in the static data store.
 
 ## Static data store hierarchy with respect to handlers/filters/mutators
 To deploy your handlers, filters, and mutators, you'll need to have directories named after each under a directory called 'sensu' in your static data store:
@@ -28,7 +28,7 @@ data/static
 All three are deployed using Ansible's [template]() module. This allows the use of variables within your configurations, which can come in quite handy!
 
 Let's take a look at the stuff I've got for [Pushover](https://pushover.net/).
-First off, the [handler](https://sensuapp.org/docs/0.18/getting-started-with-handlers) json file `pushover_handler.json.j2`:
+First off, the [handler](https://sensuapp.org/docs/0.21/getting-started-with-handlers) json file `pushover_handler.json.j2`:
 ``` json
 {
   "handlers": {

docs/dynamic_checks.md

@@ -1,5 +1,5 @@
 # Dynamic Check Deployment
-One of the awesome features of this role (if I do say so myself) is the deployment of Sensu [checks](https://sensuapp.org/docs/0.18/checks) on a dynamic basis. Deployment of which checks should be distributed to which nodes is determined from group membership within the Ansible inventory.
+One of the awesome features of this role (if I do say so myself) is the deployment of Sensu [checks](https://sensuapp.org/docs/0.21/checks) on a dynamic basis. Deployment of which checks should be distributed to which nodes is determined from group membership within the Ansible inventory.
 
 Have a group of webservers you need to monitor webservices on? Well, I'm sure you've bunched them together in your inventory under the `[webservers]` group, right? Or perhaps you only want to monitor disk space on your production systems; if they're a member of `[production]` within the inventory, you can do this easily.
 
@@ -69,7 +69,7 @@ tater.cmacr.ae
 web.cmacr.ae
 test.cmacr.ae
 ```
-Under these subdirectories, you can see [checks](https://sensuapp.org/docs/0.18/checks) that relate to directory they're placed in.
+Under these subdirectories, you can see [checks](https://sensuapp.org/docs/0.21/checks) that relate to directory they're placed in.
 The `webservers` subdirectory includes a `check_nginx.sh` script, whilst the `rabbitmq_servers` subdirectory has one that most likely checks for RabbitMQ problems (it does... trust me).  
 
 So how do these checks actually get deployed to their associated nodes?