fholzhauser
commented
6 years ago Hi Christopher,
It is probably because the Zipkin thrift spec says that it is an i64 type. It didn't really occur to us to provide an interface that accepts 8 byte binary (or any other) format.
I think, for now, converting the 8 byte binary to a 64 bit integer is indeed a good way to work around your issue.
In Erlang, it could be something like : TraceIdBin = <<"TraceId1">>, <<Id:64>> = TraceIdBin, Id.
or in Elixir : traceidbin="TraceId1"; <<id::64>>=traceidbin; id
Also please note (as mentioned in the readme), that otter is not aimed to comply with the whole OpenTracing spec. It is only a fairly liberal implementation of the main concepts, with some operational extras (like filter rules and counters/snaps), that allows sending spans to Zipkin compatible trace collectors from Erlang/Elixir apps. The main things we had in mind were : easy integration (e.g. no dependencies), simplicity and code instrumentation convenience.
Please let us know if you need any further assistance.
Regards, Ferenc
Is there any reason otter only supports integers for traceid?
My ingress controller generates a uuid and I am unable to add spans to it. I end up generating my own random 64bit integer, and lose visibility into the initial trace.
My ingress controller is utilizing Ambassador, which is Envoy under the hood on a Kubernetes cluster.
From what I can tell the OpenTracing spec does not limit traceid's to integers, just 64bit binaries.
Maybe there is a conversion to integer I can do to the original UUID that will maintain the traceid across all services?
Envoy is automatically sending the traces to Zipkin and I'm able to view them, would be great if they were correlated together.