{"action":"created","issue":{"url":"https://api.github.com/repos/openzipkin/zipkin/issues/1262","repository_url":"https://api.github.com/repos/openzipkin/zipkin","labels_url":"https://api.github.com/repos/openzipkin/zipkin/issues/1262/labels{/name}","comments_url":"https://api.github.com/repos/openzipkin/zipkin/issues/1262/comments","events_url":"https://api.github.com/repos/openzipkin/zipkin/issues/1262/events","html_url":"https://github.com/openzipkin/zipkin/issues/1262","id":174228407,"number":1262,"title":"RFC: Transition to 128bit trace ids (still 64bit span ids)","user":{"login":"adriancole","id":64215,"avatar_url":"https://avatars.githubusercontent.com/u/64215?v=3","gravatar_id":"","url":"https://api.github.com/users/adriancole","html_url":"https://github.com/adriancole","followers_url":"https://api.github.com/users/adriancole/followers","following_url":"https://api.github.com/users/adriancole/following{/other_user}","gists_url":"https://api.github.com/users/adriancole/gists{/gist_id}","starred_url":"https://api.github.com/users/adriancole/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/adriancole/subscriptions","organizations_url":"https://api.github.com/users/adriancole/orgs","repos_url":"https://api.github.com/users/adriancole/repos","events_url":"https://api.github.com/users/adriancole/events{/privacy}","received_events_url":"https://api.github.com/users/adriancole/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":16,"created_at":"2016-08-31T09:39:30Z","updated_at":"2016-09-01T01:46:12Z","closed_at":null,"body":"[Many times](https://groups.google.com/forum/#!msg/zipkin-user/7BUNqrtG5oo/Isf_UyMQ2FMJ;context-place=forum/zipkin-user) over the last years, we've had folks ask about 128 bit trace ids.\r\n\r\nThere have been a few use-cases mentioned...\r\n* archiving traces longer than a couple days (concern with collisions when retrieving by id)\r\n* using externally generated ids as trace identifiers (ex AWS lambda UUID)\r\n* joining traces that have 128bit identifiers (ex Dapper/Cloud Trace now use 128bit trace ids)\r\n\r\nDoing this comes at a cost of figuring out how to do interop, but that's well-charted territory:\r\n* Zipkin already decouples trace ids from span/parent ids; This reduces scope to only trace ids.\r\n* Zipkin trace identifier encoding is hex, which is easy to widen and detect.\r\n* There exists practice of people padding 64bit ids to 128 bit, and bit choosing to reduce to 64 bit.\r\n* Cassandra and MySQL support blobs in key clauses, and elasticsearch can as easily index a hex string of length 16 as it can one of length 32.\r\n\r\nPractically speaking we'd need to do the following to make this possible:\r\n* B3 - Update both http and binary forms to optionally accept wider trace ids\r\n* Thrift - add an optional binary field to hold the wider id\r\n* Model - Add Span.Builder.traceId(blob) and pad .traceId(long) to fit 128bits\r\n* Storage\r\n  * overload getTraceById to accept a 128bit blob.\r\n  * add 128bit column to mysql\r\n  * add 128bit index to cassandra\r\n  * write both 64 and 128bit ids until Model v2\r\n\r\nProvided we don't creep scope to also change span, parent id encoding, I think we can actually do this, and end up with an incremental win on the model that can help us bridge into systems that use wider ids increasingly often.\r\n"},"comment":{"url":"https://api.github.com/repos/openzipkin/zipkin/issues/comments/243953309","html_url":"https://github.com/openzipkin/zipkin/issues/1262#issuecomment-243953309","issue_url":"https://api.github.com/repos/openzipkin/zipkin/issues/1262","id":243953309,"user":{"login":"adriancole","id":64215,"avatar_url":"https://avatars.githubusercontent.com/u/64215?v=3","gravatar_id":"","url":"https://api.github.com/users/adriancole","html_url":"https://github.com/adriancole","followers_url":"https://api.github.com/users/adriancole/followers","following_url":"https://api.github.com/users/adriancole/following{/other_user}","gists_url":"https://api.github.com/users/adriancole/gists{/gist_id}","starred_url":"https://api.github.com/users/adriancole/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/adriancole/subscriptions","organizations_url":"https://api.github.com/users/adriancole/orgs","repos_url":"https://api.github.com/users/adriancole/repos","events_url":"https://api.github.com/users/adriancole/events{/privacy}","received_events_url":"https://api.github.com/users/adriancole/received_events","type":"User","site_admin":false},"created_at":"2016-09-01T01:46:12Z","updated_at":"2016-09-01T01:46:12Z","body":"@yurishkuro didn't mean to distract the issue. you are right that in thrift there's a \"binary\" compiler hint that says the STRING field is being used for opaque bytes. I changed my example above."}}
{"actor":{"display_login":"adriancole"}}