Implementing xrayTraceIDRatioBasedsampler

[alanprot]

Signed-off-by: Alan Protasio approtas@amazon.com

Hi..

The default Otel TraceIDRatioBased does not work with XRay as it make the decision based on the first 8 bytes of the traceId -> which are not random on traces generated with the xray.NewIDGenerator().

This PR creates a similar sampler that works on XRAY as it makes the decision based on the last 8 bytes of the trace id.

[codecov]

Codecov Report

Merging #3090 (09be06f) into main (2f95a2b) will increase coverage by 0.1%.
The diff coverage is 93.7%.

Additional details and impacted files

@@           Coverage Diff           @@
##            main   #3090     +/-   ##
=======================================
+ Coverage   69.0%   69.2%   +0.1%     
=======================================
  Files        147     148      +1     
  Lines       6884    6916     +32     
=======================================
+ Hits        4754    4787     +33     
  Misses      2011    2011             
+ Partials     119     118      -1     

Impacted Files	Coverage Δ
samplers/aws/xray/traceid_ratio_sampler.go	93.7% <93.7%> (ø)
...ion/google.golang.org/grpc/otelgrpc/interceptor.go	83.9% <0.0%> (+0.9%)	⬆️

[Aneurysm9]

Just a couple nits.

[willarmiros]

Thanks for creating this PR! This is interesting to see, because I know in Java the TraceIdRatioBased sampler reads from the trailing bytes rather than the leading bytes by default. We even have a test for it. So it makes me wonder, is the correct fix to make a new sampler for X-Ray IDs only (which may be very confusing for customers to use), or could we change the default traceIdRatioBased sampler to just read from the trailing bytes in the main Go SDK?

[alanprot]

Thanks for creating this PR! This is interesting to see, because I know in Java the TraceIdRatioBased sampler reads from the trailing bytes rather than the leading bytes by default. We even have a test for it. So it makes me wonder, is the correct fix to make a new sampler for X-Ray IDs only (which may be very confusing for customers to use), or could we change the default traceIdRatioBased sampler to just read from the trailing bytes in the main Go SDK?

I had the same question but I guess I took the safer route.. idk if changing the default one will break some other use cases ..

What the others think ?

[Aneurysm9]

I think it would be ideal to fix in the base sampler. I'm not aware of anything that should break if the position of the sampled bits changes. open-telemetry/opentelemetry-go#3557 may replace this PR.

[hanyuancheung]

Please add a note for exported func.

[tomwans]

Take a look at a related PR: open-telemetry/opentelemetry-go#3557 which brings the Go SDK in line with the Java and Python SDKs, which all by default sample from the trailing bytes.

[Aneurysm9]

This is fixed via open-telemetry/opentelemetry-go#3557.