5 ms·

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

by kawsper 13y ago

coopr 13y ago
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 13y ago
  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?
lmirosevic 13y ago
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 13y ago
  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://opensource.brightcove.com/project/diamond/ http://collectl.sourceforge.net/ http://collectl.sourceforge.net/ http://collectd.org/ 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.

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

by kawsper 13y ago

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

coopr 13y ago

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 13y ago
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?

lmirosevic 13y ago

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 13y ago
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://opensource.brightcove.com/project/diamond/ http://collectl.sourceforge.net/ http://collectl.sourceforge.net/ http://collectd.org/ 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.