Traces not showing up in jaeger.

[rnburn]

I'm running this small c++ program (matching the go quickstart example).

#include <jaegertracing/Tracer.h>
#include <opentracing/tracer.h>
#include <chrono>
#include <thread>

int main() {
  auto config = jaegertracing::Config(
      false,
      jaegertracing::samplers::Config(jaegertracing::kSamplerTypeConst, 1),
      jaegertracing::reporters::Config(
          jaegertracing::reporters::Config::kDefaultQueueSize,
          std::chrono::seconds(1), true));
  auto tracer = jaegertracing::Tracer::make("wherearemyspans?", config);
  auto span = tracer->StartSpan("abc");
  std::this_thread::sleep_for(std::chrono::milliseconds{10});
  span->Finish();
  std::this_thread::sleep_for(std::chrono::seconds{5});
  tracer->Close();
  return 0;
}

If I start the Jaeger's docker server

docker run -d -e COLLECTOR_ZIPKIN_HTTP_PORT=9411 -p5775:5775/udp -p6831:6831/udp -p6832:6832/udp \
  -p5778:5778 -p16686:16686 -p14268:14268 -p9411:9411 jaegertracing/all-in-one:latest

it shows the service name "wherearemyspans?" (so the server received something); but if I try to find traces, I don't see anything.

Running the go example, the spans show up all the time.

Any idea what could be going on?

[yurishkuro]

this might be a sign of the wrong timestamps emitted by C++ client. Jaeger thrift defines timestamps as microseconds since epoch. If they are not scaled appropriately, then the search may be mismatching on the time range.

[isaachier]

I had this issue before with @bcherukuri. It had been an issue in the client usage of system_time vs. steady_time. That was already addressed and we got traces. I'll try your example locally and get back to you.

[isaachier]

Found your issue. Relates to opentracing/opentracing-cpp#29. Try setting timestamps manually and see the results.

[isaachier]

Regardless, I somehow get the spans using your code locally.

[isaachier]

[rnburn]

Yes, it I see them if I manually set the timestamps.

It looks like Jaeger is missing logic like this to set the timestamps if they're default constructed.

[yurishkuro]

It looks like Jaeger is missing logic

do you mean the backend? Timestamps must be set by the tracer impl.

[isaachier]

But I ran your example and it worked. Are you sure it is not something I fixed recently?

[rnburn]

I mean the client library. The equivalent of what's done here in the go tracer.

[isaachier]

I'm also not sure why the convenience method StartSpan in the base class does not simply do this before passing the timestamp onto the more detailed StartSpanWithOptions pure virtual method.

[rnburn]

Isn't that what you complained about in this issue: opentracing/opentracing-cpp#29.

But regardless of whether StartSpan sets the timestamps or not you should be able to call StartSpanWithOptions using default constructed timestamps and have the tracer determine the times for you. That's the behavior in Go as well.

[isaachier]

It is the same issue indeed. My only qualm with the comparison with Go is that Go uses nil which is not a valid timestamp. Technically, January 1st, 1970 12:00:00 A.M. is a timestamp, even if no one should practically use it.

[rnburn]

Go's not using nil. It sets if time.IsZero() (see the comments) which is the same thing as setting to the epoch.