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.