Consider changing randomness of traceID to 96bits + 32bit timestamp

[semistrict]

Copied from: census-instrumentation/opencensus-go#489

This would support all the major cloud provider's trace systems while still preserving a high degree of randomness, 96 bits. As it stands, compatibility with AWS X-Ray is awkward when using traceIDs generated by open census.

[semistrict]

This sounds like an easy win with no downside.

Context is that X-Ray TraceIDs are defined to contain a timestamp, see: https://docs.aws.amazon.com/xray/latest/api/API_PutTraceSegments.html

[bogdandrutu]

This may hugely affect backends which rely on trace_id being uniformly distributed. Think about somebody using HBase with a key "trace_id" then you create a big hotspot there. Before us pushing hard on supporting AWS I would like to see from some of the AWS devs the real motivation to have the timestamp in the trace_id.

If we really need to support this model probably I would put the 96 random bits at the beginning.

[semistrict]

There should be no problem putting the random bits at the beginning. Or for that matter, putting them anywhere in the string. We only need to be able to extract them in the XRay exporter or when propagating using the XRay format. The internal opencensus TraceID representation is independent of how it's serialized to specific formats.

[savaki]

Given that X-Ray is in production use, I doubt aws would change how they generate trace ids. However, it may be enough to allow the TraceID generator to be specified by option.

[semistrict]

I think we should make it pluggable for now and if it works out well we can look into making it default.

[bogdandrutu]

We decided to go with the approach of allowing people to configure an internal IdGenerator that will be set when using AWS X-ray exporter.

[codefromthecrypt]

Only impact is that without uniform deployment it wont work. Since we arent doing this as a given default, anything amazon downstream cant use the ids and will restart. Seems a missed opportunity