[Pitch] Swift Distributed Tracing

We would like to pitch Swift Distributed Tracing to the SSWG.

Proposal swift-server/sswg/pull/84
Authors Moritz Lang, Konrad 'ktoso' Malawski
Proposed Maturity Level Incubating


Whereas Logging and Metrics enables you to instrument specific parts of an application, Distributed Tracing provides a holistic view on an entire distributed system. Together with these two, Distributed Tracing will complete the "three pillars of observability".

As with Logging and Metrics, the community will benefit most from Distributed Tracing if it is implemented in libraries and frameworks directly using one common API. End-users should be able to freely choose a suitable backend implementation without having to change the libraries or frameworks they're using.

Proposed Solution

Swift Distributed Tracing revolves around creating spans, which together form a tree-like structure. A trace can be made up by spans recorded in a single service, or propagated across multiple services. Swift Distributed Tracing uses the task-local based Swift Service Context to implement propagation transparently, without the need of manual context passing.

Our proposed solution is a library which targets three "roles":

  • End-Users
  • Library & framework authors
  • Tracer backend implementations


End-users are the ones benefiting from Distributed Tracing. They choose a Tracing backend that suits their needs, use libraries that have built-in Swift Distributed Tracing support, and augment their own code with manual instrumentation.

Library & framework authors

Libraries/Frameworks such as HTTP servers/clients, database libraries, etc. know best how to instrument their library's internals. They implement generic tracing support using the Swift Distributed Tracing API without a specific tracing backend in mind.


Tracer backend implementations

The final piece of the puzzle are tracer backend implementations. They provide vendor-specific support for exporting tracing spans.


Swift OTel exposes a tracer that exports to an OpenTelemetry Collector. This already allows adopters of this tracing library to export to popular backends compatible with OpenTelemetry, such as Zipkin, Jaeger, Honeycomb, and more.

Maturity Justification

We are proposing this package at the "Incubation" level of maturity. We believe this package to be an important building block of the server ecosystem, in the same way swift-log and swift-metrics are adopted across many server and client libraries.

The project has matured for over 3 years, has multiple active maintainers and fulfills adoption requirements in production.

We look forward to your feedback!


Really awesome to see the pitch, thank you @slashmo !

And I've followed up here with [Pitch] Swift Service Context since that's the core dependency of tracing :slight_smile: Those are separate packages but are closely related, so we think they can be reviewed at the same time, though as separate proposals / packages.

1 Like

We need a common solution for tracing and this follows a similar pattern to swift-log/metrics where the backend details are abstracted away.

I have followed this package from its inception and a large amount of thought has gone into its implementation.