benoitc/gunicorn — pull request #748 by alq666 (2014-05-14 17:58:02+00:00)
Title: gunicorn instrumentation via statsD and a new logger class

(This is another attempt at getting statsD instrumentation to gunicorn initially in #672)

# What is this pull request?

[statsd](https://github.com/etsy/statsd) is the *de facto* low-overhead instrumentation of many web stacks. I have come across a number of different ways to instrument `gunicorn`, none of which are part of the core and rely on external scripts being run out-of-band to guess the number of requests processed or the amount of cpu spent.

I am hereby proposing that gunicorn optionally submits metrics to a local (or remote) statsD instance with the use of `--logger-class gunicorn.instrument.statsd.Statsd` option. Being that statsD uses UDP as transport, the receiving end being up or down does not affect the performance of the gunicorn application (unlike other stat collection schemes).

Here is an example of such metric being graphed.

![metric_explorer___datadog-2](https://f.cloud.github.com/assets/19755/1803522/e8a24f14-6c1f-11e3-8097-28281a776c30.png)

# How does this work?

The arbiter and the base worker use a new logger that can take additional arguments to turn a log message into a metric. In addition certain known logging levels are automatically turned into metrics.

In particular the `access` method is overriden to capture duration and count of each gunicorn request.

The new logger class inherits from `gunicorn.glogging.Logger` so existing logging should be preserved. No external dependencies were created.

# Who is behind this?

[I](https://github.com/alq666) use gunicorn at [Datadog](http://www.datadoghq.com) and have found statsD an indispensable aid to measure the performance of high-traffic applications. There is no company-specific bits in the pull request of course.