Announcing pricing and general availability!

Image credit:

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



Replacing SmokePing with a very small shell script

For a while, I ran a small IRC bot for keeping the members of a local hackerspace informed about when the space is open for visitors. This bot needed to check a status page every minute or so.

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\
etric/smokecheap/tog-dot-ie --data-binary "[$(ping -c 20 | 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