[
https://issues.apache.org/jira/browse/HTRACE-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14630710#comment-14630710
]
Colin Patrick McCabe commented on HTRACE-209:
---------------------------------------------
While I agree that spanID and traceID together are 128 bits, in practice our
span receivers have assumed that both spanID and traceID are unique on their
own. For example, htraced currently builds an index from 64-bit span ID to
span data. I think htrace-hbase does something similar. These indices will
have problems if there are collisions in 64-bit space. Some of the discussion
we've been having with the Zipkin folks indicates that 64-bit collisions
actually do happen multiple times a day on some zipkin installations.
The big issue with trace ID has always been that it doesn't make sense in a
multi-parent world. If both span A (with traceID A) and span B (with traceID
B) can be parents of span C, which traceID does C get? TraceID only makes
sense if there can only be 0 or 1 parent for each span. Trace ID is also
unnecessary-- you can deduce everything it is telling you just by looking up
the parents yourself.
The approach I have taken in this patch is to enlarge span ID to 128 bits.
Top-level spans get a completely random 128-bit sequence. When creating a new
child span, I make the upper 64 bits of the child's span ID the same as the
parent's, and the bottom 64 bits random. The zipkin span receiver can continue
to treat the upper 64 bits as a "trace ID" and the bottom as a "span ID." All
the other receivers will simply treat the 128-bit ID as a span ID.
One way of looking at this is that I combined traceID and spanID into a single
number. But the big gain in this patch is that htraced is now not vulnerable
to 64-bit collisions. I would like to fix this for htrace-hbase as well in a
follow-on. We also now have a better format for span ID, based on the standard
UUID format: {{00000000-0000-0000-0000-000000000000}}. I think using a 128-bit
ID is much more elegant than trying to retrofit everything that needs to
uniquely identify a span to pass two different (and confusingly named) IDs.
> Make span ID 128 bit to avoid collisions
> ----------------------------------------
>
> Key: HTRACE-209
> URL: https://issues.apache.org/jira/browse/HTRACE-209
> Project: HTrace
> Issue Type: Sub-task
> Affects Versions: 4.0
> Reporter: Colin Patrick McCabe
> Assignee: Colin Patrick McCabe
>
> Make span ID 128 bit to avoid collisions in htrace 4.x
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
