MIT licensed by Chris Coffey
Maintained by [email protected]
This version can be pinned in stack with:servant-tracing-0.1.0.2@sha256:b53e9fafaddc1f5b6631bd9ac6165e459a4bedc7d5c5fd0bed0a531f8cdd0b15,3156

Module documentation for 0.1.0.2

servant-tracing

Build Status

This repository is the minimum required for publishing trace data to Zipkin or Jaeger. It adheres to the [Open Tracing Standard] (https://github.com/opentracing/specification) but is not complete. See the documentation on Hackage for module-level details.

Using the library

The OpenTracing standard revolves around a single function, recordSpan. recordSpan is responsible for creating new spans (see the standard for the definition of a span) and ensuring child spans use the new id. In order to properly build this tree of calls library users must provide the necessary environment via a MonadTracer instance (see haddocks). Library users are responsible for defining their own publish loop. There is a default Zipkin publisher in Tracing.Zipkin which works with Jaeger & Zipkin, but the loop to drain the spanBuffer must be provided by the user.

foo :: (MonadIO m, MonadTracer m) =>
    Int
    -> m String
foo str = recordSpan
    Nothing
    [Tag "Ultimate Answer to Life, The Universe and Everything", Tag 42]
    "Compute Ultimate Question"
    $ pure "Oops"

The code above logs a new span to the spanBuffer, where it will sit until published. If it turns out that foo is called from an active span, then it will be recorded as a child of said higher span.

Testing Locally with the Demo App

You can start up a compatible server for Zipkin or Jaeger via a standalone docker container. From there its a matter of seting the following environment variables:

  • TRACING_ENDPOINT: a String with the fully url to a running tracing server
  • TRACING_SERVICE: a String name for your service

Pending Features

  • Concurrent tracing support.
  • Thrift support
  • Additional clients
  • Pluggable samplers

Changes

Changelog for servant-tracing

Unreleased changes