Playing with competition data from SparkFun’s Free Day

Yesterday, SparkFun Electronics had their annual Free Day, where this year they gave away $200,000 in credit to their customers just because they felt like it.

The Metricfire founders are big fans of SparkFun, we both love electronics and tinkering. One of my desks is covered in microcontrollers and other components. When I’m not working on Metricfire, I’m soldering! (Or ordering parts from SparkFun…)

This year, people entered the competition to win a $100 credit by repeatedly solving captchas to prove their humanity. The competition was set to run for several hours. Several hours solving captchas? That sucks. A lot of people are going to get bored after a few minutes and wander away, but many will come back. If I don’t want to spend several hours solving infuriating captchas, can I figure out the best time for me to compete?

Wait... this is to prove I'm *not* a robot?

The answer is yes, we can work it out! SparkFun published some live statistics about the number of winning and losing attempts using Pachube. This is cool, but I didn’t find the graphs very useful. Here’s what it looked like:

That’s cool, but not very useful. It’s vanity data, and not even very pretty. We can do better and pull some meaning out it. I set about scraping this data from Pachube and getting it into Metricfire where I can better work with it.

After some quick tinkering in Python and applying some data transformations in Metricfire here’s what I ended up with:

Much better. Now can I see some trends in that data. Most importantly, I had a graph of how tough the competition was as people entered/left:

I used this graph to figure out when I should invest a few minutes in solving captchas. It looks like the best chance of winning was almost 0.06%, about five and a half hours into the competition. Watching this graph change as the day went on was fascinating – a little like watching a stock market graph.

I didn’t win anything from Free Day this year, but I had a lot of fun crunching the numbers during the event. Metricfire was a big help with that – once I decided I wanted a graph of something, it was only a couple of lines of code to get my data into the service and on a graph. This is why Metricfire exists.

- Charlie


Metricfire at PyCon 2012

Pycon!Here at Metricfire, we’re big fans of Python. Charlie’s been using it in everything from web apps to bizarre hardware hackery. Dave spent over a decade of writing Java code (mostly) for other people and Python turned out to be the light at the end of the tunnel that allowed him to actually enjoy writing code again.

We can’t wait to get down to the Santa Clara convention center from March 7th to the 15th – and as of this blog post there are still early bird tickets available:

Hit us up if you want to talk about how we can help you measure and scale your technology, or just if you want to grab a beer.



New Features – Data Transformations and Graph Cosmetics

We’re rolling out new features at a regular pace here at Metricfire, and we’ve just added two we’re particularly pleased with – Data Transformations and some basic graph cosmetics.

The transformations option allows you to alter each point of data from the metrics you’ve sent to us in a way that’s useful to you.

These options let you:

  • scale – Apply a coefficient of your choosing to each point
  • timeshift  – Retrieve the data for this metric from a period of time in the past (Seconds, minutes, hours, days, months)
  • derivative – Calculate the change between each value
  • integral – Add successive values together
  • movingaverage  – Calculate a moving average over a supplied time period.

For example, let’s say you’re comparing two different hypothetical metrics with vastly different ranges:

  • The bytes received per second over your network interface
  • The number of packets received per second over the same interface

At their base levels, mapping this data is not very useful – the data units are too different to make sense:

The blue line representing the packets per second has a useful relationship to the bytes received but at this resolution you’ll never know.

We add in our Scaling factor – our new interface will highlight correct syntax as you type:

Scaling the data to ranges closer to each other will give you something that will let you compare:

Well, that makes more sense...

Cosmetic enhancements

In addition to things to allow you to manipulate the data you’re sending to Metricfire, we’ve added the ability to customize the look and feel of your graph:

  • Line width and Color
  • Line vs Stacked Area Graphs
  • Display / Hide the graph legend

This can produce some attractive-looking graphs, (even if the end result in this case is only good for trolling your co-founder).




Why Metricfire Exists

Why Metricfire?

Our aim is to build a service designed from the ground up to measure high-volume systems accurately and to provide users with an interface that is responsive and flexible. We’re engineers and we’re trying to make something engineers will like.

We started Metricfire after trying to measure high-volume applications using existing tools. While we could eventually get the type of data we wanted, it usually meant going through the pain of combining different systems together, and then trying to force it to give us results it wasn’t designed for.

What’s wrong with existing tools? Well, we’ve gone through painful installation processes that take far too long for too little in return. Often, you’re presented with an interface that looks like the designs of a deranged Brutalist architect. Anyone who has worked with OpenTSDB or Graphite might be able to sympathize – certainly they work, but with all that has improved in web applications I think we can hope for far better.

If you want to tack on alerting with a tool like Nagios, sure, you can do it pretty simply, but is it reliable? Is it smart enough to know what else is going wrong at the same time? How do you monitor your monitoring? Is your Graphite service redundant? Does it scale to hundreds of thousands of metrics? Who can justify devoting the resources to this to make it reliable enough to alert from?

All these problems should be solved by one tool and one service with an end-to-end view of your data, from where your application reports it to the point where we wake someone up in the night. A hodgepodge of services will never make this as smooth and pretty as we’re going to make it.

These are all problems you shouldn’t have to care about, but we want to care about them for you.

Try Metricfire. We want to hear from you.