New Feature – Graph Image Embedding

While we’re delighted if you want to use our dashboards for your reporting needs, we also realize that a lot of people have their own internal reporting and dashboarding setups, or just want to share a graph quickly with someone else.

Metricfire embed menu option 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:

Metricfire - Example embedded graph







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.

37Signals on Metrics

37signals Logo37Signals had a fantastic blog post last week detailing their internal metrics service they use for all their products. After using a larger stats package, they moved to a custom system for all of the reasons that we’ve created Metricfire:

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.

How do you demo back-end technology to less technical people?

When we tell people we’re enabling developers to measure the performance of their systems, we get a range of reactions. Developers dive into the technical questions – Will it slow down my app? Do you have a client library in $FAVOURITE_LANGUAGE? Non-techie people just get a sort of faraway look on their face where presumably they’re trying to figure out what the hell a cloud service is, or why people need to measure things, or if all this stuff has something to do with the internet.

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:

Metricfire's Big Red ButtonThe 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:

Metricfire Button Presses at Dublin BetaThis 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!