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 |
Motivation
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
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.
Examples
Tracer backend implementations
The final piece of the puzzle are tracer backend implementations. They provide vendor-specific support for exporting tracing spans.
Examples
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!
Those are separate packages but are closely related, so we think they can be reviewed at the same time, though as separate proposals / packages.