Thanks for the pull request!

I'm currently being cautious about adding report-related things to the metrics classes.

A couple things I've noticed, but haven't had a chance to jump on are:

1. I think the reporters should be in their own gems instead of part of this core library (to reduce dependencies)
2. Different reporters have fairly different ways they need to send the data (and different representations)
3. The current way the reporters work (with the duplicated logic) really sucks

My thought so far was to implement some... I don't know the right word here so I'll call them "adapters"... that would implement some of the behaviors I've seen that are fairly consistent, like turning a registry into a flat list of [metric, value] pairs.

For some reporters (like the librato metrics one, and a theoretical statsd one), instead of reporting the one_minute_rate it would be better for their system to report the difference between the last reported count and the latest count.

Metriks.meter('testing').mark

Metriks::FlatteningAdapter.new(Metriks.default).each do |metric_name, value|
   puts "#{metric_name}: #{value}"
end

would output:

testing.count: 1
testing.one_minute_rate: 0.00001
testing.five_minute_rate: 0.0000001
testing.fifteen_minute_rate: 0.00000001
testing.mean_rate: 1

For reporters, like the logger reporter, it would need a different adapter that kept the hierarchy of the metric itself (because we are reporting all of the metrics for a given named metric on a single line).

These are still just fairly unpolished ideas, so I'm definitely open to other directions if they make more sense.

I think the reporters should be in their own gems instead of part of this core library (to reduce dependencies)

Ah yes, I saw the ticket for moving reporters to their own gems and figured it might be useful to have them decoupled before they're split up. Happened to have a few hours to kill on the train the other day so figured I might try it out! :)

Different reporters have fairly different ways they need to send the data (and different representations)
...
My thought so far was to implement some... I don't know the right word here so I'll call them "adapters"... that would implement some of the behaviours I've seen that are fairly consistent, like turning a registry into a flat list of [metric, value] pairs.

That sounds like an interesting idea, having looked through the reporters you support I can see what you mean about the different formats. When you say consistent behaviours, do you mean things like prepending some prefix to metric names, and not reporting certain metrics(#20), or are there are other more subtle similarities?

For some reporters (like the librato metrics one, and a theoretical statsd one), instead of reporting the one_minute_rate it would be better for their system to report the difference between the last reported count and the latest count.

Ah, so instead of sending two consecutive one_minute_rates of 5 you'd use one of librato's counters and send a first one of 5, then either send 0 or none at all?

I'm currently being cautious about adding report-related things to the metrics classes.

Agreed, metrics definitely shouldn't be aware of reporting, but shouldn't the metric classes be able to serialize/export their own values? Maybe in a more generic method like to_hash rather than export_values? I think if the information on how to extract the values is kept outside of the metric class there's a risk of too much coupling between different components, especially when it comes to things like snapshots.

May be useful to look at how etsy/statsd implemented the interface between core and backends? I imagine there's a lot of overlap in the requirements. /cc @mheffner