As the blog post mentioned, we're collaborating with partners on a common RPC context proposal for tracing systems [1]. Some of the major contributors are currently on vacation, but there'll be be another round of comments and updates once they get back.
We're also working with the same partners on a project called Census - a set of tracing instrumentation libraries that all vendors can use and contribute to, though we're still in the very early days on this effort. We'll have more to announce later in the year (still need to publish additional libraries, set up a website, etc.), but you can follow the progress on GitHub here [2].
OMG, Census! It's one of the frameworks you miss the most once you no longer can use it. There is some preliminary version of it hidden deep inside gRPC, but it's great to hear that it's becoming a standalone project.
What's the difference between this and opentracing? AFAIK opentracing is built by the people who created Dapper at Google, and the project also has a set of standards for HTTP transport.
They're different in scope and goals. Census is composed of a context propagation format (which the blog post mentioned), a single distribution of language-specific libraries that include instrumentation hooks for popular web / RPC frameworks and metrics + trace exporters for various backends, and an optional agent that you can run locally to view metrics and RPC stats.
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.).
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?
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.
Plus, defines abstract ways of passing tracing contexts through service boundaries (ie. from client => API server => other microservices) via strings and HTTP headers.
It should be pretty clear how to use it once you read through the examples.
Jaeger requires using Cassandra as a datastore (for now), which isn't easily supported at my company, so I went with Zipkin and used MySQL as a datastore.
LLVM is a future consideration for Go. One of the main reasons I don't want to tackle (1) right now if the possibility of benefiting from XRay even though it doesn't sort the case out for the vast majority: the gc users.
As the blog post mentioned, we're collaborating with partners on a common RPC context proposal for tracing systems [1]. Some of the major contributors are currently on vacation, but there'll be be another round of comments and updates once they get back.
We're also working with the same partners on a project called Census - a set of tracing instrumentation libraries that all vendors can use and contribute to, though we're still in the very early days on this effort. We'll have more to announce later in the year (still need to publish additional libraries, set up a website, etc.), but you can follow the progress on GitHub here [2].
[1] https://github.com/TraceContext/tracecontext-spec/pull/1/fil... [2] https://github.com/census-instrumentation