You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
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
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.
The text was updated successfully, but these errors were encountered: