Announcement: Swift Distributed Tracing repositories now live!

Hello everyone,
I'm excited to announce the immediate availability of apple/swift-distributed-tracing package!

Similar to Swift Log and Swift Metrics, this package is only an API, intended to be implemented by various tracers and instrumentation systems. With Distributed Tracing added to the mix, we are near completing the SSWG's original goal of providing Swift with libraries for all three "Pillars of Observability"

And thanks to @slashmo and @pokryfka's prior work we already have tracer implementations which as soon as they adopt the new repository of those packages will support both: Jaeger, Zipkin and XRay tracing for Swift :partying_face:

The XRay tracer integration is also going to be very interesting for users of Swift AWS Lambda Runtime which we announced earlier this year since it enables automatic tracing for your lambda functions, resulting in graphs such as this:

(PoC PR)

Google Summer of Code 2020

These repositories, are the continuation of the efforts started earlier this year in the #gsoc-2020 summer of code project Server Distributed Tracing where @slashmo prototyped a lot of the beginnings of this work.

Thanks again for your efforts back then, and your continued afforts on this long after the gsoc has completed! :clap:

The repositories covered by this announcement:

We would also like to thank the SSWG members, and various server-side open source projects for their invaluable feedback during the early phases of this project -- thank you!

Summary: Distributed Tracing

Distributed Tracing allows application to "trace" execution of (usually) server side applications and produce visual trace views by composing spans emitted by libraries, frameworks and defined by application developers themselves.

Tracing allows for simple co-relation of failures to specific requests; injecting trace identifiers into log statements, and also large scale performance profiling of server systems. It enables developers to answer questions "why" and "when" about faulty or slow request processing, and best of all: if adopted by the ecosystem -- at very little additional programming cost.

By using tracing your multi-node distributed system, including all asynchronous code along the way, http/grpc calls and database interactions along the way become as easy to inspect and profile as using a profiler on a local machine.

We are very excited to begin the journey to bring these powerful capabilities to the hands of Serverside Swift Developers!

Adoption and Future perspectives

We're a little bit "soft launching" this API, without the usual blog and fanfare, because of our ongoing work with the Swift Concurrency effort, which may significantly simplify the "context passing problem" which in today's API is solved by explicit context passing.

We will be submitting a Swift Evolution pitch/proposal very soon, which could be used to improve the APIs significantly, by allowing for Task-local values (similar to thread locals, however natively working with Swift's Structured Concurrency concepts (swift evolution thread)), which could be used to natively to the swift concurrency model pass baggage context information through asynchronous functions, without the annoyance of having to do so explicitly.

The goal is to achieve the best possible usability for these context passing APIs thanks to a more integrated approach with the language's runtime.

The API is designed purposefully to easily support OpenTelemetry conventions, and offers a special support package TracingOpenTelemetrySupport to embrace all wording and attributes defined by that effort.


Yay, so excited to see this!

By the way, it looks like the links for tracing-baggage and tracing-baggage-core are invalid

1 Like

Thanks! Looking forward to working out support in RediStack :slight_smile:

Fixed links!