varnishstatd stats daemon

[John Skopis]

On Tue, Mar 27, 2012 at 1:40 AM, Andrea Campi
<andrea.campi at zephirworks.com> 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
> varnish-dev at varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev