HN Gopher Feed (2017-07-24) - page 1 of 10
 
___________________________________________________________________
The future of latency profiling in Go
83 points by rakyll
https://rakyll.org/latency-profiling/
___________________________________________________________________
 
tonyhb - 5 hours ago
Using Opentracing and uber's Jaeger client is awesome.  It's easy
to implement, and Jaeger provides multiple different mechanisms for
sampling traces (always on, guaranteed throughput etc.).It's
awesome to be able to see a UI giving you diagrams like this:
https://www.dropbox.com/s/b2uhx77urpnuk9g/Screenshot%202017-... for
your API.Definitely would recommend - it beats old-school log
tracing.
 
  frik - 3 hours ago
  Do I miss anything? OpenTracing mentions "A vendor-neutral open
  standard for distributed tracing." It reads like it's for
  implementors - is it useable stand alone + Jaeger as UI?How can
  it be used - can you point me to a tutorial/blog post?
 
    jamesmishra - 2 hours ago
    Hey frik, former Uber engineer here. I never worked on Jaeger,
    but I loved using it at Uber.If you want to get started, the
    documentation is at http://jaeger.readthedocs.io/en/latest/We
    also have a blog post that describes the history of Jaegar and
    some of the design decisions. https://eng.uber.com/distributed-
    tracing/Jaegar is compatible with the OpenTracing standard (
    http://opentracing.io/documentation/pages/supported-tracers )
    and is also compatible with the Zipkin backend and wire
    protocol ( http://zipkin.io/ ).
 
      frik - 2 hours ago
      Thanks a lot, will try it out.btw
      https://uber.github.io/jaeger/ still mentions "Backend
      components are implemented in Go (will be open sourced soon)"
      ...in the meantime the code go published as it seems:
      https://github.com/uber/jaeger
 
    tonyhb - 2 hours ago
    Mm it's a little sparse right now - had to dig into the
    opentracing spec, dig in to the implementations and make it
    piecemeal.OpenTracing is for everyone - both tracing
    implementors (eg. Jaeger engineers) and for you implementing
    tracing in your system.  As an implementor in your system you
    mainly care about the "vocabulary" and "standards" opentracing
    defines.   So, if you've got two functions (A which calls B)
    opentracing defines:- Syntaxes to say that the span for "B" is
    a "childOf" "A".  This gives you the graph I had above.-
    Syntaxes to attach errors and other information to spans in a
    standard way (this lets any opentracing-compatible UI
    display/search errors etc): https://github.com/opentracing/spec
    ification/blob/master/sem...OpenTracing also allows you to
    define functions that follow each other: https://github.com/ope
    ntracing/specification/blob/master/spe....Plus, defines
    abstract ways of passing tracing contexts through service
    boundaries (ie. from client => API server => other
    microservices) via strings and HTTP headers.Also, the best part
    of opentracing (in go) is that you can use it directly to set
    these fields (https://github.com/tonyhb/personal-
    starter/blob/master/pkg/a...).  You can pull in the
    "github.com/opentracing/opentracing-go" library and use it to
    create and propagate your spans and contexts, and set errors
    using the default vocabulary
    (https://godoc.org/github.com/opentracing/opentracing-
    go/ext).Been meaning to sort my blog out and write some posts
    on this as the implementation documentation is sparse.  Some
    time soon.
 
liuliu - 1 hours ago
For 1)., if you use a LLVM backed language, XRay supposedly should
be it: https://llvm.org/docs/XRay.html