This block of code that generates the trace ID only yields a 64-bit trace ID. Can it return the TraceId object that supports 128-bit?

Closing opentracing-contrib/nginx-opentracing#112 as it is this module that is generating the ID

I am getting the below error:

[bala.nallasivan@RCSDEV48 workspace]$ g++ -std=c++11 -o sample2 sample.cc
/tmp/ccpYxnkE.o: In function __static_initialization_and_destruction_0(int, int)': sample.cc:(.text+0x6b): undefined reference to opentracing::v3::propagation_error_category()'
sample.cc:(.text+0x82): undefined reference to opentracing::v3::propagation_error_category()' sample.cc:(.text+0x99): undefined reference to opentracing::v3::propagation_error_category()'
sample.cc:(.text+0xb0): undefined reference to opentracing::v3::propagation_error_category()' sample.cc:(.text+0xc7): undefined reference to opentracing::v3::propagation_error_category()'
collect2: error: ld returned 1 exit status

Command used to run my code: g++ -std=c++11 -o sample2 sample.cc
OS: CentOS
Installation directory: /usr/local/include/
OpenTracing cpp Installation version : 1.5.0

Sample code which gave this error:

1 #include
2 #include <opentracing/propagation.h>
3 #include <zipkin/opentracing.h>
4 int main() {
5 std::cout<<"Hello.....\n"<<std::endl;
6 return 1;
7 }

I am getting this error while I build my docker file 3rd_party/include/zipkin/catch/catch.hpp:6465:33: error: size of array ‘altStackMem’ is not an integral constant-expression
26.70 6465 | static char altStackMem[SIGSTKSZ];

This din't seem to be an issue with centos though

The reportSpan member function of reporterImpl will drop spans if the span buffer is full yet there currently is no way for a client to know when this happens. Additionally, there is currently no way to change the max_buffered_spans or reporting_period parameters, yet some implementations may need to adjust these for performance and reliability reasons.

I'd like to propose the following changes as a means to address these issues and can submit a PRs if this proposal is acceptable (maybe 3 PRs, 1 for configuration, 1 for status, and 1 for the change to makeZipkinOtTracer?):

1. Add member functions to the reporterImpl class, and pass through functions to Tracer, to get and set the max_buffered_spans and reporting_period parameters and change them to be members of the reporterImpl class
2. Change the reportSpan member function to maintain a count of the number of dropped spans
3. Add a member function to the reporterImpl class, and a pass through function to Tracer, which will return the number of dropped spans and the length of time over which the count is applicable.
4. Add an optional third parameter to the makeZipkinOtTracer function which, if provided, will return a pointer to a shared pointer of the Zipkin Tracer object that will provide external access to these new status and configuration functions.

I've left out many of the implementation details, but do have a working model of the above which I have also done testing on. Does this sound reasonable?

how can i build on centos6 x64?
gcc 4.4.6

Version 0.5.2 has a link error(from the CMakeError.log):

CheckSymbolExists.c:(.text+0x1b): undefined reference to 'pthread_create' collect2: error: ld returned 1 exit status

I'm trying to compile this project with Yocto and it fails to compile opentracing.cc with

| /yocto/zipkin-cpp-opentracing/1.0+gitAUTOINC+e0cd6fd352-r0/git/zipkin_opentracing/src/opentracing.cc:270:17: error: cannot declare field 'zipkin::OtSpan::span_context_' to be of abstract type 'zipkin::OtSpanContext'
|    OtSpanContext span_context_;
|                  ^~~~~~~~~~~~~
| /yocto/zipkin-cpp-opentracing/1.0+gitAUTOINC+e0cd6fd352-r0/git/zipkin_opentracing/src/opentracing.cc:49:7: note:   because the following virtual functions are pure within 'zipkin::OtSpanContext':
|  class OtSpanContext : public ot::SpanContext {
|        ^~~~~~~~~~~~~
| In file included from /yocto/zipkin-cpp-opentracing/1.0+gitAUTOINC+e0cd6fd352-r0/recipe-sysroot/usr/include/opentracing/tracer.h:5:0,
|                  from /yocto/zipkin-cpp-opentracing/1.0+gitAUTOINC+e0cd6fd352-r0/git/zipkin_opentracing/include/zipkin/opentracing.h:1,
|                  from /yocto/zipkin-cpp-opentracing/1.0+gitAUTOINC+e0cd6fd352-r0/git/zipkin_opentracing/src/opentracing.cc:2:
| /yocto/zipkin-cpp-opentracing/1.0+gitAUTOINC+e0cd6fd352-r0/recipe-sysroot/usr/include/opentracing/span.h:34:40: note: 	virtual std::unique_ptr<opentracing::v3_unstable::SpanContext> opentracing::v3_unstable::SpanContext::Clone() const
|    virtual std::unique_ptr<SpanContext> Clone() const noexcept = 0;
|                                         ^~~~~

It's introduced by opentracing/opentracing-cpp@301ac82 commit.
Does this project is compatible with latest opentracing-cpp project, or does it need specific version?

Hello all,

When I close zipkin tracer, it hangs on writer_.join(); in zipkin_reporter_impl.cc.

I'm not sure about what happens but don't we need to unlock lock_guard in ReporterImpl::makeWriterExit before write_cond_.notify_all();?

Regards,
Vincent

In this comment, it is stated that zipkin-cpp-opentracing supports Zipkin v2 format:

the zipkin c++ library currently only supports the V2 style spans

But when looking at zipkin_core_constants.h, the collector API sounds different:

const std::string DEFAULT_COLLECTOR_ENDPOINT = "/api/v1/spans"

Testing with nginx and this module, it seems to be working even with a v2 collector endpoint.

Is this a configuration bug? Could you please confirm which version is supported?
And maybe, make the endpoint API path also a configuration?

-- The C compiler identification is GNU 5.4.0
-- The CXX compiler identification is GNU 5.4.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found CURL: /usr/lib/x86_64-linux-gnu/libcurl.so (found version "7.47.0") 
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/build/zipkin-cpp-opentracing-bba123a37147a2da6ce861cfd7984ad53d794739/.build
Scanning dependencies of target zipkin
[  5%] Building CXX object zipkin/CMakeFiles/zipkin.dir/src/zipkin_core_types.cc.o
[ 10%] Building CXX object zipkin/CMakeFiles/zipkin.dir/src/utility.cc.o
[ 15%] Building CXX object zipkin/CMakeFiles/zipkin.dir/src/hex.cc.o
[ 20%] Building CXX object zipkin/CMakeFiles/zipkin.dir/src/tracer.cc.o
[ 25%] Building CXX object zipkin/CMakeFiles/zipkin.dir/src/ip_address.cc.o
[ 30%] Building CXX object zipkin/CMakeFiles/zipkin.dir/src/span_buffer.cc.o
[ 35%] Building CXX object zipkin/CMakeFiles/zipkin.dir/src/span_context.cc.o
[ 40%] Building CXX object zipkin/CMakeFiles/zipkin.dir/src/zipkin_reporter_impl.cc.o
[ 45%] Building CXX object zipkin/CMakeFiles/zipkin.dir/src/zipkin_http_transporter.cc.o
[ 50%] Linking CXX static library libzipkin.a
[ 50%] Built target zipkin
Scanning dependencies of target hex_test
[ 55%] Building CXX object zipkin/test/CMakeFiles/hex_test.dir/hex_test.cc.o
[ 60%] Linking CXX executable hex_test
[ 60%] Built target hex_test
Scanning dependencies of target zipkin_opentracing
[ 65%] Building CXX object zipkin_opentracing/CMakeFiles/zipkin_opentracing.dir/src/utility.cc.o
[ 70%] Building CXX object zipkin_opentracing/CMakeFiles/zipkin_opentracing.dir/src/propagation.cc.o
[ 75%] Building CXX object zipkin_opentracing/CMakeFiles/zipkin_opentracing.dir/src/opentracing.cc.o
[ 80%] Linking CXX static library libzipkin_opentracing.a
[ 80%] Built target zipkin_opentracing
Scanning dependencies of target ot_tracer_test
[ 85%] Building CXX object zipkin_opentracing/test/CMakeFiles/ot_tracer_test.dir/ot_tracer_test.cc.o
[ 90%] Linking CXX executable ot_tracer_test
/usr/bin/ld: ../../zipkin/libzipkin.a(zipkin_reporter_impl.cc.o): undefined reference to symbol 'pthread_create@@GLIBC_2.2.5'
//lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[2]: *** [zipkin_opentracing/test/ot_tracer_test] Error 1
zipkin_opentracing/test/CMakeFiles/ot_tracer_test.dir/build.make:101: recipe for target 'zipkin_opentracing/test/ot_tracer_test' failed
CMakeFiles/Makefile2:258: recipe for target 'zipkin_opentracing/test/CMakeFiles/ot_tracer_test.dir/all' failed
make[1]: *** [zipkin_opentracing/test/CMakeFiles/ot_tracer_test.dir/all] Error 2
make: *** [all] Error 2
Makefile:138: recipe for target 'all' failed
The command '/bin/sh -c /tmp/build.sh' returned a non-zero code: 2
Makefile:61: recipe for target '.container-amd64' failed
make[1]: *** [.container-amd64] Error 2
make[1]: Leaving directory '/home/aledbf/go/src/k8s.io/ingress/images/nginx-slim'
Makefile:49: recipe for target 'sub-container-amd64' failed
make: *** [sub-container-amd64] Error 2

Any idea what could be the issue?
Thanks

I'm in the process of updating the nginx opentracing module and noticed we had errors reporting that constructing a tracer was failing having updated to JSON.

I've just added a new test that fails: https://github.com/pingles/zipkin-cpp-opentracing/blob/master/zipkin_opentracing/test/ot_tracer_factory_test.cc#L34

I'm going to try and sort it asap but wanted to report here for visibility.

I have run into an issue with specifying a collector which uses HTTPS.

I am no C++ dev but would it be easy to enable users to specify a collector url which is over https?
Maybe there is issues in the underlying impl. that I am missing but it looks like a quite trivial change in this piece of code?

Scanning dependencies of target zipkin_opentracing
[ 54%] Building CXX object zipkin_opentracing/CMakeFiles/zipkin_opentracing.dir/src/utility.cc.o
[ 56%] Building CXX object zipkin_opentracing/CMakeFiles/zipkin_opentracing.dir/src/propagation.cc.o
[ 58%] Building CXX object zipkin_opentracing/CMakeFiles/zipkin_opentracing.dir/src/dynamic_load.cc.o
[ 60%] Building CXX object zipkin_opentracing/CMakeFiles/zipkin_opentracing.dir/src/tracer_factory.cc.o
[ 62%] Building CXX object zipkin_opentracing/CMakeFiles/zipkin_opentracing.dir/src/opentracing.cc.o
/wasHome/zipkin-cpp-opentracing-master/zipkin_opentracing/src/opentracing.cc:270:17: error: cannot declare field 鈠ipkin::OtSpan::span_context_?to be of abstract type 鈠ipkin::OtSpanContext?
OtSpanContext span_context_;
^
/wasHome/zipkin-cpp-opentracing-master/zipkin_opentracing/src/opentracing.cc:49:7: note: because the following virtual functions are pure within 鈠ipkin::OtSpanContext?
class OtSpanContext : public ot::SpanContext {
^
In file included from /usr/local/include/opentracing/tracer.h:5:0,
from /wasHome/zipkin-cpp-opentracing-master/zipkin_opentracing/include/zipkin/opentracing.h:1,
from /wasHome/zipkin-cpp-opentracing-master/zipkin_opentracing/src/opentracing.cc:2:
/usr/local/include/opentracing/span.h:34:40: note: virtual std::unique_ptropentracing::v3_unstable::SpanContext opentracing::v3_unstable::SpanContext::Clone() const
virtual std::unique_ptr Clone() const noexcept = 0;
^
/wasHome/zipkin-cpp-opentracing-master/zipkin_opentracing/src/opentracing.cc: In constructor 鈠ipkin::OtSpan::OtSpan(std::shared_ptr&&, zipkin::SpanPtr&&, zipkin::Endpoin
t&&, const opentracing::v3_unstable::StartSpanOptions&)?
/wasHome/zipkin-cpp-opentracing-master/zipkin_opentracing/src/opentracing.cc:168:72: error: cannot allocate an object of abstract type 鈠ipkin::OtSpanContext?
OtSpanContext{zipkin::SpanContext{*span_}, std::move(baggage)};
^
/wasHome/zipkin-cpp-opentracing-master/zipkin_opentracing/src/opentracing.cc:49:7: note: since type 鈠ipkin::OtSpanContext?has pure virtual functions
class OtSpanContext : public ot::SpanContext {
^
/wasHome/zipkin-cpp-opentracing-master/zipkin_opentracing/src/opentracing.cc:170:64: error: cannot allocate an object of abstract type 鈠ipkin::OtSpanContext?
span_context_ = OtSpanContext{zipkin::SpanContext{*span_}};
^
/wasHome/zipkin-cpp-opentracing-master/zipkin_opentracing/src/opentracing.cc:49:7: note: since type 鈠ipkin::OtSpanContext?has pure virtual functions
class OtSpanContext : public ot::SpanContext {
^
/wasHome/zipkin-cpp-opentracing-master/zipkin_opentracing/src/opentracing.cc: In instantiation of 鈕pentracing::v3_unstable::expected<std::unique_ptropentracing::v3_unstable::SpanContext > zipkin::OtTracer::E
xtractImpl(Carrier&) const [with Carrier = std::basic_istream]?
/wasHome/zipkin-cpp-opentracing-master/zipkin_opentracing/src/opentracing.cc:334:30: required from here
/wasHome/zipkin-cpp-opentracing-master/zipkin_opentracing/src/opentracing.cc:380:75: error: cannot allocate an object of abstract type 鈠ipkin::OtSpanContext?
std::move(zipkin_span_context_maybe->value()), std::move(baggage))};
^
/wasHome/zipkin-cpp-opentracing-master/zipkin_opentracing/src/opentracing.cc:49:7: note: since type 鈠ipkin::OtSpanContext?has pure virtual functions
class OtSpanContext : public ot::SpanContext {
^
/wasHome/zipkin-cpp-opentracing-master/zipkin_opentracing/src/opentracing.cc:380:75: error: no matching function for call to 鈙td::unique_ptropentracing::v3_unstable::SpanContext::unique_ptr()?
std::move(zipkin_span_context_maybe->value()), std::move(baggage))};
^

Currently, each curl error has its string retrieved and printed to standard error. While this is fine for simple cases, there's some problems with it:

• it's a global, mutable change, and cerr printing is not synchronized
• it's invisible the consumer of the library
• if the consumer wishes to ignore the error, it's unnecessary overhead
• for high-volume tracing, it can be extremely verbose.

If there's some sort of permanent error (e.g. an incorrect collector host), the default reporting period of 500ms is used, and there's at least 1 span per that period, that's 2 lines printed per second. Although it's not too much if you're looking at it in the terminal while testing, it adds up to 172,800 lines per day.

It would be nice if the client could handle these errors themselves. I don't necessarily know what that would look like, but there's two ideas off the top of my head:

• template out a function to call with the curl error handle
• allow a std::function to be given to receive the curl error handle

The first is more performant, but might result in making the library more verbose. I'd have to think about it and look at code more.

As a side note, we could consider trying to establish the connection to the collector immediately, so we know about the problem before the first span is sent.

add http header "expect:" to skip http 1.1 100-continue

headers_.append("Content-Type: application/json");
headers_.append("expect:");
https://github.com/rnburn/zipkin-cpp-opentracing/blob/master/zipkin/src/zipkin_http_transporter.cc

I am facing this error, while executing the tutorial.cc code,
Can someone help me here in this

Example error message: "opentracing: SpanContext data corrupted in Extract carrier"

Thanks,
Dilli Babu S

We use GCP as our cloud provider, and for our kubernetes clusters we use the nginx-ingress with opentracing enabled, and we have a zipkin-gcp deployment that upload traces from the ingress to stackdriver.

That works fine, but when a request coming from an other google service like AppEngine, the x-cloud-trace-context-header is set, but since this lib ignores that header, the nginx-ingress trace will not be recored with the same trace-id etc, so they will not get connected.

The outgoing request will also have both the x-cloud-trace-context-header, and the x-b3-*-headers. Making everything confusing for the next service.

Would support for this header be something you could consider adding to this lib? or do you deem it out of scope? or do you see any other way of getting around this without having to write a whole new opentracing lib for stackdriver?

zipkin-cpp-opentracing/zipkin_opentracing/src/opentracing.cc:28:51: error: converting to ‘std::tuple<std::chrono::time_point<std::chrono::_V2::system_clock, std::chrono::duration<long int, std::ratio<1l, 1000000000l> > >, std::chrono::time_point<std::chrono::_V2::steady_clock, std::chrono::duration<long int, std::ratio<1l, 1000000000l> > > >’ from initializer list would use explicit constructor constexpr std::tuple<_T1, _T2>::tuple(_U1&&, _U2&&) [with _U1 = std::chrono::time_point<std::chrono::_V2::system_clock, std::chrono::duration<long int, std::ratio<1l, 1000000000l> > >; _U2 = std::chrono::time_point<std::chrono::_V2::steady_clock, std::chrono::duration<long int, std::ratio<1l, 1000000000l> > >; = void; _T1 = std::chrono::time_point<std::chrono::_V2::system_clock, std::chrono::duration<long int, std::ratio<1l, 1000000000l> > >; _T2 = std::chrono::time_point<std::chrono::_V2::steady_clock, std::chrono::duration<long int, std::ratio<1l, 1000000000l> > >]’
return {SystemClock::now(), SteadyClock::now()};