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

Introduce Propagator protocol #44

Open
slashmo opened this issue Feb 21, 2021 · 2 comments
Open

Introduce Propagator protocol #44

slashmo opened this issue Feb 21, 2021 · 2 comments
Milestone

Comments

@slashmo
Copy link
Collaborator

slashmo commented Feb 21, 2021

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 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.

protocol OpenTelemetryTraceContextPropagator {
    func extract<Carrier, Extract>(_ carrier: Carrier, into baggage: inout Baggage, using extractor: Extract)
        where Extract: Extractor, Extract.Carrier == Carrier

    func inject<Carrier, Inject>(_ baggage: Baggage, into carrier: inout Carrier, 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).


See Also

@moritzsternemann
Copy link
Contributor

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.

@ktoso ktoso added this to the 1.x milestone Feb 24, 2023
@ktoso
Copy link
Member

ktoso commented Feb 24, 2023

I think this could be done post 1.0 🤔

@ktoso ktoso modified the milestones: 1.x, 1.1.x May 31, 2023
@FranzBusch FranzBusch removed the 0 - new label Sep 6, 2024
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

No branches or pull requests

4 participants