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
I noticed that while AWS is Otel-compatible, it does not (yet?) support W3C TraceContext for propagation, which is the default used in Otel. Instead, to support it in my Otel Tracer, I need to add an additional propagator (Injector/Extractor) for AWS X-Ray's TraceID format and an IDGenerator to generate trace ids in X-Ray format.
While implementing this inside OpenTelemetryTracer I first thought about defining a new protocol called OpenTelemetryTraceContextPropagator mirroring Instrument, which requires both inject & extract methods.
protocolOpenTelemetryTraceContextPropagator{func extract<Carrier, Extract>(_ carrier:Carrier, into baggage:inoutBaggage, using extractor:Extract)where Extract:Extractor, Extract.Carrier ==Carrierfunc inject<Carrier, Inject>(_ baggage:Baggage, into carrier:inoutCarrier, using injector:Inject)where Inject:Injector, Inject.Carrier ==Carrier}
Adding a Propagator protocol
As mentioned above, the Propagator protocol I defined mirrored our Instrument protocol exactly. One option would've been to conform my AWSXrayProtopagator to Instrument instead of defining my own type, but that feels somewhat weird as it's not a full-fletched cross-cutting-tool.
This leads me to believe that we might want to introduce a first-class Propagator protocol (that could be "inherited" by the Instrument protocol).
I'd like to present another use-case for a Propagator protocol:
Jaeger offers an additional mechanism to propagate baggage values, the jaeger-baggage HTTP header. The HotROD example makes use of this for a session and request id.
For our implementation of the Jaeger HotROD example using the Apodini framework, we implemented a JaegerBaggageExtractorInstrument to facility this functionality with swift-distributed-tracing. Same as with the AwsXrayPropagator, it is not a fully fledged Instrument and would benefit from the specificity a first-class Propagator protocol provides.
Preface
I noticed that while AWS is Otel-compatible, it does not (yet?) support W3C TraceContext for propagation, which is the default used in Otel. Instead, to support it in my Otel Tracer, I need to add an additional propagator (
Injector
/Extractor
) for AWS X-Ray's TraceID format and anIDGenerator
to generate trace ids in X-Ray format.While implementing this inside
OpenTelemetryTracer
I first thought about defining a new protocol calledOpenTelemetryTraceContextPropagator
mirroringInstrument
, which requires bothinject
&extract
methods.Adding a Propagator protocol
As mentioned above, the
Propagator
protocol I defined mirrored ourInstrument
protocol exactly. One option would've been to conform myAWSXrayProtopagator
toInstrument
instead of defining my own type, but that feels somewhat weird as it's not a full-fletched cross-cutting-tool.This leads me to believe that we might want to introduce a first-class
Propagator
protocol (that could be "inherited" by theInstrument
protocol).See Also
AwsXrayPropagator
AwsXrayIdGenerator
The text was updated successfully, but these errors were encountered: