{"id":558,"date":"2013-01-18T09:28:02","date_gmt":"2013-01-18T08:28:02","guid":{"rendered":"http:\/\/www.streppone.it\/cosimo\/blog\/?p=558"},"modified":"2013-02-19T18:29:26","modified_gmt":"2013-02-19T17:29:26","slug":"net-statsd-server-perl-port-of-flickr-etsy-statsd","status":"publish","type":"post","link":"https:\/\/www.streppone.it\/cosimo\/blog\/2013\/01\/net-statsd-server-perl-port-of-flickr-etsy-statsd\/","title":{"rendered":"Net::Statsd::Server, a Perl port of Flickr\/Etsy’s statsd"},"content":{"rendered":"

If you’re looking for a Perl client to connect to a statsd<\/b> daemon, checkout Net::Statsd on CPAN<\/a>, now at version 0.08.<\/p>\n

This post is about the server<\/b> component of statsd<\/a>.<\/p>\n

Tracking metrics: up to now<\/h2>\n

The idea of statsd started in Flickr by Cal Henderson, and some code is still available<\/a>, but it’s not very functional or complete.<\/p>\n

Since reading about statsd, I found the concept brilliant. I have been using a similar technique long before hearing about statsd though. I learned it from colleagues here at Opera in 2008. They were using it to track application metrics for the Opera Link server. I thought it was great, so I also implemented it, extending it by making it very easy to add metrics and to see the output automatically in Munin. Here’s how it worked basically:<\/p>\n

# ...
\nuse Opera::Stats;
\n# ...
\nOpera::Stats::count(\"site.logins\");
\n# ...
\n<\/code><\/p>\n

The project code would have typically tens or hundreds of these calls. Each call would store\/increment a counter in a local or remote memcached. Then a complementary Opera::Stats::Munin<\/code> module would automatically generate the output needed to implement a full Munin plugin given the metrics to be exposed.<\/p>\n

So far, so good. Except there were a few things that didn’t work quite right<\/b>:<\/p>\n