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, forwards aggregated metrics every X seconds

Your architecture now has a central service that collects all of your metrics, 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 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 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 backend for StatsD. It, also, can be found on github ->

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 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
Enhanced by Zemanta

Learned something new? Want to become a better engineer? 💌

Join 9,400+ people just like you already improving their skills.

Here's how it works 👇

Leave your email and I'll send you an Interactive Modern JavaScript Cheatsheet 📖 right away. After that you'll get a thoughtfully written email every week about React, JavaScript,  and lessons learned in my 20 years of writing code for companies ranging from tiny startups to Fortune5 behemoths.

Man, I love your way of writing these newsletters. Often very relatable and funny perspectives about the mundane struggles of a dev. Lightens up my day. ~ Kostas

PS: You should also follow me on twitter 👉 here.
It's where I go to shoot the shit about programming.