A couple of weeks ago, we presented a short (~15m) talk about how we use Node.js to render Javascript charts to SVG and PNG images.

At this event, we announced three things:

• Open sourcing Dali, our daemon for executing Highcharts
• Open sourcing deb-npm-autopackage, a little script for making .deb packages from npm modules
• Our official Node.js client for Metricfire

Sorry about the poor audio – hopefully we’ll have a better recording setup for the next event.

In case you’re wondering, yes, that is our Big Red Button being used as a slide advancing tool. :D

We get a lot of questions about how we made it and how it talks to the computer. It’s about time we did a little show and tell, with lots of pictures and code!

Image from SparkFun.com - go buy one of their buttons!

The main element, the actual button, is one of SparkFun’s “Big Dome Push Button” units. Two of these have been sitting in Charlie’s electronics parts boxes for a year or so, waiting for just the right project.

Inside the button

PCB from a small USB numeric keypad

The second major component is deceptively simple and cheap – the PCB from a small USB numeric keypad. Modern membrane keyboards have a row of contacts that mate with the flexible plastic sheets with conductive traces that form the key contact points.

After some trial and error with a piece of wire, you can identify the pair of contacts that correspond to any key on the keyboard. If you solder those up to a big push-to-make switch, you’re basically done. A press of the big button will cause the controller board to send a USB keyboard event to the OS.

1W white LED on a custom mount

A little poking around with a multimeter will find you a good point on the PCB to pull 5v to power the light inside the button. Though SparkFun now sell a version with an LED, our one used an older incandescent bulb, which requires 12v and would probably draw more power than the keyboard controller was designed for. Charlie built a suitably shonky mount for a 1W white LED and it replaced the incandescent bulb.

Vinyl sticker inside the button

How’d we get our logo in there? We had some spare vinyl stickers for the backs of our macbooks, and one just happened to fit perfectly inside the button. If you need excellent decals/stickers, talk to Jeff and Neece of SmartDecals and tell them Metricfire sent you!

After that, the easy bit was making a wooden case for the whole thing. A grotty concrete-encrusted wooden plank turned out to make a solid enclosure, once it was cleaned up a bit!

Where’s the code?

As promised, there’s some code involved here. Sometimes, having the button appear to the OS as a regular HID keyboard is undesirable. When we’re demoing our (almost) real-time graphs and dashboards at events like Dublin Beta and PyCon, we don’t want button presses to be interpreted by the browser running the demo. We need something a little deeper catching those button presses so we can generate metric events.

For this, we use Python, libusb, and some hardcoded magic numbers. The code:

So there you go. If you’d like a Big Red Button of your own, you have complete instructions and sample code. Quick, to the workshop!

As with our other clients, this is a fast non-blocking client that will not compromise the speed of your application and allow you to send thousands of events per second.

We’ve already found our Node client useful – it helped us identify a memory leak:

This sort of “up and to the right” behaviour is desirable in many things, but not memory usage. The code for getting this data out of Node and sending it to Metricfire is very simple:

Our node.js client can be installed right from npm:

$ npm install metricfire

If you like documentation, you can find it on docs.metricfire.com, along with docs for all the other client libraries and the HTTP API.

Check out our free trial and see how you can easily measure and graph what’s happening in your application.

We’ve finally added an interface to quickly and easily determine which metrics are not used, and then delete them. A simple spark line chart will show whether the metric has been collecting data, and a summary screen will tell you whether it’s used on any graphs before you make a decision to remove it.

Just select “Apps and Data” from the main navigation menu and you’ll see all your applications, metrics, and a spark line of the data from each.  See our 30-day free trial and try it for yourself.

Image credit: stickermule.com

For the last few months we’ve been working with users on our beta list to tweak our features based on their feedback. We’re now ready to open our 30-day free trial to the public, and release details of our prices.

We’re building a tool aimed at developers who need the flexibility of instant metrics, but who either don’t want the trouble of setting up a server, or are in an environment where it’s just not possible for them. We have three paid plans, and we’re willing to talk to non-profits, students, or open source projects about free accounts.

Our developer plan is designed to provide enough metrics and capacity for any small project, with all the benefits of our fast client APIs, our HTTP API and embeddable graphs.

Our small business plan is designed to compete with the cost of buying or renting a server, then setting up a metrics tool, securing it, ensuring it’s backed up properly, tweaking the inevitable things that happen to a server over the course of a year and all the time that a sysadmin or devops person could be spending automating something else.

Our enterprise offering is designed as a fully hosted metrics service to rival a custom system, and it will handle as much as you want to send us. (Billions of data-points per day is no problem – talk to us!)

Some thoughts on why you might want to use a hosted version:

Take the cost of setting up an Amazon server which needs to run 24/7, getting a dedicated server rented, or racking and co-locating one of your own. Add on the time it takes your sysadmin to evaluate, install and then configure whatever metrics system you eventually decide on. Even if they’re some sort of ninja rock-star unicorn, that’s probably going to be a day of tinkering. You want it done right though, so they have to spend another day making sure it’s backed up properly, and that there’s a redundant copy somewhere so that all your delicious metrics don’t disappear into the void when something goes wrong. You’ve possibly doubled your server costs, and tacked on several expensive days of salary, but it’s done.

Now you’re finally ready to send some metrics! Fast-forward six months down the line and unfortunately you’ve run in to some sort of problem but the person who set up the metric collector is busy working on that important normal stuff that keeps your company making money. Or if we throw another spanner in the works, maybe they left the company, and someone now has to spend a few days figuring out how the system works – essentially starting from scratch?

We’ve been there, and it’s exactly why we started Metricfire. Replace the mess above with quick integration using a fast API that handles all the scaling, replication, and backups for you and save on time and money. We think it’s the way to go (even if we’re a little biased…). Try our free 30-day trial.

Thanks to the beta testers!

It took us a long time to get here, and we have to thank our beta testers for helping us get this far. We’re immensely grateful for your time and all the effort you put in to help us improve Metricfire. We’ve offered a discount via email to anyone who signed up to our beta, as well as stickers to anyone who wants ‘em (while they last…),  just drop us a mail with where you want your stickers sent!

- Dave and Charlie

The problem was that for a few days there were regular connection problems. The server running the bot couldn’t connect to the server hosting the status page. The error messages weren’t helpful – just connect() timeouts. To try to better understand the intermittent problem, I wanted to measure the latency and connectivity between these hosts on an ongoing basis.

The natural choice for long term latency measurement is, of course, SmokePing.

The only trouble is the amount of effort involved in installing SmokePing, configuring it, configuring a httpd to serve the content and run a Perl CGI, keep the content private, etc. None of that is hard, but it is certainly annoying and I was not interested. I wanted to measure latency between two machines, not spend a good half hour, if lucky, setting up all that.

So I used Metricfire instead. I wrote a one line snippet of shell script to make 20 ICMP ping requests, format the latency results, and send it to Metricfire’s HTTP API.

I handed that off to cron to run once a minute, and now you can see the complete recipe:

* * * * * curl -s https://my-api-key-redacted@api.metricfire.com/v1/m\
etric/smokecheap/tog-dot-ie --data-binary "[$(ping -c 20 tog.ie | awk \
'/bytes from/{print $8}' | cut -b6-10 | xargs | tr ' ' ',')]"

After a little clicking around, I had a graph of the min/avg/max latency between these two machines.

The whole thing took less than five minutes. It’s obviously not as complete as SmokePing, but it gave me the result I wanted with a fraction of the effort. 80% of the functionality with much less work. I’m pretty satisfied with that.

The twist to the story is that the intermittent connectivity problem disappeared before I got a chance to observe it! Definitely glad I didn’t set up SmokePing just for this. If it happens again I’ll be ready with this historical data to help me spot patterns.

- Charlie

"Boy, this is a lot bigger than the last PyCon I talked at... um..."

Within the first couple of minutes, I noticed that Paul was using so-called disfluencies such as “um” quite often. I wondered if he was a little nervous, but that didn’t seem likely for someone in his position. Was he going to get more comfortable later? Hard to know because I’d tune out the disfluencies as I listened so I couldn’t trust myself to notice the trend. To answer this silly question for myself, I decided I’d measure the occurrences of “um” and “uh” while I watched.

I whipped up a quick script to help me log this data and, of course, send it to Metricfire (via the HTTP API) so I can get a pretty graph.

Here’s what I found:

The X axis time labels do not match the talk video times, but when I happened to watch the video and log the datapoints.

During the main part of PG’s 32 minute talk, (excluding questions) it looks like he said “um” and “uh” just under 225 times. 224, to be exact. This isn’t very interesting in itself, but the consistent rate indicates that he probably wasn’t very nervous and that this is just his presentation style.

There are some small wobbles – the rate levelled off a bit when he was talking about killing Hollywood because this is clearly an issue he has given some thought to before. I suppose his thoughts were more organised on that topic and we see fewer disfluencies as a result. This is a logical and unsurprising conclusion, but it is interesting to see this visually in the data.

224 “um”s over 32 minutes is about 7 times per minute. How does this compare with other talks PG has given, and with other speakers? Do I use as many disfluencies? I don’t know. The next time I watch a PG talk I’ll repeat the experiment, and I’d be interested to see similar analysis done on other speakers and myself.

This isn’t exactly the high volume of backend application performance data Metricfire is intended to capture, but it was fun to think about. :)

- Charlie

Updated 12th March 13:35 PST: Adding Youtube video link because the PyCon video link isn’t working.

Updated 18th March 11:40 PST: Paul Graham writes about speaking skills.

Next to your graph’s action menu, you’ll find the new ‘Embed’ option, which will give you a URL to a static image of that graph. You can configure some simple options such as the image size and the format – we’re providing the graph data in PNG or SVG formats for you to play with. This URL is unauthenticated and you can use it anywhere, like embed it into your own dashboards, your back-end admin system, or put it on a big TV in your office.

The tech side of it is a slight departure from the rest of our codebase in that we’re using server-side javascript in the form of node.js to convert our existing front-end graphing tools into image data. What’s amazing (to me at least) is the amount of code reuse; with minimal code changes to our front-end javascript we can keep the rich interactive graph stuff in powerful browsers and also get simple images to embed anywhere.

Here’s what the embedding interface looks like:

Using the URL provided you get access to the resulting graph as an image:

The ability to embed graphs wherever you want is just one of many new features currently undergoing testing. Check out how we can help you measure application performance.

While we still use some of those tools today, we found ourselves wanting more – more information about the distribution of timing, more control over what’s being measured, a more intuitive user interface, and more real-time access to data when something’s going wrong.

 

We’re pleased to see that the reasons they moved away from existing tools, and the design decisions they made in their own system are not a million miles away from our own. We’re also using stats delivery over UDP, and instant aggregations of min, max, sum, observations, standard deviation – as well as data transformations baked in which make other statistical information like moving averages available without you having to mess with code.

We started Metricfire to solve the ‘Everything in One Place’ problem where you try to get several systems designed for different purposes working together to produce a holistic service that covers the whole problem. Generally, it either doesn’t work or just takes too long and leaves you with plenty of quirks to work around. We’re taking care of the entire chain, from where you want to know how a certain part of your app is performing, right up to the point at which you wake someone up in the middle of the night.

It’s interesting to get this sort of perspective (and validation) from a company like 37Signals. Let us know how we can help you get the same sort of application monitoring for your own systems.

Charlie spent some time at the Dublin BETA event the other night, and this sort of uncertainty was something we wanted to address right from the start. So how do you relate a back-end abstraction in a way that anyone can get? Well – here’s our attempt:

The analogy we’re trying to draw is that the button represents some misbehaving server lounging around out on the internet somewhere. Every time one of the people who stop by our demo booth hits the button, it’s mimicking this server doing something worth hearing about. In this instance we’re only recording the number and duration of button pushes, but it’s not a huge leap to grok that you can send just about any measurement you want – API response times, pots of coffee brewed per hour, number of failed user logins, or memory usage on your machine hitting some nasty threshold you would probably want to know about.

From our button pushes we put together a simple graph:

This is a collation of all the data taken on the night, our live graph reacted immediately to the button. It’s not the most complicated or detailed graph in existence, but it’s a very useful way for people who stop by our booth to get immediate feedback on what our software does. Overall the reaction was great, and numerous times it involved a “Oh! I have to get $X to come see this, he’s been looking for something to do this!”, which was encouraging.

We’re going to improve our button test for PyCon, stop by and give it a push!