Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jaeger client in C/C++ #228

Closed
yurishkuro opened this issue Jun 22, 2017 · 14 comments
Closed

Jaeger client in C/C++ #228

yurishkuro opened this issue Jun 22, 2017 · 14 comments

Comments

@yurishkuro
Copy link
Member

Just booking a placeholder, as there is currently no active work on that.

Why it's important - many low level infra components are implemented in C/C++, we're missing the ability to integrate with them today. For example, there is nginx instrumentation.

Refs:

@yurishkuro yurishkuro added enhancement help wanted Features that maintainers are willing to accept but do not have cycles to implement labels Jul 1, 2017
@isaachier
Copy link
Contributor

I'd be interested in helping out with this, but what exactly is involved? I have taken a look at the other clients, but having a hard time discerning the key components. For example, it seems not all the IDL files are used in all of the clients. How does zipkin relate to the jaeger client, and is it necessary to implement zipkin support in order to move ahead with the jaeger implementation?

@yurishkuro
Copy link
Member Author

yurishkuro commented Aug 21, 2017

The bare minimum would be:

  • project structure, readme, license (APL2), travis build, code coverage
  • OT types: tracer, span, span context
  • text, http, and binary codecs
  • probabilistic sampler
  • buffering remote reporter with Thrift sender subclassed by UDP sender
  • test coverage

I would suggest following jaeger-client-java class hierarchy for these, to allow for future extensibility. Zipkin features are not required in the first version.

@isaachier
Copy link
Contributor

OK thanks. Will give it a shot.

@yurishkuro
Copy link
Member Author

Do you want me to create a repository under jaegertracing?

NB: I added one more step above:

  • project structure, readme, license (APL2), travis build, code coverage

@isaachier
Copy link
Contributor

Please. I'll fork it once you do.

@yurishkuro
Copy link
Member Author

@rnburn
Copy link

rnburn commented Sep 30, 2017

Hey @isaachier just wanted to check in on this as some people were asking about using Jaeger with nginx.

Are you planning on binding to the OpenTracing API? I don't see any code for it in https://github.com/isaachier/cpp-client.

Also, just a suggestion: you may want to consider limiting your dependencies for the Jaeger client a little more. Requiring a large library like boost, for example, is likely to be an obstacle for projects like envoy to use it.

@isaachier
Copy link
Contributor

As of now, this has been sort of a side project. I did see the OpenTracing API, but not sure if it is worth the headache of merging. If there is a good reason to, I will. Right now seems the C++ API is not widely used and not yet stable (see end of their README).

I have thought about the dependencies. In short, Boost is one of the few libraries I feel is indispensable. One strong reason for this leads from another large dependency that cannot be avoided: Apache Thrift. All of the Jaeger clients use Apache Thrift to communicate, and the generated Thrift code depends on Boost.

About dependencies in general, it will depend how you use the library. I intend on exposing a simple C header for C clients or anyone else who does not want the included headers from Boost etc. That way, it is only required to link to the few Boost libraries (i.e. thread, asio, etc.) that are not header-only.

@rnburn
Copy link

rnburn commented Oct 1, 2017

@isaachier We just released version 1.0 of the C++ OpenTracing API. While it might evolve somewhat, the expectation is to keep it as stable as possible. I wrote that README; the section you're talking about was copied over from the OpenTracing Go API.

I'm expected to release nginx OpenTracing bindings soon into opentracing-contrib, and we plan to make bindings available for envoy as well, so if you bind to them you'll be able to make the client work with those projects. It would also be more aligned with what the other Jaeger client libraries do.

@isaachier
Copy link
Contributor

OK great. I am not opposed in any way to merging using the OpenTracing C++ API, especially if it means we can leverage future instrumentations of C/C++ based projects. I'll take a look at the dependencies again and see what I need vs what is truly important. The hardest part here is networking using sockets on different platforms without a convenient wrapper like Boost ASIO.

@isaachier
Copy link
Contributor

I pushed a commit with some initial work. As of now, doesn't look too difficult to implement OpenTracing interfaces using existing code.

@yurishkuro yurishkuro removed the help wanted Features that maintainers are willing to accept but do not have cycles to implement label Oct 28, 2017
@yurishkuro
Copy link
Member Author

The official client is available from https://github.com/jaegertracing/cpp-client

@maniaabdi
Copy link

maniaabdi commented Apr 26, 2018

Hi, is there any sample/tutorial on instrumenting a c++ code with Jaeger-cpp-client?

@yurishkuro
Copy link
Member Author

@maniaabdi check https://github.com/opentracing/opentracing-cpp/tree/master/example

Jaeger-specific part would be only initialization.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants