Sometimes making an alarm is the best thing you can do for yourself when working with Amazon Web Services.
Sometimes things can go wrong with your cloud computing installation, and it would be a great idea to know what is happening with your cloud systems. We simply cannot have the console open 24X7 to monitor what is happening with our systems, and creating simple Cloud Watch alarms can help you keep track of performance, billing and use issues that might otherwise go unnoticed in the general day to day chaos that is your IT Department.
This video is a quick overview and how to in using Amazon Web Services Cloud Watch and is part of the Cloud Computing course I am teaching here in Seattle. Feel free to share, fold, spindle and comment on this video so I can get a better idea of what you would like to see when it comes down to working with your Cloud installations in Amazon. In the longer run, building your own alarms to suit your own needs is the best way of going about monitoring your own cloud. But there are also some 3000 alerts, alarms, and settings that you can use right out of the box to help you get started.
One caveat though, there is always one thing to be aware of, Cloud Watch can be fairly primitive when it comes to how it works, we are looking at averages over time, or spikes in behavior, or over running your billing allowance for the month. These are not going to be detailed in depth reports like you would get with an Enterprise Resource Management tool. If you are deeply embedded in the cloud, it would be best to connect to a VPN and use some sort of ERM (Enterprise Resource Management) tool to get better alerting, alarming, and knowledge of what is happening in your cloud distribution.
Sometimes creating an alarm is not enough, you need to know how to interpret those alarms that you created. This is part of a lecture series I am doing in Cloud Computing over here in Seattle.
Alarms are awesome, it is always good to know what is happening in your cloud environment, but now that you have created an alarm in the previous entry, how do you interpret those alarms against something you really need to worry about. When starting out creating alarms, we tend to overestimate the things that should worry us. We also tend to set alarms that do not take into account how the cloud is being used by you or your company. Knowing what the systems are going to be used for is one of the more important things you should know about when it comes to setting alarms.
You should make sure that if you set minimum alerts with your systems that you take into account what happens when you spin down that system. If your alarm status has no data, it might not have had enough time to collect data because you are doing an average over time. If your alarm status was set for high use and you spin up a windows 2008 instance (with an initial spike of 5 gigs and 100% cpu utilization) your alarm might go off because it hit a spike load that you were tracking.
Always be aware that sometimes you set an alarm as a good idea, but you need to understand what is a spike, what is average use, what is exceptional use when working with your Cloud Watch alarms.
(Cross-posted @ Hacking Cloud Computing)
Nice video – it gives a great start to using CloudWatch.