Access whitepaper

Why I'm sticking with Zenoss for now

Friday, September 4, 2009 by james litton
Having recently moved our blog hosting infrastructure onto Amazon's EC2 cloud system, I have been debating reviewing our monitoring solution. We have been using Zenoss for about a year to serve both as a graphical system that is used for identifying potential problems as well as an alerting mechanism.

When I last looked into potential solutions I was most familiar with nagios having set it up a couple of times in the past, but I was lured into Zenoss due to the built-in graphical interface and the promise of a web API that I could use to automate addition and removal of nodes. As it turns out the API is not particularly easy to use and Zenoss has had several bugs over the past year some of which have cost me a significant amount of time.

Now that I've moved from a traditional co-lo to EC2 I am intrigued by CloudWatch, but not enough to switch. The reasons for this are primarily cost and flexibility. Running CloudWatch at ~$10/server/month quickly becomes a large expense when compared to $74/month for a single m1.small instance that can be used to monitor many servers at a fixed cost. Further, with that small instance running Zenoss, I can trigger alerts on anything thing that I like. I am not limited to the datapoints that CloudWatch monitors. 

In conclusion, if I were to be running only a couple of instances or I felt access to EC2 auto-scaling was a requirement, it might be worth the cost to run CloudWatch, but if you're running a large number of servers and are willing to give up auto-scaling(or build out a solution yourself or a 3rd party tool like rightscale), then CloudWatch just doesn't make sense right now.

Spread the Word

Comments for Why I'm sticking with Zenoss for now

Leave a comment





Captcha

© 2009 Compendium Blogware
All Rights Reserved