-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Comments
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? |
The bare minimum would be:
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. |
OK thanks. Will give it a shot. |
Do you want me to create a repository under jaegertracing? NB: I added one more step above:
|
Please. I'll fork it once you do. |
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. |
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. |
@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. |
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. |
I pushed a commit with some initial work. As of now, doesn't look too difficult to implement OpenTracing interfaces using existing code. |
The official client is available from https://github.com/jaegertracing/cpp-client |
Hi, is there any sample/tutorial on instrumenting a c++ code with Jaeger-cpp-client? |
@maniaabdi check https://github.com/opentracing/opentracing-cpp/tree/master/example Jaeger-specific part would be only initialization. |
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:
The text was updated successfully, but these errors were encountered: