On Tue, Mar 27, 2012 at 1:40 AM, Andrea Campi <[email protected]> wrote:
> Reading the name I was hoping you were going in the direction I'm > thinking of going :) > That is, pushing statistics to statsd [1] and from there to Graphite. Sadly, we are still using cacti (and pnp4nagios) to monitor performance information. At this point I am more interested in monitoring individual counters in nagios. I will be interested in collecting performance data next. I planned on trying graphite. I am no expert in tornado but it seems they have a UDP transport so similar to how the stats are updated an event would fire and trigger sending the stats to graphite. Do most people use statsD instead of just sending rows to graphite? > > My rationale is that we are going to use statsd for other components > of our architecture; but even looking at just Varnish, it has > potential to be more scalable. In particular, I'm looking at > collecting more in-depth stats via the SHM. > Last year I did a spike on that [2,3] and while my naive approach > broke down under moderate load, it looks like if I keep processing at > a minimum and just fire off UDP I should be able to keep up with a > much higher traffic. Why did it break down under load? In my testing I thought it would be faster to use FFI to get at the stats...but the callback function added quite a bit of overhead. > > I'm not ready to work on that right now, but I will get there. If this > is something that might interest you, maybe we can combine efforts. > > Andrea > > > 1: https://github.com/etsy/statsd > 2: https://github.com/andreacampi/varnish-rb > 3: https://github.com/andreacampi/newrelic_varnish > > _______________________________________________ > varnish-dev mailing list > [email protected] > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev _______________________________________________ varnish-dev mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
