OpenTracing: A vendor-neutral open standard for distributed network tracing | Hacker News Reader

OpenTracing: A vendor-neutral open standard for distributed network tracing

opentracing.io

141 pointsbased224 comments

This is a fantastic introduction.

https://medium.com/opentracing/take-opentracing-for-a-hotrod...

(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.

Anyway, if people have questions, the best place to go is the public Gitter: https://gitter.im/opentracing/public

People are friendly there :)

Also feel free to reach out to me directly. I will probably do a bad job following this thread... bhs@gmail.com

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.

Is there anything like that?

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.

[1] http://opencensus.io/

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 discussion goes into more detail about commonalities and differences between the two:

https://github.com/census-instrumentation/opencensus-java/is...

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.

I have to say, after reading through that, I'm still not quite mystified as to what the differences are.

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.

You can either use a Google-provided Java-server for this (https://cloud.google.com/trace/docs/zipkin) or in our case we use https://github.com/lovoo/gcloud-opentracing which is great.

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'm excited by the portability OpenTracing offers between APM products if they start adopting it. Datadog has already pledged support.

https://www.datadoghq.com/blog/opentracing-datadog-cncf/

as has NewRelic. https://blog.newrelic.com/2017/09/13/distributed-tracing-ope...

OpenTracing is awesome. We plan to use it in GitLab with Jaeger. Extensive notes are in https://gitlab.com/gitlab-org/gitlab-ce/issues/41449

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.

[1] http://www.paratools.com/otf/

For a little more context, this post explains what can OpenTracing do for you.

https://medium.com/opentracing/distributed-tracing-in-10-min...

Maybe they should put it on their homepage

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.

The guys working on Jaeger are very helpful on Gitter.

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?

This is network tracing. It's been around a few years, started as zipkin

Ok, we'll add a network above.

Nope, took me a couple minutes to figure out. I went strait to ray tracing, then lightbox tracing, then finally debug tracing.

Another one is circuit board tracing

The front page is not very obvious, no.

My mind did go to debugging tracing, but the exact form of debugging tracing is not very obvious from the front page.

Reply on news.ycombinator.com