1. 8

This package is somewhat of a combination of a distributed tracing library (with built-in graph generation), and something more like @codahale’s metrics library. Integrations are driven by plugins, but we have plugins for Graphite and Zipkin already. It’s been very useful to us. Let me know what you think!


  2. 1

    Is there any documentation on using such a library with something like statsd? One of the major selling points to me for using Codahale’s Metrics was the various statsd reporter implementations.

    1. 1

      The way we get the data to our graphite collector is unfortunately unnecessarily convoluted for most users, so that plugin hasn’t been released.

      Nonetheless, if you skipped our internal system, getting all of the key/value data into a timeseries database is quite straightforward, on the order of something like:

        monkit.Stats(func(name string, val float64) {
            // send name, val to graphite with a timestamp

      It’s a good point that a simple wrapper should be built in. If you beat me to a commit that adds it I’ll merge it!

      Worth pointing out that statsd usually does data aggregation (max/min/etc), whereas you might be able to use monkit directly to your time series database without statsd since monkit does the aggregation in process.

    2. 1

      Why have the deferred function return func(*error) func(*context.Context) instead of func(*error, *context.Context)? I thought the former would make the call evaluate the error argument immediately?

      1. 1

        it returns func(*context.Context) func(*error) though. we want to set up the context before function execution, and capture the error at the end