B3 context propagation #86
Conversation
Constant lookup will search in Module.nesting before looking up the inheritance chain, which makes constants hard to override when subclassing. This commit prefixes constants in the LightStep propagator with self.class in order to steer lookup to the inheritance chain.
This commit introduces a B3 Propagator where keys are properly injected and extracted under the proper names. Special handling of the trace id and sampled flag will come in subsequent commits.
| @@ -0,0 +1,125 @@ | |||
| #frozen_string_literal: true | |||
|
|
|||
| module LightStep | |||
There was a problem hiding this comment.
The LightStepPropagator was extracted out of the LightStep::Tracer class.
| module LightStep | ||
| # SpanContext holds the data for a span that gets inherited to child spans | ||
| class SpanContext | ||
| attr_reader :id, :trace_id, :baggage | ||
| attr_reader :id, :trace_id, :trace_id16, :sampled, :baggage |
There was a problem hiding this comment.
The SpanContext maintains an 8 byte and 16 byte trace id. The 16 byte trace id is either the original, or an 8 byte id padded with zeros on the left.
|
|
||
| def pad_id(id) | ||
| return id unless id && id.size == 16 | ||
| "#{ZERO_PADDING}#{id}" |
There was a problem hiding this comment.
I'm following the convention set out in the JS PR, but I am wondering if we should be padding on the right side of an 8 byte id. There was some discussion and a recent PR around this in the W3C Trace Context repo.
There was a problem hiding this comment.
I think, conventionally, we only pad the LHS of the id. I'm not sure what'd happen if you added the padding to the RHS - presumably it'd all convert to the same uint64 or whatever.
|
The build appears to be failing on Circle for reasons other than the code changes here. It's failing to install dependencies. I'm troubleshooting this in #87. Update:
Latest update:
|
This updates our build matrix to test against Ruby versions that are still under maintenance by the Ruby core team.
… them These were switched to use the mutating versions to spare two string allocations in a previous commit.
|
|
||
| def pad_id(id) | ||
| return id unless id && id.size == 16 | ||
| "#{ZERO_PADDING}#{id}" |
There was a problem hiding this comment.
I think, conventionally, we only pad the LHS of the id. I'm not sure what'd happen if you added the padding to the RHS - presumably it'd all convert to the same uint64 or whatever.
This PR adds support for B3 context propagation. A user is able to specify a propagator instance during tracer initialization. The default propagation format is LightStep. See the example below:
Currently Implemented
Not Implemented
This work might be incomplete, however, I figured I'd open this PR as a starting point for discussion as it's somewhat unclear what level of support is required. The current javascript PR implements the multiple header format, does not propagate the sampled state, or implement the debug flag or single header format. The python PR is the most complete and as it implements both multiple and single header formats, propagates the sampled state and debug trace flag.