[julian37]

Could you explain briefly why you chose to write a replacement for statsd, rather than improve on it? What aspects of statsd were you not happy with?

(I don't have a horse in this race, I haven't used statsd before -- but I am planning to deploy some sort of statistics gathering soon and I wonder why I would choose your implementation over Etsy's, apart from the obvious appeal of the 37signals brand.)

[noahnoahnoah]

Briefly, probably not (everyone here at 37signals got treated to a 3000 word treatise on our statsd journey a few weeks ago). I did write up a few reasons at https://github.com/noahhl/batsd/blob/master/doc/why-not.md.

In short: we as a company have a ton of Ruby experience and comparatively little Python/Node.js experience (both in terms of understanding the tools that we use, which we like to do, and simply just in being able to confidently manage dependencies, etc.), and we knew we were going to want to build our own UI eventually anyway, which limited the utility of Graphite itself.

Edited to add: I can't say it enough, Etsy and Graphite are both fantastic pieces of engineering, with fantastic communities and support behind them (there's a fascinating writeup about Graphite in particular at http://www.aosabook.org/en/graphite.html).

[otterley]

I briefly read the chapter on persistence -- basically you're doing what RRD originally did (one file per metric), except without actual round-robin storage, before RRDcache was born. The long-term performance implications could be worrisome. Unless you're backing this with solid-state storage, if you have many thousands of metrics, the seek capability of the disk may not be able to keep up with the I/O flush rate.

[moe]

You're witnessing second degree dilettantism at work.

Remember, we started out with a rock-solid reference impl called RRDTool. RRDTool is 13 years old and about as mature as it gets. It's also surprisingly usable and relatively wart-free.

However, its documentation is not written as a narrative "guide", so inevitably some kid eventually found it too complicated and decided to reinvent it, without realizing how far out of his depth he went. That's how graphite happened.

Now 37signals sees graphite, and goes full Dunning Kruger with yet another knock-off, this time leaving out everything that would acknowledge the slightest understanding of the problem domain. While graphite at least tried to mimic the RRDTool file-format 37signals just skips over that whole "complicated binary-stuff" and writes the data as newline-delimited ascii-text...

[brown9-2]

I believe Graphite/Whisper were created to address some inabilities in RRDTool: http://readthedocs.org/docs/graphite/en/latest/whisper.html#...

Are you saying that graphite is somehow deficient? How is/was the author "out of his depth"?

[mattyb]

While graphite at least tried to mimic the RRDTool file-format 37signals just skips over that whole "complicated binary-stuff" and writes the data as newline-delimited ascii-text...

What benefit lies in trying to mimic RRDTool's file format?

[moe]

Scalability.

[julian37]

That makes sense, and speaks to me (I'm more of a Ruby guy myself.) Thanks for taking the time to reply.

Edit: and, "it looked like it would be easy" made my day :-)