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/specification/blob/master/sem...

OpenTracing also allows you to define functions that follow each other: https://github.com/opentracing/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.