Quantcast

Archive for September, 2010

Integrating Graphite with Ganglia

Wednesday, September 29th, 2010

Some time ago I saw a demo on using Graphite (http://graphite.wikidot.com/). I was impressed by the ease of creating custom graphs and the quality/visual appeal of the graphs. Trouble was that Graphite uses it's own storage engine instead of RRD and I figured it may be too much work to figure out how to inject my existing Ganglia metrics.

Couple days ago I saw a tweet from Mike Brittain at Etsy on how Graphite is becoming one of his favorite graphing tools. I know that they use Ganglia at Etsy so I asked if/how they use integration between Graphite and Ganglia. He pointed me in the direction of Erik Kastner who has done Ganglia Graphite integration. I asked him if he could post the patches and he was gracious to do so. In a nutshell he uses RRD files directly and rsyncs them every few minutes. While trying to install Graphite I realized that injecting metrics into Graphite is really simple. For example graphite-web contains a simple client example that injects system load. All it does is connects to port 2003 of the graphite installation and sends a following payload

system.loadavg_1min 0.08 1285763852
system.loadavg_5min 0.02 1285763852
system.loadavg_15min 0.01 1285763852

That's simple :-) ie. some type of a metric name, value and what looks like current UNIX timestamp. I then remembered that Kostas Georgiou showed me a ruby script that connects to gmond, retrieves the XML for the host, parses it and adds to Facter. Unfortunately that didn't seem to have much value until now :-) . What I did  is change Kostas' script to send metrics to Graphite instead of adding them to facter. You can find the result at Ganglia Add-Ons GitHub repository. You can run the script either from cron or as a daemon.

There are two ways to do this. I have tested only the first way. I am not sure if the graphite receiver would freak out if it gets too many metrics in a payload. Let me know if you know :-) .

1. Run this script on every host that runs gmond. This may be somewhat tricky since I usually set up gmond to only send metrics and turn off receiving by setting deaf = yes. For this approach to work you have to turn on receiving. To make it more secure we'll just listen on loopback. In global make sure you have these settings

  mute = no
  deaf = no
In the rest of the section make sure you add/have
udp_send_channel {
  host = 127.0.0.1
  port = 8649
  ttl = 1
}
udp_recv_channel {
 bind = 127.0.0.1
 port = 8649
}
tcp_accept_channel {
   bind = 127.0.0.1
   port = 8649
}

2. Run this on the main gmond collector daemon. Main gmond collector daemon will have metrics from all hosts. Trouble is that I haven't tested injecting thousands of metrics in a single payload. I'm sure there is a way around it and perhaps someone can post a patch :-D .

Future Improvements

I can think of couple possible improvements

  1. There is a rewrite of gmetad written in Python. It supports plugins. I don't think it would be a stretch to add a plug-in where gmetad sends data to Graphite when it updates the RRDs
  2. Currently metrics are sent as <hostname>.<metric_name>. It may make sense to send them into the appropriate part of the tree ie. <type_of_metric>.<hostname>.<metric_name> e.g. database.web1.mysql_selects
  3. Better integrate Ganglia Web UI and Graphite. Graphite supports flexible URL parameters so this should be doable.

And obligatory screenshots. This is the stacked graph I created in 20 seconds :-)

Graphite view of Ganglia Metrics

EC2 micro instances cost analysis

Thursday, September 9th, 2010

Amazon today announced addition of EC2 micro instances which is their smallest instance size coming with 613 MB RAM and priced at $0.02/hour. You can read more about the announcement here

http://aws.typepad.com/aws/2010/09/new-amazon-ec2-micro-instances.html

There is a wrinkle though. There is no local (ephemeral) storage so you need to use EBS backed volumes. EBS is charged at $0.10/GB per month along with the charge of $0.10/1 million I/O requests to the volume. That is actually a reasonably good idea since it likely cuts down on I/O subsystem abuse since if you start abusing I/O it will cost you. That said I thought I would run a quick cost analysis to determine how much would it cost to actually run an instance. I have a personal server I use for handling my family's e-mail, blog and personal web sites. It gets little traffic. I use roughly 30 GB of storage. To find out the number of I/O ops I ran following command

> cat /proc/diskstats | egrep "sd[a-b] " | awk '{print $4" "$8}'
154756 3576927
773387 1844813

This lists number of both read and write ops for both drives in my machine. It adds to about 6 mil iops. Machine was last rebooted 7 days ago making this 25 mil iops per month. On the outbound network traffic side I have consumed 5 GB of traffic so far so => 20 GB per month (charged at $0.15/GB).

Thus the cost breaks down like this per month

Instance cost (30*24*$0.02) = $14.40

EBS storage charge ( 30 * $0.10) = $3.00

EBS I/O ops charge ( 25 * $0.10)  = $2.50

Outbound network traffic ( 20 * $0.15 ) = $3.00

Total: $22.90

Not too bad. A word of warning though. Since these micro instances come with only 613 MB of RAM if you load even a handful of services such as a mySQL database, web or app server you may end up swapping causing your EBS I/O ops charges to go up. I doubt these would be enormous however depending on the level of swapping they could be 25, 50% or 100% higher than what you planned for. Obviously EBS has some nice features such as persistency, snapshotting and ability to boot instances automatically after a failure however it may come with unanticipated cost.

Update: Some have pointed out that instance costs can be even lower if you reserve (assuming 1-yr commit micro instances are $115/year vs. $172 non-reserved). That is true however as I point out the biggest X factor in the whole equation is EBS charges. It's nothing that will break the bank however I prefer having idea upfront what the cost is. If your use case is a DNS server, mail server, Nagios checker than this fits the bill well however if you plan to use a ticketing system, wiki that uses a DB backend you will likely exceed memory footprint and start swapping.

Install Openstack Nova easily using Chef and Nova-Solo

Wednesday, September 1st, 2010

Inspired by Cloudscaling's Swift-Solo and being excited about being able to create my own cloud I am announcing the Nova-Solo project. Openstack Nova is the Compute portion of the project trying to build open source stack to run Amazon EC2 type service. Nova-Solo is a set of Opscode Chef recipes that allow you to quickly get most parts of the Nova stack up and running. You can fetch it from Github at

http://github.com/vvuksan/nova-solo

At this time Nova-Solo is targeted for Ubuntu 10.04 and it relies on Soren Hansen's package repository to install all of the necessary packages. Following Nova services are installed

  • Cloud controller
  • Object store
  • Volume store
  • API server
  • Compute Server

Soren's package archive is a bit outdated so some of the things don't work. For example you can create users, generate credentials, upload files into buckets but you can't register the image. Soren has said he is in the process of building new packages and I am also in the process of doing the same so hopefully things improve quickly. Nova code is definitely alphaish so beware. To get started use git to clone the nova-solo repository and off you go

git clone git://github.com/vvuksan/nova-solo.git

In the future as things stabilize we'll be making adjustments to support multiple compute servers (pieces for it are already in Nova-Solo), support other distributions like RHEL/Centos, etc.


Switch to our mobile site