Getting Rackspace Autoscale to Run in LON Datacenter Based on Event Triggers

Autoscale is an awesome product offered by Rackspace Cloud Servers, but configuring to execute via an event trigger does take some work. This is a guide to the process that aims to clarify the process outlined by this guide.

Many parts of this guide are copied from the above KC article. Thanks to Racker Shane C for the original guide.

This is assuming that you are either working on a linux distro desktop or a VM. If you don’t have this set up, please do so. I recommend Arch! www.archlinux.org

First install httpsie, since we are going to have to make API calls, event triggers cannot be configured with the control panel.  (I got mine via yaourt)

Then CURL to get your group id and X-Auth-Token to make API calls:

curl http://identity.api.rackspacecloud.com/v2.0/tokens \
 -X POST \
 -d '{"auth":{"RAX-KSKEY:apiKeyCredentials":{"username":"YourUserName","apiKey":"YourAPIKey"}}}' \
 -H "Content-type: application/json" \
 | python -m json.tool

You’ll get a long response, look for this:

"token": {
 "RAX-AUTH:authenticatedBy": [
 "APIKEY"
 ],
 "expires": "2016-05-13T16:55:12.537Z",
 "id": "AAC2K5ILbUHkMgXz_vpkRstsNgivBNIeuu0970987ee88e4mGcApywuyo9daGDawTAJXnnwjI5UyDQpOXm4qJT8PdBOEeDtMorbNfEg9EoJDB0dw0FO5SxQr86uvHQUC4eTaQ",
 "tenant": {
 "id": "10099999",
 "name": "10099999"
 }
 },

The big long string one is your token and the “id” is the tenant ID, copy them and run:

https get http://lon.autoscale.api.rackspacecloud.com/v1.0/YourID/groups X-Auth-Token:YourCrazyLongToken

The next step will basically add the webhooks to build and delete servers. These cannot be added via the control panel, hence using the API.

This part is the same as the original guide:

Next we will create the scaling UP policy webhook. I like to put JSON in a file then pass this file to our API call. Create create_policy_up.json and paste this JSON data, edit as needed. Change is how many Cloud Servers to scale up with a cooldown of 900s.

[
 {
 "name": "Scale UP",
 "change": 1,
 "cooldown": 900,
 "type": "webhook"
 }
 ]
https post http://iad.autoscale.api.rackspacecloud.com/v1.0/$TENANTID/groups/$GROUPID/policies X-Auth-Token:$TOKEN < create_policy_up.json

We make another file with our JSON data and create a scaling DOWN policy webhook. Create create_policy_down.json and paste this JSON data, edit as needed. Change is how many Cloud Servers to scale down (delete) with a cooldown of 600s.

[
 {
 "name": "Scale DOWN",
 "change": -1,
 "cooldown": 600,
 "type": "webhook"
 }
 ]
https post http://iad.autoscale.api.rackspacecloud.com/v1.0/$TENANTID/groups/$GROUPID/policies X-Auth-Token:$TOKEN < create_policy_down.json

Now we create the webhook URLs that Cloud Monitoring (Nagios, New Relic) can use to trigger the scaling events. Create create_webhook_up.json and create_webhook_down.json with this JSON data, edit as needed.

 [
 {
 "metadata": {
 "notes": "Cloud Monitoring will fire this webhook and scale UP"
 },
 "name": "Cloud Monitoring Webhook - UP"
 }
 ]
https post http://iad.autoscale.api.rackspacecloud.com/v1.0/$TENANTID/groups/$GROUPID/policies/$POLICYUPID/webhooks X-Auth-Token:$TOKEN < create_webhook_up.json
[
 {
 "metadata": {
 "notes": "Cloud Monitoring will fire this webhook and scale DOWN"
 },
 "name": "Cloud Monitoring Webhook - DOWN"
 }
 ]
https post http://iad.autoscale.api.rackspacecloud.com/v1.0/$TENANTID/groups/$GROUPID/policies/$POLICYDOWNID/webhooks X-Auth-Token:$TOKEN < create_webhook_down.json

Your Auto Scale group, policy and webhooks should now be set. Next, we need to configure Cloud Monitoring to use these webhooks we created to then trigger our scaling up or down policy.

Download and install raxmod: (http://github.com/racker/rackspace-monitoring-cli/archive/master.zip)
Again, you best be using Linux or at least a VM.

Utility can be installed using pip:

$ sudo pip install rackspace-monitoring-cli

Then create a config file: ~/.raxrc

[credentials]
 username=foo
 api_key=bar

[api]
 url=http://monitoring.api.rackspacecloud.com/v1.0

[auth_api]
 url=http://identity.api.rackspacecloud.com/v2.0/tokens

[ssl]
 verify=true

Now we can run commands on raxmon, yay!

Cloud Monitoring configuration

We first need to setup a notification for up, down and email. Use the webhook URLs we created for the up and down notifications.

$ raxmon-notifications-create --label=autoscaleUP-notification --type=webhook --details=url=http://iad.autoscale.api.rackspacecloud.com/v1.0/execute/1/46260ec2ee8fa1f1dcc6404c5ef01ad6fb1ad5a4f17c8cf3b521edc1cedbb7fd/
Resource created. ID: nteacRqyed (COPY THIS ID SOMEWHERE, we will need it in a bit)
$ raxmon-notifications-create --label=autoscaleDOWN-notification --type=webhook --details=url=http://iad.autoscale.api.rackspacecloud.com/v1.0/execute/1/452ab958f503dec27dca502b3a829c5784db1c84ff7ad76c2e50446301f386b2/
Resource created. ID: ntVzEPokKs (SAME, copy it)

This is optional but when our scaling up/down policies trigger I also want an email for these critical/ok alerts. (DO IT)

$ raxmon-notifications-create --label "autoscale-email" --type=email --details=address=youremail@domain.com
Resource created. ID: ntsUwpwLg6 (AGAIN, copy)

This next command tells Cloud Monitoring to create a new notification plan “Autoscale-Notification-Plan”, and when this plan is selected as the notification on Cloud Monitoring checks, trigger the scaling up policy on critical alerts and trigger the scaling down policy when the check recovers to OK. We add the email resource ID ntsUwpwLg6 so it will also send an email with the alerts.

(NOTE, replace the ID numbers after –critical-state with the ones above. The first is the UP number, and the second is the email ID, and after –ok-state the first is DOWN and the second is the email ID.)

$ raxmon-notification-plans-create --label "Autoscale-Notification-Plan" --critical-state nteacRqyed,ntsUwpwLg6 --ok-state ntVzEPokKs,ntsUwpwLg6
Resource created. ID: npP1qUz46q

Almost done, now go back to your Cloud Server and create a monitoring check, CPU for example, and for the “Send Alarms to” drop down menu, select “Autoscale-Notification-Plan”. Now when this monitoring check goes critical it will trigger our scaling up policy, and when it recovers back to OK, it will trigger the scaling down policy.

You will want to simulate some Critical/OK alerts to trigger these events and see how Auto Scale responds. Some things you can play around with are min/max servers, percentage based scaling, cooldown timing and making sure your new resources are responding properly once active.

These webhooks we created can also be used in your own monitoring with Nagios or any third party monitoring tool if they can utilize webhooks. Hopefully this guide gives some insight into how you can use webhooks and Cloud Monitoring to trigger Auto Scale.

Here’s hoping this guide makes things clearer.

Leave a Reply

Your email address will not be published. Required fields are marked *