
The future of latency profiling in Go - rakyll
https://rakyll.org/latency-profiling/
======
mmclean
PM for tracing at Google here.

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...](https://github.com/TraceContext/tracecontext-
spec/pull/1/files) [2] [https://github.com/census-
instrumentation](https://github.com/census-instrumentation)

~~~
tonyhb
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.

~~~
mmclean
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.

------
tonyhb
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-...](https://www.dropbox.com/s/b2uhx77urpnuk9g/Screenshot%202017-07-24%2010.56.51.png?dl=0)
for your API.

Definitely would recommend - it beats old-school log tracing.

~~~
frik
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
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/](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/](https://eng.uber.com/distributed-tracing/)

Jaegar is compatible with the OpenTracing standard (
[http://opentracing.io/documentation/pages/supported-
tracers](http://opentracing.io/documentation/pages/supported-tracers) ) and is
also compatible with the Zipkin backend and wire protocol (
[http://zipkin.io/](http://zipkin.io/) ).

~~~
frik
Thanks a lot, will try it out.

btw [https://uber.github.io/jaeger/](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](https://github.com/uber/jaeger)

------
liuliu
For 1)., if you use a LLVM backed language, XRay supposedly should be it:
[https://llvm.org/docs/XRay.html](https://llvm.org/docs/XRay.html)

~~~
rakyll
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.

------
easytiger
what is the latency caused by the call to trace the latency?

