Were you aware that with Cloud Monitoring you could monitor any of your servers? No, really, any server, anywhere! It does not matter if they’re hosted on the Rackspace Public Cloud, if they’re Rackspace Dedicated Servers, if they’re in your data centers, or even another providers’ data centers. This means you can even monitor the servers already running on your existing Rackspace Private Cloud!
So what does it take to setup Cloud Monitoring on Rackspace Private Cloud? Well, let’s take a step back and set the scene before we jump into the specifics:
Project Touchstone is a new, internal, and open source project at Rackspace. Its purpose is to showcase proper cloud architecture, concrete examples of how to consume various cloud resources, and how to orchestrate your stack, which when combined, allows for a scalable and efficient infrastructure.
In Touchstone, there is an example project named “Encoder” that provides you with the ability to convert specified video files into other consumable media formats, which are then stored on Cloud Files for future download. The encoder project is a three-tier webapp that is designed as decoupled in responsibility and resources right from the start. By doing so, we empower ourselves with the ability to scale out each of its individual components as usage and load increases.
In the encoder project, there is one resource in particular that we care to monitor and analyze closely: the data worker. This component is the one node that is in charge of performing the conversions in between video formats, where as the rest of the nodes primarily provide the capabilities to run the actual webapp.
Because video conversion is so exhaustive on the CPU, we want to create an email alert that notifies us when the load average on the data worker passes a certain threshold, as this is an indication that special attention is required. We’d also like to be notified when the system has been restored to normal operating conditions.
The Getting Started with Rackspace Monitoring CLI provides summary of the technical documentation that walks you through setting up the monitoring agent, the overarching concepts of the monitoring service and then actually utilizing it. The specific install and configuration of the monitoring service for the data worker, including the notification and alarm we create, can be found in its install script. When successfully run, the install of the agent, creation of the load average check, notification, notification plan and alarm resembles the following:
After the agent has been running, you can view graphical visualizations for the recently created “check” as well as the metrics it reports on Cloud Intelligence. The following is the graph for the one-minute metric of the CPU load average check:
Now that we’ve established that the check is operational, you can submit a video to be encoded into a multitude of formats available by the webapp. With our one-minute refresh rate set in our alert, we begin to see the activity of the CPU load average reflect the recently incurred load from the encoding process:
Soon thereafter, at the peak of its computational tax from the conversion, the load average spikes up well beyond the threshold of 0.70 that we’ve established to be alerted on:
Within seconds, we receive an email notification due to the recent spike in activity as we’ve requested. Though it is not a part of this article or project, in this scenario, it is implied that the proper actions needed to subside the load or further scale the infrastructure out would be a great next step.
As soon as the encoding completes and the CPU load average decreases, we can view the graphs indicating that the load average has returned to optimal and accepted levels as well as an email in case we are not actively viewing the visualizations:
This is just the beginning of what you can achieve with Cloud Monitoring on your stack within Rackspace Private Cloud. For further information, feedback, or assistance, please visit our Private Cloud forum.