Why didn't you go with statsd or graphite? You would have gotten a lot of bindin...

lmirosevic · on June 20, 2013

Can I ask you why use graphite over SaaS based monitoring like scout, etc.? I'm genuinely curious. Is it just because it's free?

kawsper · on June 20, 2013

I haven't used Scout but I have the same problems with that as I do with NewRelic. Their plugins is built for their vendor agent. With that said I do like the opensource plugins of Scout.

The issue is that we are now a lot of people that tries to solve the same kind of problems. Everyone seems to be writing collectors that reports information to backends.

On top of my head I can name:

http://opensource.brightcove.com/project/diamond/ http://collectl.sourceforge.net/ http://collectd.org/

They all implement some kind of RRD or Graphite service hooks. It would be nice if all I should do to upgrade was to point my existing collectd collectors to NewRelic or Scout and be good to go.

Instead, I now have to reconfigure my whole stack, install their agent, add their plugins for my software, make sure things are working and then switch.

I am not advocating that everyone should use Graphite, I am just advocating that we should have some consistency between these systems, so we can use the same collectors no matter what the backend is.

I had a feeling that Graphite+Statsd was where the community was heading given that both Etsy and Github are using that.

coopr · on June 19, 2013

Try a New Relic plugin and you'll find out why ;)

The experience of adding monitoring with a New Relic plugin should be MUCH better than with any other monitoring approach.

kawsper · on June 19, 2013

I still need to rewrite all my statsd/graphite implementations.

Could you tell me what differs in your solution, and why it is better? And why you didn't choose Graphite/Carbon or statsd?