DevOps Zone is brought to you in partnership with:

I'm a writer, programmer, web developer, and entrepreneur. Preona is my current startup that began its life as the team developing Twitulater. Our goal is to create a set of applications for the emerging Synaptic Web, which would rank real-time information streams in near real time, all along reading its user behaviour and understanding how to intelligently react to it. Swizec is a DZone MVB and is not an employee of DZone and has posted 65 posts at DZone. You can read more from them at their website. View Full User Profile

Making StatsD Talk Directly to a Browser

08.09.2012
| 4934 views |
  • submit to reddit

StatsD is “A network daemon that runs on the Node.js platform and listens for statistics, like counters and timers, sent over UDP and sends aggregates to one or more pluggable backend services.”

I’ve previously mentioned StatsD in Your startup needs a dashboard, over at Zemanta’s fruitblog.

The idea behind StatsD is this:

  1. Stuff happens
  2. Send metrics of “stuff” to a central service (StatsD)
  3. StatsD acts as a buffer, forwarding aggregated metrics every X seconds

Your architecture now has a central service that collects all of your metrics. It then pushes them to appropriate software that doesn’t need to handle too much traffic and is guaranteed data will come from a single source in a sanitized format.

A software architect's dream

A software architect's dream.

Straight from the browser?

Collecting data into StatsD works wonderfully. It’s fast, reliable, extremely robust and you can give it just about any data you can think of.

Unless your client is a browser.

See, StatsD only accepts UDP packets and browsers that don’t let you send UDP packets. There’s a valid excuse for this – it doesn’t matter if some packets are lost, as long as whatever you’re measuring isn’t slowed down by the measuring.

To solve this I created a simple proxy in node.js. It accepts normal HTTP requests and pushes data onward to StatsD. The simplicity, I hope, ensures speed.

The API is a simple tracking pixel:

<img src="http://<address>?t=<type>&v=<value>&b=<bucket>" />

Where type is one of c (counter), t (timer), g (gauge). As in the per StatsD naming convention. And bucket is simply the name of your metric.

The source is on github. Feel free to use it.

Straight to the browser

Ok, so now we can collect data from the browser, but I want to send it directly to a browser as well. None of that Graphite stuff – I want to use some other fancy graphs and visualisations. Just because.

To solve this problem, I implemented a socket.io backend for StatsD. It, also, can be found on github -> https://github.com/etsy/statsd/pull/102

I hope the pull request gets merged soon, or at all for that matter. I really think this is a useful addition to StatsD because it means you can use whatever client-side javascript you want to do visualisations, in near real-time and all that.

The data is sent over in a simple format:

{perSecond: {bucket1: 0.2,
             bucket2: 0.1
             },
 counts: {bucket1: 2,
          bucket2: 1
         },
 timers: {timer1: {upper: 2.4,
                   lower: 1.2,
                   count: 10}
         },
 gauges: {gauge1: 10
          },
 statsd: {numStats: 6},
 timestamp: <unix timestamp>}

The goal?

If all goes well, I will soon be able to use cubism.js to draw a pretty timeseries of the traffic on this blog. And hey, who knows what else I can think of to add to a personal dashboard of my life … I now have the basic framework. Time to start using it.

Cubism.js makes shiny timeseries

Published at DZone with permission of Swizec Teller, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)