Over a million developers have joined DZone.

Making StatsD Talk Directly to a Browser

DZone's Guide to

Making StatsD Talk Directly to a Browser

· DevOps Zone ·
Free Resource

Learn how integrating security into DevOps to deliver "DevSecOps" requires changing mindsets, processes and technology.

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

Learn how enterprises are using tools to automate security in their DevOps toolchain with these DevSecOps Reference Architectures.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}