Remove references to Graphite and add a quick start section to the README

[mkeesey]

Replaced references to Graphite with StatsD and added a section to the README to help users who are new to using Metrics plugins get an idea of how to use the API.

[JoeDeVries]

+1

[watsoncj]

👍

[mveitas]

We are working on migrating to use the new Metrics 3.0.1 library. I have created a QuickStart guide in the README with an example of how to create the new StatsdReporter

[watsoncj]

Hi @mvietas, we have a Metrics 3.0 compatible fork here: https://github.com/ReadyTalk/metrics-statsd

[mveitas]

Thanks for the link! If you are actively maintaining this it would probably make sense to consolidate.

I might add a PR to update the Metrics docs with a link to this project.

Sent from my iPhone

On Dec 2, 2013, at 10:46 PM, Casey Watson notifications@github.com wrote:

Hi @mvietas, we have a Metrics 3.0 compatible fork here: https://github.com/ReadyTalk/metrics-statsd

—
Reply to this email directly or view it on GitHub.

[watsoncj]

Yep, it's been fairly active. The PR is a good idea. I suspect we've just had more resources to throw at it than @organicveggie has. We've been building on the awesome work that he's already done. Since we have several collaborators on the ReadyTalk repo we should be pretty responsive to any pull requests.

[mveitas]

@watsoncj I was taking a look through the the ReadyTalk metrics-statsd project and noticed that all data is being sent as a gauge? Is there a reason for this?

[watsoncj]

This has been bugging me as well. It basically comes down to a mismatch between the Metrics
reporter API and StatsD. StatsD uses the counter type for increment/decrement operations, while Metrics expects to own the count in memory.

If we just switched to use the counter type without reseting the in-memory metric, the StatsD count would go through the roof since it would double the count each time it gets reported.

The biggest limitation of using the gauge type is that your counts get reset when you restart the VM.

Ideally, the reporter would just send the delta value as a counter type.

I know @mkeesey is using the Metrics counter as a sort of “active sessions” value which is a slightly different use-case. I’d be interested in his opinion.

On Dec 3, 2013, at 8:43 AM, Matt Veitas notifications@github.com wrote:

@watsoncj I was taking a look through the the ReadyTalk metrics-statsd project and noticed that all data is being sent as a gauge? Is there a reason for this?

—
Reply to this email directly or view it on GitHub.

[mkeesey]

@mveitas, everything is sent as a gauge now because the CodaHale metrics library already does metric consolidation and calculations (such as 99th percentiles with timers, etc). Sending all this data as a gauge ensures that statsd doesn't (incorrectly in this case) try to consolidate our timers or other metrics again and calculate statistics on values that have already been transformed on the sender's side.

As @watsoncj alluded to, my particular use case is to track active sessions and timings specific to a specific invocation of the Java VM. I would be open to pull requests that allow for a mode where we send deltas with statsd counters to allow values to survive VM restarts.

[dclements]

It's important to note that what statsd does and what the Codahale library do are functionally very similar. The difference is that the codahale library is designed to report from within a VM, while statsd is designed for several servers to use remotely. The use of gauges, as @mkeesey indicates, is to address this.

By way of example: If you look at the counters on the statsd protocol you'll see:

Metrics sent by the client increment or decrement the value of the gauge
rather than giving its current value.

The Codahale library's counters have no way to track the delta, and just send the current value: If you look at the Counter class, it has no memory of when it is being reported on, and so when it reports using a ScheduledReporter what we are really doing is pulling the current state. This makes reporting on it a gauge from the standpoint of StatsD.

The other types specified by the statsd protocol fall under a similar mantle, except that they would actually be more difficult to report, since it isn't a simple matter to report the diffs between, say, histograms.

If people want to report directly to statsd and take advantage of statsd's various types, the codahale library is not ideal for this and can't really be shoehorned into it (even the interfaces aren't really built for it), and trying to make it work for counters (and counters alone) strikes me as inherently problematic compared to just leaving counters as a gauge. It'd be best to use–or at least start from–a different library (e.g., the youdevise one).