(disclaimer: I am one of the people who started opentracing)
Someone sent me this HN thread – nice to see the questions here!
OpenTracing has had a big end-of-2017 with support landing for various service mesh(es), bindings announced from some major vendors (newrelic and datadog), many community contributions in the "core" OpenTracing repos as well as integrations with numerous external projects, lots of uptake from companies large and small, etc.
If I understand it correctly this only species an API that implementors of the different solutions must follow, so that in your program you may import different vendor implementations. This allows easier change of vendor.
But no wire protocol is specified or anything like that. It is the duty of the vendor to create all the different programming language bindings and API implementations, and store the data from whenever it comes.
From my point of view it is the second part that would be more interesting: a standard logging protocol with tracing incorporated, and standard ways to pass along the tracing id (spans) to other services.
OpenCensus [1] provides an implementation for tracing and app-level metrics, a context wire protocol, and exporters for various backends. While it provides similar tracing APIs to OpenTracing, they're not identical, though there have been some early conversations about resolving this.
I'm the PM for Census at Google, though other vendors are involved as well. Basic implementations for Java and Go are already functional, with much more to come. We gave a small talk at Kubecon last month, but will start promoting the project once it's slightly more mature.
The use case of non-request metrics is the biggest difference to me. While it's great to track e.g. resource usage for each incoming request, there are also workloads that don't fit that mold. Think of a garbage collecting background worker: either you use a separate API to push the data or you make up bogus GC RPCs to attach metrics to their traces.
Yes!! We are very interested in resolving these API differences. In my opinion OpenCensus is great and if it could become the “standard” client for OpenTracing it would make me really happy.
This is really great. We are currently using it with Google Stackdriver (https://cloud.google.com/trace/), since we do not want to care about hosting Jaeger/Zipkin infrastructure. I think Aws X-ray needs to catch up on Stackdriver.
Since we want to be compatible with opentracing, you need a bridge for Google Stackdriver and Opentracing/Zipkin.
If you’re interested in getting involved, we’re kicking off a documentation overhaul and looking for language maintainers (especially ruby), come say hi in our gitter channel if you’re interested or have any questions! https://gitter.im/opentracing/public
I really hope AWS X-Ray gets on board with this. I just finished making a library to integrate X-Ray with our Haskell applications and then realized OpenTracing exists. I would love to be able to easily support more tracing backends.
This sounds distinct from the similarly-named "Open Trace Format (OTF)" [1]. Though it's a big bonus that this one has libraries for so many languages.
Timely! We are about to dogfood the Graphistry visual graph analysis stack for seeing correlations in logs, for our internal use of zipkin. If your team has this stuff feeding into Splunk/elk/etc, and would want to try as well, please reach out! Reference this post and ping info@graphistry[com], we'd love to chat on it.
When I saw the term tracing my mind went to network tracing and then ray tracing before whatever this is. Is the front page of this more obvious to other people?
https://medium.com/opentracing/take-opentracing-for-a-hotrod...