Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Revert advice against backfilling of zeros #337

Closed
codefromthecrypt opened this issue Oct 8, 2019 · 0 comments · Fixed by #356
Closed

Revert advice against backfilling of zeros #337

codefromthecrypt opened this issue Oct 8, 2019 · 0 comments · Fixed by #356
Assignees

Comments

@codefromthecrypt
Copy link

Please remove or re-word the 3.2.2.3 advice around trace-id and explicitly using random characters instead of zeros to back-fill downgraded traces

3.2.2.3 trace-id
When a system operates with a trace-id that is shorter than 16 bytes, it SHOULD fill-in the extra bytes with random values rather than zeroes. Let's say the system works with an 8-byte trace-id like 3ce929d0e0e4736. Instead of setting trace-id value to 0000000000000003ce929d0e0e4736 it SHOULD generate a value like 4bf92f3577b34da6a3ce929d0e0e4736 where 4bf92f3577b34da6a is a random value or a function of time and host value.

This is a really bad idea as it will directly interfere with known practice and break traces that wouldn't break before. For example, if one node downgrades to 64-bit, making 2 outgoing calls, then they propagate random data.. it will appear now as 3 different traces.

There was a thread about the zeros thing on jaeger jaegertracing/jaeger-client-java#649 (comment)

In the jaeger thread, there was an interpretation that "When a system operates with a trace-id that is shorter than 16 bytes" it means only when it is provisioning (generating) a trace ID. I think it is dangerous to make that assumption.

It is commonplace for components to inherit (operate with) IDs provisioned or generated upstream. For example, it is commonly the case that proxies provision trace IDs, and sometimes nodes downstream can't push 128bit IDs, so they downgrade.

If the intent was in fact to say that the backfilling random was about generating, it is entirely unintuitive. If you can generate random 64 bit ID and also backfill 64 more bits of random characters, you can generate 128 bit ID! I don't believe many people would think that the associated paragraph is about generating IDs.

My strong recommendation is to be clear about what you are discussing. 3.2.2.3 looks almost obviously a discussion of how to work/operate in mixed environments, and makes a troubling recommendation. Either re-word this to say it is about ID provisioning, or please remove the bad advice about back filling randomly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants