Zipkin c/c++ tracer library

[codefromthecrypt]

There are a couple c or c++ zipkin libraries out there.

For example, there's some recent work in envoy, which was made and/or facilitated by @rshriram @RomanDzhabarov @fabolive and @mattklein123. This is high performance code, having had several reviews on it, though its only instrumentation target is envoy

There's an offer from LightStep employees to help push forward the stalled https://github.com/openzipkin/zipkin-cpp-opentracing (noted on https://github.com/lyft/envoy/issues/1196 by @tedsuo and gitter by @rnburn)

Meanwhile, there is also recent work by @flier on a zipkin c/c++ tracer including a gRPC example https://github.com/flier/zipkin-cpp

What's most supportable are things reused, maintained by multiple people and stable (with regards to zipkin). At the end of the day, what ends up being made, though, are things people feel like working on :) Unlike other projects, zipkin does not have a large deck of fulltime staff to work on things.

What I would like to see is a c/c++ library (in or outside zipkin's org) which binds to Zipkin. This could be used directly where performance or best experience with Zipkin is a goal. Abstractions like OpenTracing or Census could bridge to apis inside this repo. This decouples Zipkin support from any api opinions (such as logging) which are made in these abstractions, any version incompatibilities, etc, and centralizes the mapping concern. Formalizing on a zipkin library will certainly help support and triage (knowing the difference between a zipkin problem and an abstraction mapping problem. I'd go so far as to say zipkin-go-opentracing should have been split this way knowing what we know now cc @basvanbeek.

One way to progress could be to move @flier's work into the org. Another could be to create a fresh repo and pick things from various places. Main thing is to not setup yet another abandoned library, or one that leads users to api thrash or poor experience... diverse interest is important, and advocacy for Zipkin is important in OpenZipkin works.

Thoughts?

[tedsuo]

Hi @adriancole. Just to let you know where we're currently at.

• We started working on a C++ implementation here to get our feet under us: https://github.com/rnburn/zipkin-cpp-opentracing. It's based on the implementation in Envoy for the pragmatic reason that it was easier, and allowed us to start by refactoring the code running in the system we are committed to maintaining in production (envoy). We haven't heard from @flier yet, though they did respond to our PRs which was nice. Maybe they haven't seen this issue?

• I agree your suggestion of keeping the OT-zipkin bridge separate from the zipkin API, so we are taking that approach. Both pieces still are in the same repo for the time being.

• OT C++11 API is ready for review. It would be great if someone from zipkin with C++ experience could review it (I'll mention in gitter as well): https://github.com/opentracing/opentracing-cpp/pull/11

• We can move our work into OpenZipkin if there are no objections, and we are happy to collaborate with @flier and others on API design, combining concepts and code in from both repos. We are focused more on making zipkin work in the context of OT, and have few opinions about what the ZipKin C++ API should look like beyond that, so we don't really want to go much farther without more involvement from the rest of the ZipKin community.

Cheers, Ted

[codefromthecrypt]

Hi, ted.

Thanks for the updates. This sounds like great progress

One thing quite important is having multiple folks on a project as we have been bit in the past. There are abandoned or barely breathing works and these confuse and annoy people. Diversity is missing in these scenarios.

For example eventhough criteo/zipkin4net is behind one of the largest zipkin sites (2.5M req/second on burst for a service), and also well maintained, we are waiting for more buy in before moving the project here.

Can you do me a favor and ping the authors of the original zipkin c++driver about the repo you have? That might raise attention. I will look at it, too, and see if I can find others. Maybe flier will reply back.

If we have a couple contributors who dont work at the same place on board to help, then seems a good idea to consider.

Hope it makes sense, but if not ping back! Regardless, good work.

[flier]

Hi @adriancole,

Thanks for your advice, I'm open to use either zipkin-cpp or zipkin-cpp-opentracing, if it could provide enough features that we are using, such as native C API, kafka collector etc.

We maintains zipkin-cpp and rust-zipkin because the exists library doesn't meet our requirements. We glad to fix issues and accept PR for those projects, because our internal projects depend on it.

If @tedsuo like to sync up API design, I think we may extract a thin API layer (C and C++), such as a zipkin-cpp-api project, as the official project, and maybe a zipkin-cpp-spec project to define scenes with test cases.