diff --git a/README.md b/README.md index 8e67175..ac4be1d 100644 --- a/README.md +++ b/README.md @@ -8,583 +8,21 @@ While Swift Distributed Tracing allows building all kinds of _instruments_, whic > Warning: The docs below, showcasing the 0.3.x series of the logging integration are **deprecated** thanks to the latest inclusion of [metadata providers in swift-log](https://github.com/apple/swift-log/pull/238). With the introduction of [task local values in Swift](https://developer.apple.com/documentation/swift/tasklocal), and metadata providers in swift-log, the `LoggingContext` pattern showcased below has become an _anti-pattern_. Please give us a moment to finish the [new documentation PR #69](https://github.com/apple/swift-distributed-tracing/pull/69), which will explain the new integration style in detail. > -> Tracer APIs will not change substantially, as we're closing up on announcing version 1.0. Please look forward to beta releases very soon! +> APIs will not change substantially, as we're closing up on announcing version 1.0. Please look forward to beta releases very soon! --- -This project uses the context progagation type defined independently in: +This project uses the context propagation type defined independently in: - 🧳 [swift-distributed-tracing-baggage](https://github.com/apple/swift-distributed-tracing-baggage) -- [`Baggage`](https://apple.github.io/swift-distributed-tracing-baggage/docs/current/InstrumentationBaggage/Structs/Baggage.html) (zero dependencies) --- -## Table of Contents +## Documentation -* [Compatibility](#compatibility) - + [Tracing Backends](#tracing-backends) - + [Libraries & Frameworks](#libraries--frameworks) -* [Getting Started](#getting-started) - + [Dependencies & Tracer backend](#dependencies--tracer-backend) - + [Benefiting from instrumented libraries/frameworks](#benefiting-from-instrumented-libraries-frameworks) - + [Instrumenting your code](#instrumenting-your-code) - + [More examples](#more-examples) -* [In-Depth Guide](#in-depth-guide) -* In-Depth Guide for **Application Developers** - + [Setting up instruments & tracers](#setting-up-instruments--tracers) - + [Bootstrapping the InstrumentationSystem](#bootstrapping-the-instrumentationsystem) - + [Context propagation](#passing-context-objects) - + [Creating context objects](#creating-context-objects--and-when-not-to-do-so-) - + [Working with `Span`s](#spans) -* In-Depth Guide for: **Library/Framework developers** - + [Instrumenting your software](#library-framework-developers--instrumenting-your-software) - + [Extracting & injecting Baggage](#extracting--injecting-baggage) - + [Tracing your library](#tracing-your-library) -* In-Depth Guide for: **Instrument developers** - + [Creating an `Instrument`](#instrument-developers--creating-an-instrument) - + [Creating a `Tracer`](#creating-a--tracer-) -* [Contributing](#contributing) +> Warning: A significant update of the reference documentation is in thr works right now, please refer to this PR: ---- - -## Compatibility - -This project is designed in a very open and extensible manner, such that various instrumentation and tracing systems can be built on top of it. - -The purpose of the tracing package is to serve as common API for all tracer and instrumentation implementations. Thanks to this, libraries may only need to be instrumented once, and then be used with any tracer which conforms to this API. - - -### Tracing Backends - -Compatible `Tracer` implementations: - -| Library | Status | Description | -| ------- | ------ | ----------- | -| [@slashmo](https://github.com/slashmo) / [**OpenTelemetry** Swift](https://github.com/slashmo/opentelemetry-swift) | Complete | Exports spans to OpenTelemetry Collector; **X-Ray** & **Jaeger** propagation available via extensions. | -| [@pokrywka](https://github.com/pokryfka) / [AWS **xRay** SDK Swift](https://github.com/pokryfka/aws-xray-sdk-swift) | Complete (?) | ... | -| _Your library?_ | ... | [Get in touch!](https://forums.swift.org/c/server/43) | - -If you know of any other library please send in a [pull request](https://github.com/apple/swift-distributed-tracing/compare) to add it to the list, thank you! - -### Libraries & Frameworks - -As this API package was just released, no projects have yet fully adopted it, the following table for not serves as reference to prior work in adopting tracing work. As projects move to adopt tracing completely, the table will be used to track adoption phases of the various libraries. - -| Library | Integrates | Status | -| ------- | ---------- | ------ | -| AsyncHTTPClient | Tracing | Old* [Proof of Concept PR](https://github.com/swift-server/async-http-client/pull/289) | -| Swift gRPC | Tracing | Old* [Proof of Concept PR](https://github.com/grpc/grpc-swift/pull/941) | -| Swift AWS Lambda Runtime | Tracing | Old* [Proof of Concept PR](https://github.com/swift-server/swift-aws-lambda-runtime/pull/167) | -| Swift NIO | Baggage | Old* [Proof of Concept PR](https://github.com/apple/swift-nio/pull/1574) | -| RediStack (Redis) | Tracing | Signalled intent to adopt tracing. | -| Soto AWS Client | Tracing | Signalled intent to adopt tracing. | -| _Your library?_ | ... | [Get in touch!](https://forums.swift.org/c/server/43) | - -> `*` Note that this package was initially developed as a Google Summer of Code project, during which a number of Proof of Concept PR were opened to a number of projects. -> -> These projects are likely to adopt the, now official, Swift Distributed Tracing package in the shape as previewed in those PRs, however they will need updating. Please give the library developers time to adopt the new APIs (or help them by submitting a PR doing so!). - -If you know of any other library please send in a [pull request](https://github.com/apple/swift-distributed-tracing/compare) to add it to the list, thank you! - ---- - -## Getting Started - -In this short getting started example, we'll go through bootstrapping, immediately benefiting from tracing, and instrumenting our own synchronous and asynchronous APIs. The following sections will explain all the pieces of the API in more depth. When in doubt, you may want to refer to the [OpenTelemetry](https://opentelemetry.io), [Zipkin](https://zipkin.io), or [Jaeger](https://www.jaegertracing.io) documentations because all the concepts for different tracers are quite similar. - -### Dependencies & Tracer backend - -In order to use tracing you will need to bootstrap a tracing backend ([available backends](#backends)). - -When developing an *application* locate the specific tracer library you would like to use and add it as an dependency directly: - -```swift -.package(url: "", // the specific tracer - ] -), -``` - -Then (in an application, libraries should _never_ invoke `bootstrap`), you will want to bootstrap the specific tracer you want to use in your application. A `Tracer` is a type of `Instrument` and can be offered used to globally bootstrap the tracing system, like this: - - -```swift -import Tracing // the tracing API -import AwesomeTracing // the specific tracer - -InstrumentationSystem.bootstrap(AwesomeTracing()) -``` - -If you don't bootstrap (or other instrument) the default no-op tracer is used, which will result in no trace data being collected. - -### Benefiting from instrumented libraries/frameworks - -**Automatically reported spans**: When using an already instrumented library, e.g. an HTTP Server which automatically emits spans internally, this is all you have to do to enable tracing. It should now automatically record and emit spans using your configured backend. - -**Using baggage and logging context**: The primary transport type for tracing metadata is called `Baggage`, and the primary type used to pass around baggage context and loggers is `LoggingContext`. Logging context combines baggage context values with a smart `Logger` that automatically includes any baggage values ("trace metadata") when it is used for logging. For example, when using an instrumented HTTP server, the API could look like this: - -```swift -SomeHTTPLibrary.handle { (request, context) in - context.logger.info("Wow, tracing!") // automatically includes tracing metadata such as "trace-id" - return try doSomething(request context: context) -} -``` - -In this snippet, we use the context logger to log a very useful message. However it is even more useful than it seems at first sight: if a tracer was installed and extracted tracing information from the incoming request, it would automatically log our message _with_ the trace information, allowing us to co-relate all log statements made during handling of this specific request: - -``` -05:46:38 example-trace-id=1111-23-1234556 info: Wow tracing! -05:46:38 example-trace-id=9999-22-9879797 info: Wow tracing! -05:46:38 example-trace-id=9999-22-9879797 user=Alice info: doSomething() for user Alice -05:46:38 example-trace-id=1111-23-1234556 user=Charlie info: doSomething() for user Charlie -05:46:38 example-trace-id=1111-23-1234556 user=Charlie error: doSomething() could not complete request! -05:46:38 example-trace-id=9999-22-9879797 user=alice info: doSomething() completed -``` - -Thanks to tracing, and trace identifiers, even if not using tracing visualization libraries, we can immediately co-relate log statements and know that the request `1111-23-1234556` has failed. Since our application can also _add_ values to the context, we can quickly notice that the error seems to occur for the user `Charlie` and not for user `Alice`. Perhaps the user Charlie has exceeded some quotas, does not have permissions or we have a bug in parsing names that include the letter `h`? We don't know _yet_, but thanks to tracing we can much quicker begin our investigation. - -**Passing context to client libraries**: When using client libraries that support distributed tracing, they will accept a `Baggage.LoggingContext` type as their _last_ parameter in many calls. - -When using client libraries that support distributed tracing, they will accept a `Baggage.LoggingContext` type as their _last_ parameter in many calls. Please refer to [Context argument naming/positioning](#context-propagation-by-explicit-loggingcontext-passing) in the [Context propagation](#context-propagation-by-explicit-loggingcontext-passing) section of this readme to learn more about how to properly pass context values around. - -### Instrumenting your code - -Adding a span to synchronous functions can be achieved like this: - -```swift -func handleRequest(_ op: String, context: LoggingContext) -> String { - let tracer = InstrumentationSystem.tracer - let span = tracer.startSpan(operationName: "handleRequest(\(name))", context: context) - defer { span.end() } - - return "done:\(op)" -} -``` - -Throwing can be handled by either recording errors manually into a span by calling `span.recordError(error:)`, or by wrapping a potentially throwing operation using the `withSpan(operation:context:body:)` function, which automatically records any thrown error and ends the span at the end of the body closure scope: - -```swift -func handleRequest(_ op: String, context: LoggingContext) -> String { - return try InstrumentationSystem.tracer - .withSpan(operationName: "handleRequest(\(name))", context: context) { - return try dangerousOperation() - } -} -``` - -If this function were asynchronous, and returning a [Swift NIO](https://github.com/apple/swift-nio) `EventLoopFuture`, -we need to end the span when the future completes. We can do so in its `onComplete`: - -```swift -func handleRequest(_ op: String, context: LoggingContext) -> EventLoopFuture { - let tracer = InstrumentationSystem.tracer - let span = tracer.startSpan(operationName: "handleRequest(\(name))", context: context) - - let future: EventLoopFuture = someOperation(op) - future.whenComplete { _ in - span.end() // oh no, ignored errors! - } - - return future -} -``` - -This is better, however we ignored the possibility that the future perhaps has failed. If this happens, we would like to report the span as _errored_ because then it will show up as such in tracing backends and we can then easily search for failed operations etc. - -To do this within the future we could manually invoke the `span.recordError` API before ending the span like this: - -```swift -func handleRequest(_ op: String, context: LoggingContext) -> EventLoopFuture { - let tracer = InstrumentationSystem.tracer - let span = tracer.startSpan(operationName: "handleRequest(\(name))", context: context) - - let future: EventLoopFuture = someOperation(op) - future.whenComplete { result in - switch result { - case .failure(let error): span.recordError(error) - case .success(let value): // ... record additional *attributes* into the span - } - span.end() - } - - return future -} -``` - -While this is verbose, this is only the low-level building blocks that this library provides, higher level helper utilities can be - -> Eventually convenience wrappers will be provided, automatically wrapping future types etc. We welcome such contributions, but likely they should live in `swift-distributed-tracing-extras`. - -Once a system, or multiple systems have been instrumented, a Tracer has been selected and your application runs and emits some trace information, you will be able to inspect how your application is behaving by looking at one of the various trace UIs, such as e.g. Zipkin: - -![Simple example trace in Zipkin Web UI](Sources/Tracing/Docs.docc/Resources/zipkin_trace.png) - -### More examples - -It sometimes is easier to grasp the usage of tracing by looking at a "real" application - which is why we have implemented an example application, spanning multiple nodes and using various databases - tracing through all of them. You can view the example application here: [slashmo/swift-tracing-examples](https://github.com/slashmo/swift-tracing-examples/tree/main/hotrod). - -### Future work: Tracing asynchronous functions - -> ⚠️ This section refers to in-development upcoming Swift Concurrency features and can be tried out using nightly snapshots of the Swift toolchain. - -With Swift's ongoing work towards asynchronous functions, actors, and tasks, tracing in Swift will become more pleasant than it is today. - -Firstly, a lot of the callback heavy code will be folded into normal control flow, which is easy and correct to integrate with tracing like this: - -```swift -func perform(context: LoggingContext) async -> String { - let span = InstrumentationSystem.tracer.startSpan(operationName: #function, context: context) - defer { span.end() } - - return await someWork() -} -``` - - -## In-Depth Guide - -When instrumenting server applications there are typically three parties involved: - -1. [Application developers](#application-developers-setting-up-instruments) creating server-side applications -2. [Library/Framework developers](#libraryframework-developers-instrumenting-your-software) providing building blocks to create these applications -3. [Instrument developers](#instrument-developers-creating-an-instrument) providing tools to collect distributed metadata about your application - -For applications to be instrumented correctly these three parts have to play along nicely. - -## Application Developers - -### Setting up instruments & tracers - -As an end-user building server applications you get to choose what instruments to use to instrument your system. Here's -all the steps you need to take to get up and running: - -Add a package dependency for this repository in your `Package.swift` file, and one for the specific instrument you want -to use, in this case `FancyInstrument`: - -```swift -.package(url: "https://github.com/apple/swift-distributed-tracing.git", .branch("main")), -.package(url: "", from: "<4.2.0>"), -``` - -To your main target, add a dependency on the `Instrumentation library` and the instrument you want to use: - -```swift -.target( - name: "MyApplication", - dependencies: [ - "FancyInstrument" - ] -), -``` - -### Bootstrapping the `InstrumentationSystem` - -Instead of providing each instrumented library with a specific instrument explicitly, you *bootstrap* the -`InstrumentationSystem` which acts as a singleton that libraries/frameworks access when calling out to the configured -`Instrument`: - -```swift -InstrumentationSystem.bootstrap(FancyInstrument()) -``` - -#### Recommended bootstrap order - -Swift offers developers a suite of observability libraries: logging, metrics and tracing. Each of those systems offers a `bootstrap` function. It is useful to stick to a recommended boot order in order to achieve predictable initialization of applications and sub-systems. - -Specifically, it is recommended to bootstrap systems in the following order: - -1. [Swift Log](https://github.com/apple/swift-log#default-logger-behavior)'s `LoggingSystem` -2. [Swift Metrics](https://github.com/apple/swift-metrics#selecting-a-metrics-backend-implementation-applications-only)' `MetricsSystem` -3. Swift Tracing's `InstrumentationSystem` -4. Finally, any other parts of your application - -This is because tracing systems may attempt to emit metrics about their status etc. - -#### Bootstrapping multiple instruments using MultiplexInstrument - -It is important to note that `InstrumentationSystem.bootstrap(_: Instrument)` must only be called once. In case you -want to bootstrap the system to use multiple instruments, you group them in a `MultiplexInstrument` first, which you -then pass along to the `bootstrap` method like this: - -```swift -InstrumentationSystem.bootstrap(MultiplexInstrument([FancyInstrument(), OtherFancyInstrument()])) -``` - -`MultiplexInstrument` will then call out to each instrument it has been initialized with. - - - -### Context propagation, by explicit `LoggingContext` passing - -> `LoggingContext` naming has been carefully selected and it reflects the type's purpose and utility: It binds a [Swift Log `Logger`](https://github.com/apple/swift-log) with an associated distributed tracing [Baggage](https://github.com/apple/swift-distributed-tracing-baggage). -> -> It _also_ is used for tracing, by tracers reaching in to read or modify the carried baggage. - -For instrumentation and tracing to work, certain pieces of metadata (usually in the form of identifiers), must be -carried throughout the entire system–including across process and service boundaries. Because of that, it's essential -for a context object to be passed around your application and the libraries/frameworks you depend on, but also carried -over asynchronous boundaries like an HTTP call to another service of your app. - -`LoggingContext` should always be passed around explicitly. - -Libraries which support tracing are expected to accept a `LoggingContext` parameter, which can be passed through the entire application. Make sure to always pass along the context that's previously handed to you. E.g., when making an HTTP request using `AsyncHTTPClient` in a `NIO` handler, you can use the `ChannelHandlerContext`s `baggage` property to access the `LoggingContext`. - -#### Context argument naming/positioning - -> 💡 This general style recommendation has been ironed out together with the Swift standard library, core team, the SSWG as well as members of the community. Please respect these recommendations when designing APIs such that all APIs are able to "feel the same" yielding a great user experience for our end users ❤️ -> -> It is possible that the ongoing Swift Concurrency efforts, and "Task Local" values will resolve this explicit context passing problem, however until these arrive in the language, please adopt the "context is the last parameter" style as outlined here. - -Propagating baggage context through your system is to be done explicitly, meaning as a parameter in function calls, following the "flow" of execution. - -When passing baggage context explicitly we strongly suggest sticking to the following style guideline: - -- Assuming the general parameter ordering of Swift function is as follows (except DSL exceptions): - 1. Required non-function parameters (e.g. `(url: String)`), - 2. Defaulted non-function parameters (e.g. `(mode: Mode = .default)`), - 3. Required function parameters, including required trailing closures (e.g. `(onNext elementHandler: (Value) -> ())`), - 4. Defaulted function parameters, including optional trailing closures (e.g. `(onComplete completionHandler: (Reason) -> ()) = { _ in }`). -- Logging Context should be passed as **the last parameter in the required non-function parameters group in a function declaration**. - -This way when reading the call side, users of these APIs can learn to "ignore" or "skim over" the context parameter and the method signature remains human-readable and “Swifty”. - -Examples: - -- `func request(_ url: URL,` **`context: LoggingContext`** `)`, which may be called as `httpClient.request(url, context: context)` -- `func handle(_ request: RequestObject,` **`context: LoggingContext`** `)` - - if a "framework context" exists and _carries_ the baggage context already, it is permitted to pass that context - together with the baggage; - - it is _strongly recommended_ to store the baggage context as `baggage` property of `FrameworkContext`, and conform `FrameworkContext` to `LoggingContext` in such cases, in order to avoid the confusing spelling of `context.context`, and favoring the self-explanatory `context.baggage` spelling when the baggage is contained in a framework context object. -- `func receiveMessage(_ message: Message, context: FrameworkContext)` -- `func handle(element: Element,` **`context: LoggingContext`** `, settings: Settings? = nil)` - - before any defaulted non-function parameters -- `func handle(element: Element,` **`context: LoggingContext`** `, settings: Settings? = nil, onComplete: () -> ())` - - before defaulted parameters, which themselfes are before required function parameters -- `func handle(element: Element,` **`context: LoggingContext`** `, onError: (Error) -> (), onComplete: (() -> ())? = nil)` - -In case there are _multiple_ "framework-ish" parameters, such as passing a NIO `EventLoop` or similar, we suggest: - -- `func perform(_ work: Work, for user: User,` _`frameworkThing: Thing, eventLoop: NIO.EventLoop,`_ **`context: LoggingContext`** `)` - - pass the baggage as **last** of such non-domain specific parameters as it will be _by far more_ omnipresent than any - specific framework parameter - as it is expected that any framework should be accepting a context if it can do so. - While not all libraries are necessarily going to be implemented using the same frameworks. - -We feel it is important to preserve Swift's human-readable nature of function definitions. In other words, we intend to -keep the read-out-loud phrasing of methods to remain _"request that URL (ignore reading out loud the context parameter)"_ -rather than _"request (ignore this context parameter when reading) that URL"_. - -#### When to use what context type? - -Generally libraries should favor accepting the general `LoggingContext` type, and **not** attempt to wrap it, as it will result in difficult to compose APIs between multiple libraries. Because end users are likely going to be combining various libraries in a single application, it is important that they can "just pass along" the same context object through all APIs, regardless which other library they are calling into. - -Frameworks may need to be more opinionated here, and e.g. already have some form of "per request context" contextual object which they will conform to `LoggingContext`. _Within_ such framework it is fine and expected to accept and pass the explicit `SomeFrameworkContext`, however when designing APIs which may be called _by_ other libraries, such framework should be able to accept a generic `LoggingContext` rather than its own specific type. - -#### Existing context argument - -When adapting an existing library/framework to support `LoggingContext` and it already has a "framework context" which is expected to be passed through "everywhere", we suggest to follow these guidelines for adopting LoggingContext: - -1. Add a `Baggage` as a property called `baggage` to your own `context` type, so that the call side for your - users becomes `context.baggage` (rather than the confusing `context.context`) -2. If you cannot or it would not make sense to carry baggage inside your framework's context object, pass (and accept (!)) the `LoggingContext` in your framework functions like follows: -- if they take no framework context, accept a `context: LoggingContext` which is the same guideline as for all other cases -- if they already _must_ take a context object and you are out of words (or your API already accepts your framework context as "context"), pass the baggage as **last** parameter (see above) yet call the parameter `baggage` to disambiguate your `context` object from the `baggage` context object. - -Examples: - -- `Lambda.Context` may contain `baggage` and a `logger` and should be able to conform to `LoggingContext` - - passing context to a `Lambda.Context` unaware library becomes: `http.request(url: "...", context: context)`. -- `ChannelHandlerContext` offers a way to set/get baggage on the underlying channel via `context.baggage = ...` - - this context is not passed outside a handler, but within it may be passed as is, and the baggage may be accessed on it directly through it. - - Example: https://github.com/apple/swift-nio/pull/1574 - -### Creating context objects (and when not to do so) - -Generally application developers _should not_ create new context objects, but rather keep passing on a context value that they were given by e.g. the web framework invoking the their code. - -If really necessary, or for the purposes of testing, one can create a baggage or context using one of the two factory functions: - -- [`DefaultLoggingContext.topLevel(logger:)`](https://github.com/apple/swift-distributed-tracing-baggage/blob/main/Sources/Baggage/LoggingContext.swift) or [`Baggage.topLevel`](https://github.com/apple/swift-distributed-tracing-baggage-core/blob/main/Sources/CoreBaggage/Baggage.swift) - which creates an empty context/baggage, without any values. It should _not_ be used too frequently, and as the name implies in applications it only should be used on the "top level" of the application, or at the beginning of a contextless (e.g. timer triggered) event processing. -- [`DefaultLoggingContext.TODO(logger:reason:)`](https://github.com/apple/swift-distributed-tracing-baggage/blob/main/Sources/Baggage/LoggingContext.swift) or [`Baggage.TODO`](https://github.com/apple/swift-distributed-tracing-baggage-core/blob/main/Sources/CoreBaggage/Baggage.swift) - which should be used to mark a parameter where "before this code goes into production, a real context should be passed instead." An application can be run with `-DBAGGAGE_CRASH_TODOS` to cause the application to crash whenever a TODO context is still in use somewhere, making it easy to diagnose and avoid breaking context propagation by accidentally leaving in a `TODO` context in production. - -Please refer to the respective functions documentation for details. - -If using a framework which itself has a "`...Context`" object you may want to inspect it for similar factory functions, as `LoggingContext` is a protocol, that may be conformed to by frameworks to provide a smoother user experience. - - -### Working with `Span`s - -The primary purpose of this API is to start and end so-called `Span` types. - -Spans form hierarchies with their parent spans, and end up being visualized using various tools, usually in a format similar to gant charts. So for example, if we had multiple operations that compose making dinner, they would be modelled as child spans of a main `makeDinner` span. Any sub tasks are again modelled as child spans of any given operation, and so on, resulting in a trace view similar to: - -``` ->-o-o-o----- makeDinner ----------------o---------------x [15s] - \-|-|- chopVegetables--------x | [2s] - | | \- chop -x | | [1s] - | | \--- chop -x | [1s] - \-|- marinateMeat -----------x | [3s] - \- preheatOven -----------------x | [10s] - \--cook---------x [5s] -``` - -The above trace is achieved by starting and ending spans in all the mentioned functions, for example, like this: - -```swift -let tracer: Tracer - -func makeDinner(context: LoggingContext) async throws -> Meal { - tracer.withSpan(operationName: "makeDinner", context) { - let veggiesFuture = try chopVegetables(context: span.context) - let meatFuture = marinateMeat(context: span.context) - let ovenFuture = try preheatOven(temperature: 350, context: span.context) - ... - return cook(veggies, meat, oven) - } -} -``` - -> ❗️ It is tremendously important to **always `end()` a started `Span`**! make sure to end any started span on _every_ code path, including error paths -> -> Failing to do so is an error, and a tracer *may* decide to either crash the application or log warnings when an not-ended span is deinitialized. - - -## Library/Framework developers: Instrumenting your software - -### Extracting & injecting Baggage - -When hitting boundaries like an outgoing HTTP request you call out to the [configured instrument(s)](#Bootstrapping-the-Instrumentation-System): - -An HTTP client e.g. should inject the given `LoggingContext` into the HTTP headers of its outbound request: - -```swift -func get(url: String, context: LoggingContext) { - var request = HTTPRequest(url: url) - InstrumentationSystem.instrument.inject( - context.baggage, - into: &request.headers, - using: HTTPHeadersInjector() - ) -} -``` - -On the receiving side, an HTTP server should use the following `Instrument` API to extract the HTTP headers of the given -`HTTPRequest` into: - -```swift -func handler(request: HTTPRequest, context: LoggingContext) { - InstrumentationSystem.instrument.extract( - request.headers, - into: &context.baggage, - using: HTTPHeadersExtractor() - ) - // ... -} -``` - -> In case your library makes use of the `NIOHTTP1.HTTPHeaders` type we already have an `HTTPHeadersInjector` & -`HTTPHeadersExtractor` available as part of the `NIOInstrumentation` library. - -For your library/framework to be able to carry `LoggingContext` across asynchronous boundaries, it's crucial that you carry the context throughout your entire call chain in order to avoid dropping metadata. - -### Tracing your library - -When your library/framework can benefit from tracing, you should make use of it by integrating the `Tracing` library. - -In order to work with the tracer [configured by the end-user](#Bootstrapping-the-Instrumentation-System), it adds a property to `InstrumentationSystem` that gives you back a `Tracer`. You can then use that tracer to start `Span`s. In an HTTP client you e.g. -should start a `Span` when sending the outgoing HTTP request: - -```swift -func get(url: String, context: LoggingContext) { - var request = HTTPRequest(url: url) - - // inject the request headers into the baggage as explained above - - // start a span for the outgoing request - let tracer = InstrumentationSystem.tracer - var span = tracer.startSpan(named: "HTTP GET", context: context, ofKind: .client) - - // set attributes on the span - span.attributes.http.method = "GET" - // ... - - self.execute(request).always { _ in - // set some more attributes & potentially record an error - - // end the span - span.end() - } -} -``` - -> ⚠️ Make sure to ALWAYS end spans. Ensure that all paths taken by the code will result in ending the span. -> Make sure that error cases also set the error attribute and end the span. - -> In the above example we used the semantic `http.method` attribute that gets exposed via the -`TracingOpenTelemetrySupport` library. - -## Instrument developers: Creating an instrument - -Creating an instrument means adopting the `Instrument` protocol (or `Tracer` in case you develop a tracer). -`Instrument` is part of the `Instrumentation` library & `Tracing` contains the `Tracer` protocol. - -`Instrument` has two requirements: - -1. A method to inject values inside a `LoggingContext` into a generic carrier (e.g. HTTP headers) -2. A method to extract values from a generic carrier (e.g. HTTP headers) and store them in a `LoggingContext` - -The two methods will be called by instrumented libraries/frameworks at asynchronous boundaries, giving you a chance to -act on the provided information or to add additional information to be carried across these boundaries. - -> Check out the [`Baggage` documentation](https://github.com/apple/swift-distributed-tracing-baggage) for more information on -how to retrieve values from the `LoggingContext` and how to set values on it. - -### Creating a `Tracer` - -When creating a tracer you need to create two types: - -1. Your tracer conforming to `Tracer` -2. A span class conforming to `Span` - -> The `Span` conforms to the standard rules defined in [OpenTelemetry](https://github.com/open-telemetry/opentelemetry-specification/blob/v0.7.0/specification/trace/api.md#span), so if unsure about usage patterns, you can refer to this specification and examples referring to it. - -### Defining, injecting and extracting Baggage - -```swift -import Tracing - -private enum TraceIDKey: BaggageKey { - typealias Value = String -} - -extension Baggage { - var traceID: String? { - get { - return self[TraceIDKey.self] - } - set { - self[TraceIDKey.self] = newValue - } - } -} - -var context = DefaultLoggingContext.topLevel(logger: ...) -context.baggage.traceID = "4bf92f3577b34da6a3ce929d0e0e4736" -print(context.baggage.traceID ?? "new trace id") -``` +Documentation is published on the Swift Package Index, available here: https://swiftpackageindex.com/apple/swift-distributed-tracing/main/documentation/tracing ## Contributing diff --git a/Sources/Instrumentation/Instrument.swift b/Sources/Instrumentation/Instrument.swift index 7224b7e..9448a7d 100644 --- a/Sources/Instrumentation/Instrument.swift +++ b/Sources/Instrumentation/Instrument.swift @@ -14,16 +14,52 @@ import InstrumentationBaggage -/// Typealias used to simplify Support of old Swift versions which do not have `Sendable` defined. -#if swift(>=5.6.0) -@preconcurrency public protocol _SwiftInstrumentationSendable: Sendable {} -#else -public protocol _SwiftInstrumentationSendable {} -#endif +// ===== --------------------------------------------------------------------------------------------------------------- +// MARK: Instrument + +/// Convenience for accessing the globally bootstrapped ``InstrumentProtocol``. +/// +/// Equivalent to ``InstrumentationSystem/instrument``. +public enum Instrument { + /// Convenience to access the globally bootstrapped instrument on ``InstrumentationSystem``. + /// + /// Equivalent to ``InstrumentationSystem/instrument``. + public var current: InstrumentProtocol { + InstrumentationSystem.instrument + } +} + +/// Conforming types are usually cross-cutting tools like tracers. They are agnostic of what specific `Carrier` is used +/// to propagate metadata across boundaries, but instead just specify what values to use for which keys. +public protocol InstrumentProtocol: _SwiftInstrumentationSendable { + /// Extract values from a `Carrier` by using the given extractor and inject them into the given `Baggage`. + /// It's quite common for `InstrumentProtocol`s to come up with new values if they weren't passed along in the given `Carrier`. + /// + /// - Parameters: + /// - carrier: The `Carrier` that was used to propagate values across boundaries. + /// - baggage: The `Baggage` into which these values should be injected. + /// - extractor: The ``Extractor`` that extracts values from the given `Carrier`. + func extract(_ carrier: Carrier, into baggage: inout Baggage, using extractor: Extract) + where Extract: Extractor, Extract.Carrier == Carrier + + /// Extract values from a `Baggage` and inject them into the given `Carrier` using the given ``Injector``. + /// + /// - Parameters: + /// - baggage: The `Baggage` from which relevant information will be extracted. + /// - carrier: The `Carrier` into which this information will be injected. + /// - injector: The ``Injector`` used to inject extracted `Baggage` into the given `Carrier`. + func inject(_ baggage: Baggage, into carrier: inout Carrier, using injector: Inject) + where Inject: Injector, Inject.Carrier == Carrier +} + +// ===== --------------------------------------------------------------------------------------------------------------- +// MARK: Instrument /// Conforming types are used to extract values from a specific `Carrier`. public protocol Extractor: _SwiftInstrumentationSendable { /// The carrier to extract values from. + /// + /// For example, this could be an "http request" type. associatedtype Carrier /// Extract the value for the given key from the `Carrier`. @@ -37,6 +73,8 @@ public protocol Extractor: _SwiftInstrumentationSendable { /// Conforming types are used to inject values into a specific `Carrier`. public protocol Injector: _SwiftInstrumentationSendable { /// The carrier to inject values into. + /// + /// For example, this could be an "http request" type. associatedtype Carrier /// Inject the given value for the given key into the given `Carrier`. @@ -48,25 +86,12 @@ public protocol Injector: _SwiftInstrumentationSendable { func inject(_ value: String, forKey key: String, into carrier: inout Carrier) } -/// Conforming types are usually cross-cutting tools like tracers. They are agnostic of what specific `Carrier` is used -/// to propagate metadata across boundaries, but instead just specify what values to use for which keys. -public protocol Instrument: _SwiftInstrumentationSendable { - /// Extract values from a `Carrier` by using the given extractor and inject them into the given `Baggage`. - /// It's quite common for `Instrument`s to come up with new values if they weren't passed along in the given `Carrier`. - /// - /// - Parameters: - /// - carrier: The `Carrier` that was used to propagate values across boundaries. - /// - baggage: The `Baggage` into which these values should be injected. - /// - extractor: The ``Extractor`` that extracts values from the given `Carrier`. - func extract(_ carrier: Carrier, into baggage: inout Baggage, using extractor: Extract) - where Extract: Extractor, Extract.Carrier == Carrier +// ===== --------------------------------------------------------------------------------------------------------------- +// MARK: Sendable support - /// Extract values from a `Baggage` and inject them into the given `Carrier` using the given ``Injector``. - /// - /// - Parameters: - /// - baggage: The `Baggage` from which relevant information will be extracted. - /// - carrier: The `Carrier` into which this information will be injected. - /// - injector: The ``Injector`` used to inject extracted `Baggage` into the given `Carrier`. - func inject(_ baggage: Baggage, into carrier: inout Carrier, using injector: Inject) - where Inject: Injector, Inject.Carrier == Carrier -} +/// Typealias used to simplify Support of old Swift versions which do not have `Sendable` defined. +#if swift(>=5.6.0) +@preconcurrency public protocol _SwiftInstrumentationSendable: Sendable {} +#else +public protocol _SwiftInstrumentationSendable {} +#endif diff --git a/Sources/Instrumentation/InstrumentationSystem.swift b/Sources/Instrumentation/InstrumentationSystem.swift index 9c512a8..f65b3a3 100644 --- a/Sources/Instrumentation/InstrumentationSystem.swift +++ b/Sources/Instrumentation/InstrumentationSystem.swift @@ -15,23 +15,23 @@ import InstrumentationBaggage /// `InstrumentationSystem` is a global facility where the default cross-cutting tool can be configured. -/// It is set up just once in a given program to select the desired ``Instrument`` implementation. +/// It is set up just once in a given program to select the desired ``InstrumentProtocol`` implementation. /// /// # Bootstrap multiple Instruments /// If you need to use more that one cross-cutting tool you can do so by using ``MultiplexInstrument``. /// -/// # Access the Instrument -/// ``instrument``: Returns whatever you passed to ``bootstrap(_:)`` as an ``Instrument``. +/// # Access the InstrumentProtocol +/// ``instrument``: Returns whatever you passed to ``bootstrap(_:)`` as an ``InstrumentProtocol``. public enum InstrumentationSystem { private static let lock = ReadWriteLock() - private static var _instrument: Instrument = NoOpInstrument() + private static var _instrument: InstrumentProtocol = NoOpInstrument() private static var isInitialized = false - /// Globally select the desired ``Instrument`` implementation. + /// Globally select the desired ``InstrumentProtocol`` implementation. /// - /// - Parameter instrument: The ``Instrument`` you want to share globally within your system. + /// - Parameter instrument: The ``InstrumentProtocol`` you want to share globally within your system. /// - Warning: Do not call this method more than once. This will lead to a crash. - public static func bootstrap(_ instrument: Instrument) { + public static func bootstrap(_ instrument: InstrumentProtocol) { self.lock.withWriterLock { precondition( !self.isInitialized, """ @@ -47,23 +47,23 @@ public enum InstrumentationSystem { /// For testing scenarios one may want to set instruments multiple times, rather than the set-once semantics enforced by ``bootstrap(_:)``. /// /// - Parameter instrument: the instrument to boostrap the system with, if `nil` the ``NoOpInstrument`` is bootstrapped. - internal static func bootstrapInternal(_ instrument: Instrument?) { + internal static func bootstrapInternal(_ instrument: InstrumentProtocol?) { self.lock.withWriterLock { self._instrument = instrument ?? NoOpInstrument() } } - /// Returns the globally configured ``Instrument``. + /// Returns the globally configured ``InstrumentProtocol``. /// - /// Defaults to a no-op ``Instrument`` if ``bootstrap(_:)`` wasn't called before. - public static var instrument: Instrument { + /// Defaults to a no-op ``InstrumentProtocol`` if ``bootstrap(_:)`` wasn't called before. + public static var instrument: InstrumentProtocol { self.lock.withReaderLock { self._instrument } } } extension InstrumentationSystem { /// :nodoc: INTERNAL API: Do Not Use - public static func _findInstrument(where predicate: (Instrument) -> Bool) -> Instrument? { + public static func _findInstrument(where predicate: (InstrumentProtocol) -> Bool) -> InstrumentProtocol? { self.lock.withReaderLock { if let multiplex = self._instrument as? MultiplexInstrument { return multiplex.firstInstrument(where: predicate) diff --git a/Sources/Instrumentation/MultiplexInstrument.swift b/Sources/Instrumentation/MultiplexInstrument.swift index 6679357..fd96c19 100644 --- a/Sources/Instrumentation/MultiplexInstrument.swift +++ b/Sources/Instrumentation/MultiplexInstrument.swift @@ -14,27 +14,27 @@ import InstrumentationBaggage -/// A pseudo-``Instrument`` that may be used to instrument using multiple other ``Instrument``s across a +/// A pseudo-``InstrumentProtocol`` that may be used to instrument using multiple other ``InstrumentProtocol``s across a /// common `Baggage`. public struct MultiplexInstrument { - private var instruments: [Instrument] + private var instruments: [InstrumentProtocol] /// Create a ``MultiplexInstrument``. /// - /// - Parameter instruments: An array of ``Instrument``s, each of which will be used to ``Instrument/inject(_:into:using:)`` or ``Instrument/extract(_:into:using:)`` + /// - Parameter instruments: An array of ``InstrumentProtocol``s, each of which will be used to ``InstrumentProtocol/inject(_:into:using:)`` or ``InstrumentProtocol/extract(_:into:using:)`` /// through the same `Baggage`. - public init(_ instruments: [Instrument]) { + public init(_ instruments: [InstrumentProtocol]) { self.instruments = instruments } } extension MultiplexInstrument { - func firstInstrument(where predicate: (Instrument) -> Bool) -> Instrument? { + func firstInstrument(where predicate: (InstrumentProtocol) -> Bool) -> InstrumentProtocol? { self.instruments.first(where: predicate) } } -extension MultiplexInstrument: Instrument { +extension MultiplexInstrument: InstrumentProtocol { public func inject(_ baggage: Baggage, into carrier: inout Carrier, using injector: Inject) where Inject: Injector, Carrier == Inject.Carrier { diff --git a/Sources/Instrumentation/NoOpInstrument.swift b/Sources/Instrumentation/NoOpInstrument.swift index 437b31b..040da89 100644 --- a/Sources/Instrumentation/NoOpInstrument.swift +++ b/Sources/Instrumentation/NoOpInstrument.swift @@ -14,8 +14,8 @@ import InstrumentationBaggage -/// A "no op" implementation of an ``Instrument``. -public struct NoOpInstrument: Instrument { +/// A "no op" implementation of an ``InstrumentProtocol``. +public struct NoOpInstrument: InstrumentProtocol { public init() {} public func inject(_ baggage: Baggage, into carrier: inout Carrier, using injector: Inject) diff --git a/Sources/Tracing/Docs.docc/InDepthGuide.md b/Sources/Tracing/Docs.docc/InDepthGuide.md index 052f9f2..13e21fc 100644 --- a/Sources/Tracing/Docs.docc/InDepthGuide.md +++ b/Sources/Tracing/Docs.docc/InDepthGuide.md @@ -8,7 +8,7 @@ When instrumenting server applications there are typically three parties involve 1. **Application developers** create server-side applications 2. **Library/Framework developers** provide building blocks to create these applications -3. **Instrument developers** provide tools to collect distributed metadata about your application +3. **InstrumentProtocol developers** provide tools to collect distributed metadata about your application For applications to be instrumented correctly these three parts have to play along nicely. @@ -42,7 +42,7 @@ To your main target, add a dependency on the `Instrumentation library` and the i Instead of providing each instrumented library with a specific instrument explicitly, you *bootstrap* the `InstrumentationSystem` which acts as a singleton that libraries/frameworks access when calling out to the configured -`Instrument`: +`InstrumentProtocol`: ```swift InstrumentationSystem.bootstrap(FancyInstrument()) @@ -63,7 +63,7 @@ This is because tracing systems may attempt to emit metrics about their status e #### Bootstrapping multiple instruments using MultiplexInstrument -It is important to note that `InstrumentationSystem.bootstrap(_: Instrument)` must only be called once. In case you +It is important to note that `InstrumentationSystem.bootstrap(_: InstrumentProtocol)` must only be called once. In case you want to bootstrap the system to use multiple instruments, you group them in a `MultiplexInstrument` first, which you then pass along to the `bootstrap` method like this: @@ -188,7 +188,7 @@ Spans form hierarchies with their parent spans, and end up being visualized usin The above trace is achieved by starting and ending spans in all the mentioned functions, for example, like this: ```swift -let tracer: Tracer +let tracer: TracerProtocol func makeDinner(context: LoggingContext) async throws -> Meal { tracer.withSpan(operationName: "makeDinner", context) { @@ -225,7 +225,7 @@ func get(url: String, context: LoggingContext) { } ``` -On the receiving side, an HTTP server should use the following `Instrument` API to extract the HTTP headers of the given +On the receiving side, an HTTP server should use the following `InstrumentProtocol` API to extract the HTTP headers of the given `HTTPRequest` into: ```swift @@ -248,7 +248,7 @@ For your library/framework to be able to carry `LoggingContext` across asynchron When your library/framework can benefit from tracing, you should make use of it by integrating the `Tracing` library. -In order to work with the tracer configured by the end-user (see ), it adds a property to `InstrumentationSystem` that gives you back a ``Tracer``. You can then use that tracer to start ``Span``s. In an HTTP client you e.g. +In order to work with the tracer configured by the end-user (see ), it adds a property to `InstrumentationSystem` that gives you back a ``TracerProtocol``. You can then use that tracer to start ``Span``s. In an HTTP client you e.g. should start a ``Span`` when sending the outgoing HTTP request: ```swift @@ -280,12 +280,12 @@ func get(url: String, context: LoggingContext) { > In the above example we used the semantic `http.method` attribute that gets exposed via the `TracingOpenTelemetrySupport` library. -## Instrument developers: Creating an instrument +## InstrumentProtocol developers: Creating an instrument -Creating an instrument means adopting the `Instrument` protocol (or ``Tracer`` in case you develop a tracer). -`Instrument` is part of the `Instrumentation` library & `Tracing` contains the ``Tracer`` protocol. +Creating an instrument means adopting the `InstrumentProtocol` protocol (or ``TracerProtocol`` in case you develop a tracer). +`InstrumentProtocol` is part of the `Instrumentation` library & `Tracing` contains the ``TracerProtocol`` protocol. -`Instrument` has two requirements: +`InstrumentProtocol` has two requirements: 1. A method to inject values inside a `LoggingContext` into a generic carrier (e.g. HTTP headers) 2. A method to extract values from a generic carrier (e.g. HTTP headers) and store them in a `LoggingContext` @@ -296,11 +296,11 @@ act on the provided information or to add additional information to be carried a > Check out the [`Baggage` documentation](https://github.com/apple/swift-distributed-tracing-baggage) for more information on how to retrieve values from the `LoggingContext` and how to set values on it. -### Creating a `Tracer` +### Creating a `TracerProtocol` When creating a tracer you need to create two types: -1. Your tracer conforming to ``Tracer`` +1. Your tracer conforming to ``TracerProtocol`` 2. A span class conforming to ``Span`` > ``Span`` conforms to the standard rules defined in [OpenTelemetry](https://github.com/open-telemetry/opentelemetry-specification/blob/v0.7.0/specification/trace/api.md#span), so if unsure about usage patterns, you can refer to this specification and examples referring to it. diff --git a/Sources/Tracing/Docs.docc/index.md b/Sources/Tracing/Docs.docc/index.md index f541c06..1c8b295 100644 --- a/Sources/Tracing/Docs.docc/index.md +++ b/Sources/Tracing/Docs.docc/index.md @@ -11,7 +11,7 @@ While Swift Distributed Tracing allows building all kinds of _instruments_, whic --- -This project uses the context progagation type defined independently in: +This project uses the context propagation type defined independently in: - 🧳 [swift-distributed-tracing-baggage](https://github.com/apple/swift-distributed-tracing-baggage) -- [`Baggage`](https://apple.github.io/swift-distributed-tracing-baggage/docs/current/InstrumentationBaggage/Structs/Baggage.html) (zero dependencies) @@ -23,7 +23,7 @@ The purpose of the tracing package is to serve as common API for all tracer and ### Tracing Backends -Compatible `Tracer` implementations: +Compatible implementations: | Library | Status | Description | | ------- | ------ | ----------- | @@ -62,14 +62,21 @@ To your main target, add a dependency on the `Tracing` library and the instrumen ), ``` -Then (in an application, libraries should _never_ invoke `bootstrap`), you will want to bootstrap the specific tracer you want to use in your application. A ``Tracer`` is a type of `Instrument` and can be offered used to globally bootstrap the tracing system, like this: +Then (in an application, libraries should _never_ invoke `bootstrap`), you will want to bootstrap the specific tracer you want to use in your application. A ``TracerProtocol`` is a type of `InstrumentProtocol` and can be offered used to globally bootstrap the tracing system, like this: ```swift import Tracing // the tracing API +import Logging // the logging API import AwesomeTracing // the specific tracer -InstrumentationSystem.bootstrap(AwesomeTracing()) +let awesome = AwesomeTracing() + +// bootstrap "awesome tracing" globally: +InstrumentationSystem.bootstrap(awesome) + +// also configure a metadata provider for swift-log +LoggingSystem.bootstrap(myHandler, metadataProvider: awesome.metadataProvider) ``` If you don't bootstrap (or other instrument) the default no-op tracer is used, which will result in no trace data being collected. @@ -78,12 +85,17 @@ If you don't bootstrap (or other instrument) the default no-op tracer is used, **Automatically reported spans**: When using an already instrumented library, e.g. an HTTP Server which automatically emits spans internally, this is all you have to do to enable tracing. It should now automatically record and emit spans using your configured backend. -**Using baggage and logging context**: The primary transport type for tracing metadata is called `Baggage`, and the primary type used to pass around baggage context and loggers is `LoggingContext`. Logging context combines baggage context values with a smart `Logger` that automatically includes any baggage values ("trace metadata") when it is used for logging. For example, when using an instrumented HTTP server, the API could look like this: +**Using baggage and logging context**: The primary transport type for tracing metadata is called `Baggage` and it is propagated transparently using Swift Concurrency's [task-local values](https://developer.apple.com/documentation/swift/tasklocal). For example, when using an instrumented HTTP server, the API could look like this: ```swift -SomeHTTPLibrary.handle { (request, context) in - context.logger.info("Wow, tracing!") // automatically includes tracing metadata such as "trace-id" - return try doSomething(request context: context) +let log = Logger(label: "testing") + +SomeHTTPLibrary.handle { request in + // Since we configured logging with the metadata provider from "awesome tracing", + // we can just directly log messages, and the metadata provider will inject any + // available tracing metadata (e.g. an example-trace-id). + log.info("Wow, tracing!") + return try doSomething() } ``` @@ -100,30 +112,13 @@ In this snippet, we use the context logger to log a very useful message. However Thanks to tracing, and trace identifiers, even if not using tracing visualization libraries, we can immediately co-relate log statements and know that the request `1111-23-1234556` has failed. Since our application can also _add_ values to the context, we can quickly notice that the error seems to occur for the user `Charlie` and not for user `Alice`. Perhaps the user Charlie has exceeded some quotas, does not have permissions or we have a bug in parsing names that include the letter `h`? We don't know _yet_, but thanks to tracing we can much quicker begin our investigation. -**Passing context to client libraries**: When using client libraries that support distributed tracing, they will accept a `Baggage.LoggingContext` type as their _last_ parameter in many calls. - -When using client libraries that support distributed tracing, they will accept a `Baggage.LoggingContext` type as their _last_ parameter in many calls. Please refer to the section of the to learn more about how to properly pass context values around. - ### Instrumenting your code Adding a span to synchronous functions can be achieved like this: ```swift -func handleRequest(_ op: String, context: LoggingContext) -> String { - let tracer = InstrumentationSystem.tracer - let span = tracer.startSpan(operationName: "handleRequest(\(name))", context: context) - defer { span.end() } - - return "done:\(op)" -} -``` - -Throwing can be handled by either recording errors manually into a span by calling ``Span/recordError(_:)``, or by wrapping a potentially throwing operation using the `withSpan(operation:context:body:)` function, which automatically records any thrown error and ends the span at the end of the body closure scope: - -```swift -func handleRequest(_ op: String, context: LoggingContext) -> String { - return try InstrumentationSystem.tracer - .withSpan(operationName: "handleRequest(\(name))", context: context) { +func handleRequest(_ op: String) async -> String { + try Tracer.current.withSpan(operationName: "handleRequest(\(op))") { return try dangerousOperation() } } @@ -133,9 +128,9 @@ If this function were asynchronous, and returning a [Swift NIO](https://github.c we need to end the span when the future completes. We can do so in its `onComplete`: ```swift -func handleRequest(_ op: String, context: LoggingContext) -> EventLoopFuture { - let tracer = InstrumentationSystem.tracer - let span = tracer.startSpan(operationName: "handleRequest(\(name))", context: context) +func handleRequest(_ op: String) async -> String { + let tracer = Tracer.current + let span = tracer.startSpan(operationName: "handleRequest(\(op))") let future: EventLoopFuture = someOperation(op) future.whenComplete { _ in @@ -151,9 +146,9 @@ This is better, however we ignored the possibility that the future perhaps has f To do this within the future we could manually invoke the ``Span/recordError(_:)`` API before ending the span like this: ```swift -func handleRequest(_ op: String, context: LoggingContext) -> EventLoopFuture { - let tracer = InstrumentationSystem.tracer - let span = tracer.startSpan(operationName: "handleRequest(\(name))", context: context) +func handleRequest(_ op: String) -> EventLoopFuture { + let tracer = Tracer.current + let span = tracer.startSpan(operationName: "handleRequest(\(name))") let future: EventLoopFuture = someOperation(op) future.whenComplete { result in @@ -172,31 +167,10 @@ While this is verbose, this is only the low-level building blocks that this libr > Eventually convenience wrappers will be provided, automatically wrapping future types etc. We welcome such contributions, but likely they should live in `swift-distributed-tracing-extras`. -Once a system, or multiple systems have been instrumented, a ``Tracer`` has been selected and your application runs and emits some trace information, you will be able to inspect how your application is behaving by looking at one of the various trace UIs, such as e.g. Zipkin: +Once a system, or multiple systems have been instrumented, a ``TracerProtocol`` has been selected and your application runs and emits some trace information, you will be able to inspect how your application is behaving by looking at one of the various trace UIs, such as e.g. Zipkin: ![Simple example trace in Zipkin Web UI](zipkin_trace.png) -### More examples - -It sometimes is easier to grasp the usage of tracing by looking at a "real" application - which is why we have implemented an example application, spanning multiple nodes and using various databases - tracing through all of them. You can view the example application here: [slashmo/swift-tracing-examples](https://github.com/slashmo/swift-tracing-examples/tree/main/hotrod). - -### Future work: Tracing asynchronous functions - -> ⚠️ This section refers to in-development upcoming Swift Concurrency features and can be tried out using nightly snapshots of the Swift toolchain. - -With Swift's ongoing work towards asynchronous functions, actors, and tasks, tracing in Swift will become more pleasant than it is today. - -Firstly, a lot of the callback heavy code will be folded into normal control flow, which is easy and correct to integrate with tracing like this: - -```swift -func perform(context: LoggingContext) async -> String { - let span = InstrumentationSystem.tracer.startSpan(operationName: #function, context: context) - defer { span.end() } - - return await someWork() -} -``` - ## Topics ### Articles diff --git a/Sources/Tracing/InstrumentationSystem+Tracing.swift b/Sources/Tracing/InstrumentationSystem+Tracing.swift index 1be4949..1083a7f 100644 --- a/Sources/Tracing/InstrumentationSystem+Tracing.swift +++ b/Sources/Tracing/InstrumentationSystem+Tracing.swift @@ -15,13 +15,19 @@ @_exported import Instrumentation extension InstrumentationSystem { - /// Returns the ``Tracer`` bootstrapped as part of the `InstrumentationSystem`. + /// Returns the ``TracerProtocol`` bootstrapped as part of the `InstrumentationSystem`. /// /// If the system was bootstrapped with a `MultiplexInstrument` this function attempts to locate the _first_ /// tracing instrument as passed to the multiplex instrument. If none is found, a ``NoOpTracer`` is returned. /// - /// - Returns: A ``Tracer`` if the system was bootstrapped with one, and ``NoOpTracer`` otherwise. - public static var tracer: Tracer { - (self._findInstrument(where: { $0 is Tracer }) as? Tracer) ?? NoOpTracer() + /// - Returns: A ``TracerProtocol`` if the system was bootstrapped with one, and ``NoOpTracer`` otherwise. + #if swift(>=5.6.0) // because we must use `any Existential` to avoid warnings + public static var tracer: any TracerProtocol { + (self._findInstrument(where: { $0 is any TracerProtocol }) as? any TracerProtocol) ?? NoOpTracer() } + #else + public static var tracer: any TracerProtocol { + (self._findInstrument(where: { $0 is TracerProtocol }) as? TracerProtocol) ?? NoOpTracer() + } + #endif } diff --git a/Sources/Tracing/NoOpTracer.swift b/Sources/Tracing/NoOpTracer.swift index 97bfc35..347548c 100644 --- a/Sources/Tracing/NoOpTracer.swift +++ b/Sources/Tracing/NoOpTracer.swift @@ -16,8 +16,8 @@ import Dispatch @_exported import Instrumentation @_exported import InstrumentationBaggage -/// No operation ``Tracer``, used when no tracing is required. -public struct NoOpTracer: Tracer { +/// No operation ``TracerProtocol``, used when no tracing is required. +public struct NoOpTracer: TracerProtocol { public init() {} public func startSpan( @@ -28,7 +28,7 @@ public struct NoOpTracer: Tracer { function: String, file fileID: String, line: UInt - ) -> Span { + ) -> NoOpSpan { NoOpSpan(baggage: baggage) } @@ -46,7 +46,7 @@ public struct NoOpTracer: Tracer { // no-op } - public final class NoOpSpan: Span { + public final class NoOpSpan: SpanProtocol { public let baggage: Baggage public let isRecording = false diff --git a/Sources/Tracing/Span.swift b/Sources/Tracing/SpanProtocol.swift similarity index 98% rename from Sources/Tracing/Span.swift rename to Sources/Tracing/SpanProtocol.swift index ad15b2c..7298fcf 100644 --- a/Sources/Tracing/Span.swift +++ b/Sources/Tracing/SpanProtocol.swift @@ -23,10 +23,10 @@ import struct Dispatch.DispatchWallTime /// with it. A `Span` can be created from a `Baggage` or `LoggingContext` which MAY contain existing span identifiers, /// in which case this span should be considered as "child" of the previous span. /// -/// Creating a `Span` is delegated to a ``Tracer`` and end users should never create them directly. +/// Creating a `Span` is delegated to a ``TracerProtocol`` and end users should never create them directly. /// /// - SeeAlso: For more details refer to the [OpenTelemetry Specification: Span](https://github.com/open-telemetry/opentelemetry-specification/blob/v0.7.0/specification/trace/api.md#span) which this type is compatible with. -public protocol Span: AnyObject, _SwiftTracingSendableSpan { +public protocol SpanProtocol: AnyObject, _SwiftTracingSendableSpan { /// The read-only `Baggage` of this `Span`, set when starting this `Span`. var baggage: Baggage { get } @@ -70,7 +70,7 @@ public protocol Span: AnyObject, _SwiftTracingSendableSpan { func end(at time: DispatchWallTime) } -extension Span { +extension SpanProtocol { /// End this `Span` at the current time. /// /// ### Rules about ending Spans @@ -92,7 +92,7 @@ extension Span { /// Adds a ``SpanLink`` between this `Span` and the given `Span`. /// - Parameter other: The `Span` to link to. /// - Parameter attributes: The ``SpanAttributes`` describing this link. Defaults to no attributes. - public func addLink(_ other: Span, attributes: SpanAttributes = [:]) { + public func addLink(_ other: SpanProtocol, attributes: SpanAttributes = [:]) { self.addLink(SpanLink(baggage: other.baggage, attributes: attributes)) } } diff --git a/Sources/Tracing/Tracer.swift b/Sources/Tracing/Tracer.swift index e0b7eb2..671dabe 100644 --- a/Sources/Tracing/Tracer.swift +++ b/Sources/Tracing/Tracer.swift @@ -16,9 +16,27 @@ import Dispatch @_exported import Instrumentation @_exported import InstrumentationBaggage -/// An `Instrument` with added functionality for distributed tracing. It uses the span-based tracing model and is +// ==== ---------------------------------------------------------------------------------------------------------------- +// MARK: Tracer + +/// Convenience for accessing the globally bootstrapped ``TracerProtocol``. +/// +/// Equivalent to ``InstrumentationSystem/tracer``. +public enum Tracer { + /// Convenience to access the globally bootstrapped tracer on ``InstrumentationSystem``. + /// + /// Equivalent to ``InstrumentationSystem/tracer``. + public var current: any TracerProtocol { + InstrumentationSystem.tracer + } +} + +/// An `InstrumentProtocol` with added functionality for distributed tracing. It uses the span-based tracing model and is /// based on the OpenTracing/OpenTelemetry spec. -public protocol Tracer: Instrument { +public protocol TracerProtocol: InstrumentProtocol { + /// The type of `Span` that this tracer can create. + associatedtype Span: SpanProtocol + /// Start a new ``Span`` with the given `Baggage` at a given time. /// /// - Note: Prefer to use `withSpan` to start a span as it automatically takes care of ending the span, @@ -52,7 +70,7 @@ public protocol Tracer: Instrument { func forceFlush() } -extension Tracer { +extension TracerProtocol { #if swift(>=5.3.0) /// Start a new ``Span`` with the given `Baggage` starting "now". /// @@ -115,7 +133,7 @@ extension Tracer { // ==== ---------------------------------------------------------------------------------------------------------------- // MARK: Starting spans: `withSpan` -extension Tracer { +extension TracerProtocol { #if swift(>=5.3.0) /// Execute a specific task within a newly created ``Span``. /// @@ -206,7 +224,7 @@ extension Tracer { #if swift(>=5.5) && canImport(_Concurrency) @available(macOS 10.15, iOS 13.0, tvOS 13.0, watchOS 6.0, *) -extension Tracer { +extension TracerProtocol { /// Execute the given operation within a newly created ``Span``, /// started as a child of the currently stored task local `Baggage.current` or as a root span if `nil`. /// @@ -263,7 +281,7 @@ extension Tracer { function: String = #function, file fileID: String = #fileID, line: UInt = #line, - _ operation: (Span) async throws -> T + _ operation: (SpanProtocol) async throws -> T ) async rethrows -> T { let span = self.startSpan( operationName, @@ -307,7 +325,7 @@ extension Tracer { function: String = #function, file fileID: String = #fileID, line: UInt = #line, - _ operation: (Span) async throws -> T + _ operation: (SpanProtocol) async throws -> T ) async rethrows -> T { let span = self.startSpan(operationName, baggage: baggage, ofKind: kind, function: function, file: fileID, line: line) defer { span.end() } diff --git a/Sources/_TracingBenchmarks/SpanAttributesDSLBenchmark.swift b/Sources/_TracingBenchmarks/SpanAttributesDSLBenchmark.swift index 0a930de..31b191e 100644 --- a/Sources/_TracingBenchmarks/SpanAttributesDSLBenchmark.swift +++ b/Sources/_TracingBenchmarks/SpanAttributesDSLBenchmark.swift @@ -69,7 +69,7 @@ public let SpanAttributesDSLBenchmarks: [BenchmarkInfo] = [ ), ] -private var span: Span! +private var span: SpanProtocol! private func setUp() { span = InstrumentationSystem.tracer.startSpan("something", baggage: .topLevel) diff --git a/Tests/InstrumentationTests/InstrumentTests.swift b/Tests/InstrumentationTests/InstrumentTests.swift index aaea30a..cada7ed 100644 --- a/Tests/InstrumentationTests/InstrumentTests.swift +++ b/Tests/InstrumentationTests/InstrumentTests.swift @@ -52,7 +52,7 @@ private struct DictionaryExtractor: Extractor { } } -private final class FirstFakeTracer: Instrument { +private final class FirstFakeTracer: InstrumentProtocol { enum TraceIDKey: BaggageKey { typealias Value = String @@ -77,7 +77,7 @@ private final class FirstFakeTracer: Instrument { } } -private final class SecondFakeTracer: Instrument { +private final class SecondFakeTracer: InstrumentProtocol { enum TraceIDKey: BaggageKey { typealias Value = String diff --git a/Tests/InstrumentationTests/InstrumentationSystemTests.swift b/Tests/InstrumentationTests/InstrumentationSystemTests.swift index 87a7be5..5f0a2c8 100644 --- a/Tests/InstrumentationTests/InstrumentationSystemTests.swift +++ b/Tests/InstrumentationTests/InstrumentationSystemTests.swift @@ -17,7 +17,7 @@ import InstrumentationBaggage import XCTest extension InstrumentationSystem { - public static func _instrument(of instrumentType: I.Type) -> I? where I: Instrument { + public static func _instrument(of instrumentType: I.Type) -> I? where I: InstrumentProtocol { self._findInstrument(where: { $0 is I }) as? I } } @@ -48,7 +48,7 @@ final class InstrumentationSystemTests: XCTestCase { } } -private final class FakeTracer: Instrument { +private final class FakeTracer: InstrumentProtocol { func inject( _ baggage: Baggage, into carrier: inout Carrier, @@ -68,7 +68,7 @@ private final class FakeTracer: Instrument { Carrier == Extract.Carrier {} } -private final class FakeInstrument: Instrument { +private final class FakeInstrument: InstrumentProtocol { func inject( _ baggage: Baggage, into carrier: inout Carrier, diff --git a/Tests/TracingTests/DynamicTracepointTracerTests.swift b/Tests/TracingTests/DynamicTracepointTracerTests.swift index 0738b8f..f9b41d4 100644 --- a/Tests/TracingTests/DynamicTracepointTracerTests.swift +++ b/Tests/TracingTests/DynamicTracepointTracerTests.swift @@ -105,7 +105,7 @@ final class DynamicTracepointTracerTests: XCTestCase { } /// Only intended to be used in single-threaded testing. -final class DynamicTracepointTestTracer: Tracer { +final class DynamicTracepointTestTracer: TracerProtocol { private(set) var activeTracepoints: Set = [] struct TracepointID: Hashable { @@ -139,7 +139,7 @@ final class DynamicTracepointTestTracer: Tracer { } private(set) var spans: [TracepointSpan] = [] - var onEndSpan: (Span) -> Void = { _ in + var onEndSpan: (SpanProtocol) -> Void = { _ in } func startSpan(_ operationName: String, @@ -148,11 +148,11 @@ final class DynamicTracepointTestTracer: Tracer { at time: DispatchWallTime, function: String, file fileID: String, - line: UInt) -> Tracing.Span + line: UInt) -> TracepointSpan { let tracepoint = TracepointID(function: function, fileID: fileID, line: line) guard self.shouldRecord(tracepoint: tracepoint) else { - return NoOpTracer.NoOpSpan(baggage: baggage) + return TracepointSpan.notRecording(file: fileID, line: line) } let span = TracepointSpan( @@ -229,7 +229,7 @@ final class DynamicTracepointTestTracer: Tracer { extension DynamicTracepointTestTracer { /// Only intended to be used in single-threaded testing. - final class TracepointSpan: Tracing.Span { + final class TracepointSpan: Tracing.SpanProtocol { private let operationName: String private let kind: SpanKind @@ -241,7 +241,21 @@ extension DynamicTracepointTestTracer { private(set) var baggage: Baggage private(set) var isRecording: Bool = false - let onEnd: (Span) -> Void + let onEnd: (TracepointSpan) -> Void + + static func notRecording(file fileID: String, line: UInt) -> TracepointSpan { + let span = TracepointSpan( + operationName: "", + startTime: .now(), + baggage: .topLevel, + kind: .internal, + file: fileID, + line: line, + onEnd: { _ in () } + ) + span.isRecording = false + return span + } init(operationName: String, startTime: DispatchWallTime, @@ -249,7 +263,7 @@ extension DynamicTracepointTestTracer { kind: SpanKind, file fileID: String, line: UInt, - onEnd: @escaping (Span) -> Void) + onEnd: @escaping (TracepointSpan) -> Void) { self.operationName = operationName self.startTime = startTime diff --git a/Tests/TracingTests/TestTracer.swift b/Tests/TracingTests/TestTracer.swift index 397809f..ea28867 100644 --- a/Tests/TracingTests/TestTracer.swift +++ b/Tests/TracingTests/TestTracer.swift @@ -19,9 +19,9 @@ import InstrumentationBaggage import Tracing /// Only intended to be used in single-threaded testing. -final class TestTracer: Tracer { +final class TestTracer: TracerProtocol { private(set) var spans = [TestSpan]() - var onEndSpan: (Span) -> Void = { _ in } + var onEndSpan: (SpanProtocol) -> Void = { _ in } func startSpan( _ operationName: String, @@ -31,7 +31,7 @@ final class TestTracer: Tracer { function: String, file fileID: String, line: UInt - ) -> Span { + ) -> TestSpan { let span = TestSpan( operationName: operationName, startTime: time, @@ -95,7 +95,7 @@ extension Baggage { } /// Only intended to be used in single-threaded testing. -final class TestSpan: Span { +final class TestSpan: SpanProtocol { private let operationName: String private let kind: SpanKind @@ -122,14 +122,14 @@ final class TestSpan: Span { private(set) var isRecording = false - let onEnd: (Span) -> Void + let onEnd: (SpanProtocol) -> Void init( operationName: String, startTime: DispatchWallTime, baggage: Baggage, kind: SpanKind, - onEnd: @escaping (Span) -> Void + onEnd: @escaping (SpanProtocol) -> Void ) { self.operationName = operationName self.startTime = startTime diff --git a/Tests/TracingTests/TracedLock.swift b/Tests/TracingTests/TracedLock.swift index a17003a..fa29ffe 100644 --- a/Tests/TracingTests/TracedLock.swift +++ b/Tests/TracingTests/TracedLock.swift @@ -21,7 +21,7 @@ final class TracedLock { let name: String let underlyingLock: NSLock - var activeSpan: Span? + var activeSpan: SpanProtocol? init(name: String) { self.name = name diff --git a/Tests/TracingTests/TracedLockTests.swift b/Tests/TracingTests/TracedLockTests.swift index e7caee5..b55f19a 100644 --- a/Tests/TracingTests/TracedLockTests.swift +++ b/Tests/TracingTests/TracedLockTests.swift @@ -56,10 +56,10 @@ enum TaskIDKey: BaggageKey { } // ==== ------------------------------------------------------------------------ -// MARK: PrintLn Tracer +// MARK: PrintLn TracerProtocol /// Only intended to be used in single-threaded testing. -private final class TracedLockPrintlnTracer: Tracer { +private final class TracedLockPrintlnTracer: TracerProtocol { func startSpan( _ operationName: String, baggage: Baggage, @@ -68,7 +68,7 @@ private final class TracedLockPrintlnTracer: Tracer { function: String, file fileID: String, line: UInt - ) -> Span { + ) -> TracedLockPrintlnSpan { TracedLockPrintlnSpan( operationName: operationName, startTime: time, @@ -97,7 +97,7 @@ private final class TracedLockPrintlnTracer: Tracer { Extract: Extractor, Carrier == Extract.Carrier {} - final class TracedLockPrintlnSpan: Span { + final class TracedLockPrintlnSpan: SpanProtocol { private let operationName: String private let kind: SpanKind diff --git a/Tests/TracingTests/TracerTests.swift b/Tests/TracingTests/TracerTests.swift index 987f3e7..08ae379 100644 --- a/Tests/TracingTests/TracerTests.swift +++ b/Tests/TracingTests/TracerTests.swift @@ -112,11 +112,11 @@ final class TracerTests: XCTestCase { var spanEnded = false tracer.onEndSpan = { _ in spanEnded = true } - func operation(span: Span) -> String { + func operation(span: SpanProtocol) -> String { "world" } - let value = tracer.withSpan("hello") { (span: Span) -> String in + let value = tracer.withSpan("hello") { (span: SpanProtocol) -> String in XCTAssertEqual(span.baggage.traceID, Baggage.current?.traceID) return operation(span: span) } @@ -141,7 +141,7 @@ final class TracerTests: XCTestCase { var spanEnded = false tracer.onEndSpan = { _ in spanEnded = true } - func operation(span: Span) throws -> String { + func operation(span: SpanProtocol) throws -> String { throw ExampleSpanError() } @@ -171,12 +171,12 @@ final class TracerTests: XCTestCase { var spanEnded = false tracer.onEndSpan = { _ in spanEnded = true } - func operation(span: Span) async throws -> String { + func operation(span: SpanProtocol) async throws -> String { "world" } try self.testAsync { - let value = try await tracer.withSpan("hello") { (span: Span) -> String in + let value = try await tracer.withSpan("hello") { (span: SpanProtocol) -> String in XCTAssertEqual(span.baggage.traceID, Baggage.current?.traceID) return try await operation(span: span) } @@ -202,14 +202,14 @@ final class TracerTests: XCTestCase { var spanEnded = false tracer.onEndSpan = { _ in spanEnded = true } - func operation(span: Span) async -> String { + func operation(span: SpanProtocol) async -> String { "world" } self.testAsync { var fromNonAsyncWorld = Baggage.topLevel fromNonAsyncWorld.traceID = "1234-5678" - let value = await tracer.withSpan("hello", baggage: fromNonAsyncWorld) { (span: Span) -> String in + let value = await tracer.withSpan("hello", baggage: fromNonAsyncWorld) { (span: SpanProtocol) -> String in XCTAssertEqual(span.baggage.traceID, Baggage.current?.traceID) XCTAssertEqual(span.baggage.traceID, fromNonAsyncWorld.traceID) return await operation(span: span) @@ -236,7 +236,7 @@ final class TracerTests: XCTestCase { var spanEnded = false tracer.onEndSpan = { _ in spanEnded = true } - func operation(span: Span) async throws -> String { + func operation(span: SpanProtocol) async throws -> String { throw ExampleSpanError() } diff --git a/Tests/TracingTests/TracingInstrumentationSystemTests.swift b/Tests/TracingTests/TracingInstrumentationSystemTests.swift index 5e68ea5..0c9650a 100644 --- a/Tests/TracingTests/TracingInstrumentationSystemTests.swift +++ b/Tests/TracingTests/TracingInstrumentationSystemTests.swift @@ -17,11 +17,11 @@ import Tracing import XCTest extension InstrumentationSystem { - public static func _tracer(of tracerType: T.Type) -> T? where T: Tracer { + public static func _tracer(of tracerType: T.Type) -> T? where T: TracerProtocol { self._findInstrument(where: { $0 is T }) as? T } - public static func _instrument(of instrumentType: I.Type) -> I? where I: Instrument { + public static func _instrument(of instrumentType: I.Type) -> I? where I: InstrumentProtocol { self._findInstrument(where: { $0 is I }) as? I } }