diff --git a/Docs/README.md b/Docs/README.md new file mode 100644 index 0000000..7ec783e --- /dev/null +++ b/Docs/README.md @@ -0,0 +1,3 @@ +# Documentation landing page + +This documentation target exists only to serve as a landing page for self-hosted documentation. diff --git a/Docs/SwiftDistributedTracing/Docs.docc/index.md b/Docs/SwiftDistributedTracing/Docs.docc/index.md new file mode 100644 index 0000000..b6e4147 --- /dev/null +++ b/Docs/SwiftDistributedTracing/Docs.docc/index.md @@ -0,0 +1,29 @@ +# ``SwiftDistributedTracing`` + +A Distributed Tracing API for Swift. + +## Overview + +This is a collection of Swift libraries enabling the instrumentation of server side applications using tools such as tracers. Our goal is to provide a common foundation that allows to freely choose how to instrument systems with minimal changes to your actual code. + +While Swift Distributed Tracing allows building all kinds of _instruments_, which can co-exist in applications transparently, its primary use is instrumenting multi-threaded and distributed systems with Distributed Traces. + +### Quickstart Guides + +We provide a number of guides aimed at getting your started with tracing your systems and have prepared them from three "angles": + +1. **Application developers** who create server-side applications + * please refer to the guide. +2. **Library/Framework developers** who provide building blocks to create these applications + * please refer to the guide. +3. **Instrument developers** who provide tools to collect distributed metadata about your application + * please refer to the guide. + + +## Topics + +### Guides + +- +- +- diff --git a/Docs/SwiftDistributedTracing/empty.swift b/Docs/SwiftDistributedTracing/empty.swift new file mode 100644 index 0000000..2f2036f --- /dev/null +++ b/Docs/SwiftDistributedTracing/empty.swift @@ -0,0 +1,19 @@ +//===----------------------------------------------------------------------===// +// +// This source file is part of the Swift Distributed Tracing open source project +// +// Copyright (c) 2020-2021 Apple Inc. and the Swift Distributed Tracing project +// authors +// Licensed under Apache License v2.0 +// +// See LICENSE.txt for license information +// +// SPDX-License-Identifier: Apache-2.0 +// +//===----------------------------------------------------------------------===// + +// !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! // +// This module is left purposefully empty of any source files, as it serves +// only as a "landing page" for the documentation. This is in-place until docc +// gains the ability to support package-wide documentation. +// !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! // \ No newline at end of file diff --git a/Samples/Dinner/.gitignore b/Samples/Dinner/.gitignore new file mode 100644 index 0000000..0a4509a --- /dev/null +++ b/Samples/Dinner/.gitignore @@ -0,0 +1,2 @@ +.build +Package.resolved diff --git a/Samples/Dinner/Package.swift b/Samples/Dinner/Package.swift new file mode 100644 index 0000000..3e30e30 --- /dev/null +++ b/Samples/Dinner/Package.swift @@ -0,0 +1,23 @@ +// swift-tools-version:5.3 +import PackageDescription + +let package = Package( + name: "onboarding", + platforms: [ + .macOS("13.0.0"), + ], + products: [ + .executable(name: "onboarding", targets: ["Onboarding"]), + ], + dependencies: [ + // This example uses the following tracer implementation: + .package(url: "https://github.com/slashmo/swift-otel", .branch("main")), + .package(url: "https://github.com/apple/swift-log.git", from: "1.5.0"), + ], + targets: [ + .target(name: "Onboarding", dependencies: [ + .product(name: "OpenTelemetry", package: "swift-otel"), + .product(name: "OtlpGRPCSpanExporting", package: "swift-otel"), + ]), + ] +) diff --git a/Samples/Dinner/README.md b/Samples/Dinner/README.md new file mode 100644 index 0000000..3babef0 --- /dev/null +++ b/Samples/Dinner/README.md @@ -0,0 +1,18 @@ +## Tracing Dinner Sample App + +In order to try this sample app, and visualize traces it produces, you should first run `docker-compose` in order +to launch a docker containers which host a Zipkin UI and collector: + +``` +# cd Samples/Dinner + +docker-compose -f docker/docker-compose.yaml up --build +``` + +and then run the sample app which will produce a number of traces: + +``` +swift run -c release +``` + +Refer to the "Trace Your Application" guide in the documentation to learn more about how to interpret this sample. \ No newline at end of file diff --git a/Samples/Dinner/Sources/Onboarding/Clock+Extensions.swift b/Samples/Dinner/Sources/Onboarding/Clock+Extensions.swift new file mode 100644 index 0000000..55f8620 --- /dev/null +++ b/Samples/Dinner/Sources/Onboarding/Clock+Extensions.swift @@ -0,0 +1,29 @@ +//===----------------------------------------------------------------------===// +// +// This source file is part of the Swift Distributed Tracing open source project +// +// Copyright (c) 2020-2023 Apple Inc. and the Swift Distributed Tracing project +// authors +// Licensed under Apache License v2.0 +// +// See LICENSE.txt for license information +// +// SPDX-License-Identifier: Apache-2.0 +// +//===----------------------------------------------------------------------===// +//===----------------------------------------------------------------------===// +// +// This source file is part of the Swift OpenTelemetry open source project +// +// Copyright (c) 2021 Moritz Lang and the Swift OpenTelemetry project authors +// Licensed under Apache License v2.0 +// +// See LICENSE.txt for license information +// +// SPDX-License-Identifier: Apache-2.0 +// +//===----------------------------------------------------------------------===// + +func sleep(for duration: ContinuousClock.Duration) async { + try? await Task.sleep(until: ContinuousClock.now + duration, clock: .continuous) +} \ No newline at end of file diff --git a/Samples/Dinner/Sources/Onboarding/Dinner.swift b/Samples/Dinner/Sources/Onboarding/Dinner.swift new file mode 100644 index 0000000..f52d641 --- /dev/null +++ b/Samples/Dinner/Sources/Onboarding/Dinner.swift @@ -0,0 +1,90 @@ +//===----------------------------------------------------------------------===// +// +// This source file is part of the Swift Distributed Tracing open source project +// +// Copyright (c) 2020-2023 Apple Inc. and the Swift Distributed Tracing project +// authors +// Licensed under Apache License v2.0 +// +// See LICENSE.txt for license information +// +// SPDX-License-Identifier: Apache-2.0 +// +//===----------------------------------------------------------------------===// +//===----------------------------------------------------------------------===// +// +// This source file is part of the Swift OpenTelemetry open source project +// +// Copyright (c) 2021 Moritz Lang and the Swift OpenTelemetry project authors +// Licensed under Apache License v2.0 +// +// See LICENSE.txt for license information +// +// SPDX-License-Identifier: Apache-2.0 +// +//===----------------------------------------------------------------------===// + + +import Tracing + +func makeDinner() async throws -> Meal { + try await InstrumentationSystem.tracer.withSpan("makeDinner") { _ in + await sleep(for: .milliseconds(200)) + + async let veggies = try chopVegetables() + async let meat = marinateMeat() + async let oven = preheatOven(temperature: 350) + // ... + return try await cook(veggies, meat, oven) + } +} + +func chopVegetables() async throws -> [Vegetable] { + try await otelChopping1.tracer().withSpan("chopVegetables") { _ in + // Chop the vegetables...! + // + // However, since chopping is a very difficult operation, + // one chopping task can be performed at the same time on a single service! + // (Imagine that... we cannot parallelize these two tasks, and need to involve another service). + async let carrot = try chop(.carrot, tracer: otelChopping1.tracer()) + async let potato = try chop(.potato, tracer: otelChopping2.tracer()) + return try await [carrot, potato] + } +} + +func chop(_ vegetable: Vegetable, tracer: any Tracer) async throws -> Vegetable { + await tracer.withSpan("chop-\(vegetable)") { _ in + await sleep(for: .seconds(5)) + // ... + return vegetable // "chopped" + } +} + +func marinateMeat() async -> Meat { + await sleep(for: .milliseconds(620)) + + return await InstrumentationSystem.tracer.withSpan("marinateMeat") { _ in + await sleep(for: .seconds(3)) + // ... + return Meat() + } +} + +func preheatOven(temperature: Int) async -> Oven { + await InstrumentationSystem.tracer.withSpan("preheatOven") { _ in + // ... + await sleep(for: .seconds(6)) + return Oven() + } +} + +func cook(_: Any, _: Any, _: Any) async -> Meal { + await InstrumentationSystem.tracer.withSpan("cook") { span in + span.addEvent("children-asking-if-done-already") + await sleep(for: .seconds(3)) + span.addEvent("children-asking-if-done-already-again") + await sleep(for: .seconds(2)) + // ... + return Meal() + } +} diff --git a/Samples/Dinner/Sources/Onboarding/Model.swift b/Samples/Dinner/Sources/Onboarding/Model.swift new file mode 100644 index 0000000..0574946 --- /dev/null +++ b/Samples/Dinner/Sources/Onboarding/Model.swift @@ -0,0 +1,35 @@ +//===----------------------------------------------------------------------===// +// +// This source file is part of the Swift Distributed Tracing open source project +// +// Copyright (c) 2020-2023 Apple Inc. and the Swift Distributed Tracing project +// authors +// Licensed under Apache License v2.0 +// +// See LICENSE.txt for license information +// +// SPDX-License-Identifier: Apache-2.0 +// +//===----------------------------------------------------------------------===// +//===----------------------------------------------------------------------===// +// +// This source file is part of the Swift OpenTelemetry open source project +// +// Copyright (c) 2021 Moritz Lang and the Swift OpenTelemetry project authors +// Licensed under Apache License v2.0 +// +// See LICENSE.txt for license information +// +// SPDX-License-Identifier: Apache-2.0 +// +//===----------------------------------------------------------------------===// + + +struct Meal: Sendable {} +struct Meat: Sendable {} +struct Oven: Sendable {} +enum Vegetable: Sendable { + case potato + case carrot +} + diff --git a/Samples/Dinner/Sources/Onboarding/main.swift b/Samples/Dinner/Sources/Onboarding/main.swift new file mode 100644 index 0000000..e5c214e --- /dev/null +++ b/Samples/Dinner/Sources/Onboarding/main.swift @@ -0,0 +1,77 @@ +//===----------------------------------------------------------------------===// +// +// This source file is part of the Swift Distributed Tracing open source project +// +// Copyright (c) 2020-2023 Apple Inc. and the Swift Distributed Tracing project +// authors +// Licensed under Apache License v2.0 +// +// See LICENSE.txt for license information +// +// SPDX-License-Identifier: Apache-2.0 +// +//===----------------------------------------------------------------------===// +//===----------------------------------------------------------------------===// +// +// This source file is part of the Swift OpenTelemetry open source project +// +// Copyright (c) 2021 Moritz Lang and the Swift OpenTelemetry project authors +// Licensed under Apache License v2.0 +// +// See LICENSE.txt for license information +// +// SPDX-License-Identifier: Apache-2.0 +// +//===----------------------------------------------------------------------===// + + +import Logging +import NIO +import OpenTelemetry +import OtlpGRPCSpanExporting +import Tracing + +// ==== ---------------------------------------------------------------------------------------------------------------- + +let group = MultiThreadedEventLoopGroup(numberOfThreads: 1) + +LoggingSystem.bootstrap { label in + var handler = StreamLogHandler.standardOutput(label: label) + handler.logLevel = .trace + return handler +} + +// ==== ---------------------------------------------------------------------------------------------------------------- +// MARK: - Configure OTel + +let exporter = OtlpGRPCSpanExporter(config: OtlpGRPCSpanExporter.Config(eventLoopGroup: group)) +let processor = OTel.SimpleSpanProcessor(exportingTo: exporter) +let otel = OTel(serviceName: "DinnerService", eventLoopGroup: group, processor: processor) + +let otelChopping1 = OTel(serviceName: "ChoppingService-1", eventLoopGroup: group, processor: processor) +let otelChopping2 = OTel(serviceName: "ChoppingService-2", eventLoopGroup: group, processor: processor) + +// First start `OTel`, then bootstrap the instrumentation system. +// This makes sure that all components are ready to begin handling spans. +try otel.start().wait() +try otelChopping1.start().wait() +try otelChopping2.start().wait() + +// By bootstrapping the instrumentation system, our dependencies +// compatible with "Swift Distributed Tracing" will also automatically +// use the "OpenTelemetry Swift" Tracer πŸš€. +InstrumentationSystem.bootstrap(otel.tracer()) + +// ==== ---------------------------------------------------------------------------------------------------------------- +// MARK: - Run the sample app + +let dinner = try await makeDinner() + +// ==== ---------------------------------------------------------------------------------------------------------------- +// MARK: - Shutdown + +// Wait a second to let the exporter finish before shutting down. +sleep(2) + +try otel.shutdown().wait() +try group.syncShutdownGracefully() diff --git a/Samples/Dinner/docker/collector-config.yaml b/Samples/Dinner/docker/collector-config.yaml new file mode 100644 index 0000000..d07e13d --- /dev/null +++ b/Samples/Dinner/docker/collector-config.yaml @@ -0,0 +1,24 @@ +receivers: + otlp: + protocols: + grpc: + endpoint: otel-collector:4317 + +exporters: + logging: + verbosity: detailed + + jaeger: + endpoint: "jaeger:14250" + tls: + insecure: true + + zipkin: + endpoint: "http://zipkin:9411/api/v2/spans" + + +service: + pipelines: + traces: + receivers: otlp + exporters: [logging, jaeger, zipkin] diff --git a/Samples/Dinner/docker/docker-compose.yaml b/Samples/Dinner/docker/docker-compose.yaml new file mode 100644 index 0000000..b4522b4 --- /dev/null +++ b/Samples/Dinner/docker/docker-compose.yaml @@ -0,0 +1,26 @@ +version: '3' +services: + otel-collector: + image: otel/opentelemetry-collector-contrib:latest + command: ["--config=/etc/config.yaml"] + volumes: + - ./collector-config.yaml:/etc/config.yaml + ports: + - "4317:4317" + networks: [exporter] + depends_on: [zipkin, jaeger] + + zipkin: + image: openzipkin/zipkin:latest + ports: + - "9411:9411" + networks: [exporter] + + jaeger: + image: jaegertracing/all-in-one + ports: + - "16686:16686" + networks: [exporter] + +networks: + exporter: diff --git a/Sources/Tracing/Docs.docc/Guides/ImplementATracer.md b/Sources/Tracing/Docs.docc/Guides/ImplementATracer.md new file mode 100644 index 0000000..397949e --- /dev/null +++ b/Sources/Tracing/Docs.docc/Guides/ImplementATracer.md @@ -0,0 +1,169 @@ +# Implement a Tracer + +## Overview + +This guide is aimed at ``Tracer`` and `Instrument` protocol implementation authors. + +This guide is for you if you find yourself in need of implementing your own tracing client such as Zipkin, Jaeger, X-Trace, OpenTelemetry or something similar that is custom to your company or distributed system. It will also complete your understanding of how distributed tracing systems actually work, so even the casual developer may find this guide useful to read through, even if not implementing your own tracers. + +## Do you need an Instrument or a Tracer? + +Distributed tracing offers two types of instrumentation protocols: an instrument, and a tracer. + +A tracer is-an instrument as well, and further refines it with the ability to start a trace ``Span``. + +## Creating an instrument + +In order to implement an instrument you need to implement the `Instrument` protocol. +`Instrument` is part of the `Instrumentation` library that `Tracing` depends on and offers the minimal core APIs that allow implementing instrumentation types. + +`Instrument` has two requirements: + +1. An `Instrument/extract(_:into:using:)` method, which extracts values from a generic carrier (e.g. HTTP headers) and store them into a `Baggage` instance +2. An `Instrument/inject(_:into:using:)` method, which takes values from the `Baggage` to inject them into a generic carrier (e.g. HTTP headers) + +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. + +> The [`Baggage` documentation](https://github.com/apple/swift-distributed-tracing-baggage) type is declared in the swift-distributed-tracing-baggage package. + +### Creating a `Tracer` + +When creating a tracer you will need to implement two types: + +1. Your tracer conforming to ``Tracer`` +2. A span type conforming to ``Span`` + +> ``Span`` largely resembles span concept as defined [OpenTelemetry](https://github.com/open-telemetry/opentelemetry-specification/blob/v0.7.0/specification/trace/api.md#span), however this package does not enforce certain rules specified in there - that is left up to a specific open telemetry tracer implementation. + +### Defining, injecting and extracting Baggage + +In order to be able to extract and inject values into the `Baggage` which is the value that is "carried around" across asynchronous contexts, +we need to declare a `BaggageKey`. Baggage generally acts as a type-safe dictionary and declaring the keys this way allows us to perform lookups +returning the expected type of values: + +```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 + } + } +} +``` + +Which is then to be used like this: + +```swift +var baggage = Barrage.current ?? Baggage.topLevel +baggage.traceID = "4bf92f3577b34da6a3ce929d0e0e4736" +print(baggage.traceID ?? "") +``` + +Here we used a `Baggage.current` to "_pick up_" the task-local baggage value, if present, +and if not present we created a new "top level" baggage item. This API specifically is +named "top level" to imply that this should be used when first initiating a top level +context propagation baggage -- whenever possible, prefer to pick up the `current` baggage. + +### Injecting and extracting Baggage + +When hitting boundaries like an outgoing HTTP request the library will call out to the [configured instrument(s)](#Bootstrapping-the-Instrumentation-System): + +For example, an imaginary HTTP client library making a GET request would look somewhat like this: + +```swift +func get(url: String) { + var request = HTTPRequest(url: url) + if let baggage = Baggage.current { + InstrumentationSystem.instrument.inject( + baggage, + into: &request.headers, + using: HTTPHeadersInjector() + ) + // actually make the HTTP request + } +} +``` + +On the receiving side, an HTTP server should use the following `Instrument` API to extract the HTTP headers of the given +`HTTPRequest` _into_ the baggage and then wrap invoking user code (or the "next" call in a middleware setup) with `Baggage.withValue` +which sets the Baggage.current task local value: + +```swift +func handler(request: HTTPRequest) async throws { + var requestBaggage = Baggage.current ?? .topLevel + InstrumentationSystem.instrument.extract( + request.headers, + into: &requestBaggage, + using: HTTPHeadersExtractor() + ) + + try await Baggage.withValue(requestBaggage) { + // invoke user code ... + } +} +``` + +> In case your library makes use of the `NIOHTTP1.HTTPHeaders` type we already have an `HTTPHeadersInjector` and +`HTTPHeadersExtractor` available as part of the `NIOInstrumentation` library. + +For your library/framework to be able to carry `Baggage` across asynchronous boundaries, it's crucial that you carry the context throughout your entire call chain in order to avoid dropping metadata. + +## 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 `Baggage` 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 `Baggage` + +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 `Baggage` 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 = Baggage.topLevel(logger: ...) +context.baggage.traceID = "4bf92f3577b34da6a3ce929d0e0e4736" +print(context.baggage.traceID ?? "new trace id") +``` diff --git a/Sources/Tracing/Docs.docc/Guides/InstrumentYourLibrary.md b/Sources/Tracing/Docs.docc/Guides/InstrumentYourLibrary.md new file mode 100644 index 0000000..70110e9 --- /dev/null +++ b/Sources/Tracing/Docs.docc/Guides/InstrumentYourLibrary.md @@ -0,0 +1,345 @@ +# Instrument Your Library or Framework + +## Overview + +This guide is aimed at library and framework developers who wish to instrument their code using distributed tracing. + +Doing so within a library may enable automatic trace propagation and is key to propagating trace information across distributed nodes, e.g. by instrumenting the HTTP client used by such system. + +Other examples of libraries which would benefit _the most_ from being instrumented using distributed tracing include: + +- HTTP Clients (e.g. AsyncHTTPClient), +- HTTP Servers (e.g. Vapor or Smoke), +- RPC systems (Swift gRPC or Swift's `DistributedActorSystem` implementations), +- database drivers (e.g. SQL or MongoDB clients), +- any other library which can emit meaningful span information about tasks it is performing. + +The most important libraries to instrument are "edge" libraries, which serve to connect between systems, because +it is them who must inject and extract contextual baggage metadata to enable distributed trace ``Span`` propagation. + +Following those, any database or other complex library which may be able to emit useful information about its internals are +also good candidates to being instrumented. Note that libraries may do so optionally, or hide the "verboseness" of such traces +behind options, or only attach information if a ``Span`` is already active etc. Please review your library's documentation to learn +more about it has integrated tracing support. + +### Propagating baggage metadata + +When crossing boundaries between processes, such as making or receiving an HTTP request, the library responsible for doing so should invoke instrumentation in order to inject or extract the contextual baggage metadata into/from the "carrier" type (such as the `HTTPResponse`) type. + +#### Handling outbound requests + +When a library makes an "outgoing" request or message interaction, it should invoke the method of a configured instrument. This will invoke whichever instrument the end-user has configured and allow them to customize what metadata gets to be propagated. This can be depicted by the following diagram: + +``` + β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” + β”‚ Specific Tracer / Instrument β”‚ + β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ + β”‚ + instrument.inject(baggage, into: request, using: httpInjector) + β”‚ + β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β–Όβ”€β”€β”€β”€β”€β”€β” + β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€ Tracing API β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β” + β”‚HTTPClient β””β”€β”€β”€β”€β”€β”€β”€β”€β–²β”€β”€β”€β”€β”€β”€β”˜ β”‚ β”‚ N β”‚ + β”‚ β”‚ β”‚ β”‚ e β”‚ + β”‚ β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”Œβ”€β”€β–Όβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”‚ β”‚ t β”‚ +β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”‚ | make β”‚ β”‚ add metadata to β”‚ β”‚ β”‚ w β”‚ +β”‚ User code |────▢│ β”‚ HTTPRequest │──▢│ HTTPRequest │────┼─────▢│ o β”‚ +β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β”‚ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β”‚ β”‚ r β”‚ + β”‚ β”‚ β”‚ k β”‚ + β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β””β”€β”€β”€β”€β”˜ +``` + +> Note: A library _itself_ cannot really know what information to propagate, since that depends on the used tracing or instrumentation system. The library does however understand its carrier type, and thus can implement the `Instrumentation/Injector` protocol. + +For example, an HTTP client e.g. should inject the current baggage (which could be carrying trace ``Span`` information) into the HTTP headers as follows: + +```swift +func get(url: String) -> HTTPResponse { + var request = HTTPRequest(url: url) + + if let baggage = Baggage.current { + InstrumentationSystem.instrument.inject( + baggage, + into: &request, + using: HTTPRequestInjector() + ) + } + + try await _send(request) +} +``` + +As you can see, the library does not know anything about what tracing system or instrumentation is installed, because it cannot know that ahead of time. + +All it has to do is query for the current [task-local](https://developer.apple.com/documentation/swift/tasklocal) `Baggage` value, and if one is present, call on the instrumentation system to inject it into the request. + +Since neither the tracing API, nor the specific tracer backend are aware of this library's specific `HTTPRequest` type, we also need to implement an `Instrumentation/Injector` which takes on the responsibility of adding the metadata into the carrier type (which in our case is the `HTTPRequest`). An injector could for example be implemented like this: + +```swift +struct HTTPRequestInjector: Injector { + func inject(_ value: String, forKey key: String, into request: inout HTTPRequest) { + request.headers.append((key, value)) + } +} +``` + +Once the metadata has been injected, the request--including all the additional metadata--is sent over the network. + +> Note: The actual logic of deciding what baggage values to inject depend on the tracer implementation, and thus we are not covering it in this _end-user_ focused guide. Refer to if you'd like to learn about implementing a ``Tracer``. + +#### Handling inbound requests + +On the receiving side, an HTTP server needs to perform the inverse operation, as it receives the request from the network and forms an `HTTPRequest` object. Before it is passed it to user-code, it must extract any trace metadata from the request headers into the `Baggage`. + +``` + β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” + β”‚ Specific Tracer / Instrument β”‚ + β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ + β–² + β”‚ + instrument.extract(request, into: &baggage, using: httpExtractor) + β”‚ + β”Œβ”€β”€β”€β”€β”€β”€β–Όβ”€β”€β”€β”€β”€β”€β” +β”Œβ”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€ Tracing API β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” +β”‚ N β”‚ β”‚HTTPServerLib β””β”€β”€β”€β”€β”€β”€β–²β”€β”€β”€β”€β”€β”€β”˜ β”‚ +β”‚ e β”‚ β”‚ β”‚ β”‚ +β”‚ t β”‚ β”‚β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”Œβ”€β–Όβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”‚ +β”‚ w β”‚ β”‚β”‚ parse β”‚ β”‚extract metadata β”‚ β”‚ β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” +β”‚ o │─────────▢││ HTTPRequest β”œβ”€β”€β–Άfrom HTTPRequest │───┼────▢│ User code β”‚ +β”‚ r β”‚ β”‚β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β”‚ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ +β”‚ k β”‚ β”‚ β”‚ +β”‚ β”‚ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ +└──── +``` + +This is very similar to what we were doing on the outbound side, but the roles of baggage and request are somewhat reversed: we're extracting values from the carrier into the baggage. The code performing this task could look something like this: + +```swift +func handler(request: HTTPRequest) async { + // we are beginning a new "top level" context - the beginning of a request - + // and thus start from a fresh, empty, top-level baggage: + var baggage = Baggage.topLevel + + // populate the baggage by extracting interesting metadata from the incoming request: + InstrumentationSystem.instrument.extract( + request, + into: &baggage, + using: HTTPRequestExtractor() + ) + + // ... invoke user code ... +} +``` + +Similarly to the outbound side, we need to implement an `Instrumentation/Extractor` because the tracing libraries don't know about our specific HTTP types, yet we need to have them decide for which values to extract keys. + +```swift +struct HTTPRequestExtract: Instrumentation.Extractor { + func extract(key: String, from request: HTTPRequest) -> String? { + request.headers.first(where: { $0.0 == key })?.1 + } +} +``` + +Which exact keys will be asked for depends on the tracer implementation, thus we don't present this part of the implementation in part of the guide. For example, a tracer most likely would look for, and extract, values for keys such as `trace-id` and `span-id`. Note though that the exact semantics and keys used by various tracers differ, which is why we have to leave the decision of what to extract up to tracer implementations. + +Next, your library should "*restore*" the contextual baggage, this is performed by setting the baggage task-local value around calling into user code, like this: + +```swift +func handler(request: HTTPRequest) async { + // ... + InstrumentationSystem.instrument.extract(..., into: &baggage, ...) + // ... + + // wrap user code with binding the Baggage task local: + await Baggage.withValue(baggage) { + await userCode(request) + } + + // OR, alternatively start a span here - if your library should be starting spans on behalf of the user: + // await startSpan("HTTP \(request.path)" { span in + // await userCode(request) + // } +} +``` + +This sets the task-local value `Baggage.current` which is used by [swift-log](https://github.com/apple/swift-log), as well as ``Tracer`` APIs in order to later "*pick up*" the baggage and e.g. include it in log statements, or start new trace spans using the information stored in the baggage. + +> Note: The end goal here being that when end-users of your library write `log.info("Hello")` the logger is able to pick up the contextual baggage information and include the e.g. the `trace-id` in such log statement automatically! This way, every log made during the handling of this request would include the `trace-id` automatically, e.g. like this: +> +> `12:43:32 info [trace-id=463a...13ad] Logging during handling of a request!` + +If your library makes multiple calls to user-code as part of handling the same request, you may consider if restoring the baggage around all of these callbacks is beneficial. For example, if a library had callbacks such as: + +```swift +/// Example library protocol, offering multiple callbacks, all semantically part of the same request handling. +protocol SampleHTTPHandler { + // called immediately when an incoming HTTPRequests headers are available, + // even before the request body has been processed. + func requestHeaders(headers: HTTPHeaders) async + + // Called multiple (or zero) times, for each "part" of the incoming HTTPRequest body. + func requestBodyPart(ByteBuffer) async +} +``` + +You may want to restore the baggage once around both those calls, or if that is not possible, restore it every time when calling back into user code, e.g. like this: + +```swift +actor MySampleServer { + + var baggage: Baggage = .topLevel + var userCode: SampleHTTPHandler + + func onHeaders(headers: HTTPHeaders) async { + await Baggage.withValue(self.baggage) { + await userHandler.requestHeaders(headers) + } + } + + func onBodyPart(part: ByteBuffer) async { + await Baggage.withValue(self.baggage) { + await userHandler.requestHeaders(headers) + } + } +} +``` + +While this code is very simple for illustration purposes, and it may seem surprising why there are two separate places where we need to call into user-code separately, in practice such situations can happen when using asynchronous network or database libraries which offer their API in terms of callbacks. Always consider if and when to restore baggage such that it makes sense for the end user. + +### Starting Trace Spans in Your Library + +The above steps are enough if you wanted to provide contextual baggage propagation. It already enables techniques such as **correlation ids** which can be set once, in one system, and then carried through to any downstream services the code makes calls from while the baggage is set. + +Many libraries also have the opportunity to start trace spans themselfes, on behalf of users, in pieces of the library that can provide useful insight in the behavior or the library in production. For example, the `HTTPServer` can start spans as soon as it begins handling HTTP requests, and this way provide a parent span to any spans the user-code would be creating itself. + +Let us revisit the previous sample `HTTPServer` which restored baggage around invoking the user-code, and further extend it to start a span including basic information about the `HTTPRequest` being handled: + +```swift +// SUB-OPTIMAL EXAMPLE: +func handler(request: HTTPRequest) async { + // 1) extract trace information into baggage... + InstrumentationSystem.instrument.extract(..., into: &baggage, ...) + // ... + + // 2) restore baggage, using a task-local: + await Baggage.withValue(baggage) { + // 3) start span, using contextual baggage (which may contain trace-ids already): + await withSpan("\(request.path)") { span in + // 3.1) Set useful attributes:on the span: + span.attributes["http.method"] = request.method + // ... + // See also: Open Telemetry typed attributes in swift-distributed-tracing-extras + + // 4) user code will have the apropriate Span baggage restored: + await userCode(request) + } + } +} +``` + +This is introducing multiple layers of nesting, and we have un-necessarily restored, picked-up, and restored the baggage again. In order to avoid this duplicate work, it is beneficial to use the ``withSpan(_:baggage:ofKind:at:function:file:line:_:)-4o2b`` overload, which also accepts a `Baggage` as parameter, rather than picking it up from the task-local value: + +```swift +// BETTER +func handler(request: HTTPRequest) async { + // 1) extract trace information into baggage: + InstrumentationSystem.instrument.extract(..., into: &baggage, ...) + + // 2) start span, passing the freshly extracted baggage explicitly: + await withSpan("\(request.path)", baggage: baggage) { span in + // ... + } +} +``` + +This method will only restore the baggage once, after the tracer has had a chance to decide if this execution will be traced, and if so, setting its own trace and span identifiers. This way only one task-local access (set) is performed in this version of the code, which is preferable to the set/read/set that was performed previously. + +#### Manual Span Lifetime Management + +While the ``withSpan(_:baggage:ofKind:at:function:file:line:_:)-4o2b`` API is preferable in most situations, it may not be possible to use when the lifetime of a span only terminates in yet another callback API. In such situations, it may be impossible to "wrap" the entire piece of code that would logically represent "the span" using a `withSpan(...) { ... }` call. + +In such situations you can resort to using the ``startSpan(_:baggage:ofKind:at:function:file:line:)`` and ``Span/end()`` APIs explicitly. Those APIs can then be used like this: + +```swift +// Callback heavy APIs may need to store and manage spans manually: +var span: Span? + +func startHandling(request: HTTPRequest) { + self.span = startSpan("\(request.path)") + + userCode.handle(request) +} + +func finishHandling(request: HTTPRequest, response: HTTPResponse) { + // always end spans (!) + span?.end() // ends and flushes the span +} +``` + +It is very important to _always_ end spans that are started, as attached resources may keep accumulating and lead to memory leaks or worse issues in tracing backends depending on their implementation. + +The manual way of managing spans also means that error paths need to be treated with increased attention. This is something that `withSpan` APIs handle automatically, but we cannot rely on `withSpan` detecting an error thrown out of its body closure anymore when using the `startSpan`/`Span.end` APIs. + +When an error is thrown, or if the span should be considered errored for some reason, you should invoke the ``Span/recordError(_:)`` method and pass an `Swift.Error` that should be recorded on the span. Since failed spans usually show up in very visually distinct ways, and are most often the first thing a developer inspecting an application using tracing is looking for, it is important to get error reporting right in your library. Here is a simple example how this might look like: + +```swift +var span: any Span + +func onError(error: Error) { + span.recordError(error) // record the error, and... + span.end() // end the span +} +``` + +It is worth noting that double-ending a span should be considered a programmer error, and tracer implementations are free to crash or otherwise report such problem. + +> Note: The problem with finding a span that was ended in two places is that its lifecycle seems to be incorrectly managed, and therefore the span timing information is at risk of being incorrect. +> +> Please also take care to never `end()` a span that was created using `withSpan()` APIs, because `withSpan` will automatically end the span when the closure returns. + +#### Storing and restoring baggage across callbacks + +Note also since a `Span` contains an instrumentation `Baggage`, you can also pass the span's baggage to any APIs which may need it, or even restore the baggage e.g. for loggers to pick it up while emitting log statements: + +```swift +final class StatefulHandler { + var span: any Span + + func startHandling(request: HTTPRequest) { + self.span = InstrumentationSystem.tracer.startSpan("\(request.path)") + } + + // callback, form other task, so we don't have the task-local information here anymore + func onSomethingHappening(event: SomeEvent) { + Baggage.withValue(span.baggage) { // restore task-local baggage + // which allows the baggage to be used by loggers and tracers as usual again: + log.info("Event happened: \(event)") + + // since the baggage was restored here, the startSpan will pick it up, + // and the "event-id" span will be a child of the "request.path" span we started before. + withSpan("event-\(event.id)") { span in // new child span (child of self.span) + // ... handle the event ... + } + } + } +} +``` + +It is also possible to pass the baggage explicitly to `withSpan` or `startSpan`: + +```swift +withSpan("event-\(event.id)", baggage: span.baggage) { span in + // ... +} +``` + +which is equivalent to surrounding thr withSpan with a binding of the baggage. The passed baggage (with the values updated by the tracer), will then be set for the duration of the `withSpan` operation, just like usual. + +### Global vs. "Stored" Tracers and Instruments + +Tracing works similarly to swift-log and swift-metrics, in the sense that there is a global "backend" configured at application start, by end-users (developers) of an application. And this is how using `InstrumentationSystem/tracer` gets the "right" tracer at runtime. + +You may be tempted to allow users _configuring_ a tracer as part of your applications initialization. Generally we advice against that pattern, because it makes it confusing which library needs to be configured, how, and where -- and if libraries are composed, perhaps the setting is not available to the actual "end-user" anymore. + +On the other hand, it may be valuable for testing scenarios to be able to set a tracer on a specific instance of your library. Therefore, if you really want to offer a configurable `Instrument` or `Tracer` then we suggest defaulting this setting to `nil`, and if it is `nil`, reaching to the global `InstrumentationSystem/instrument` or `InstrumentationSystem/tracer` - this way it is possible to override a tracer for testing on a per-instance basis, but the default mode of operation that end-users expect from libraries remains working. diff --git a/Sources/Tracing/Docs.docc/Guides/TraceYourApplication.md b/Sources/Tracing/Docs.docc/Guides/TraceYourApplication.md new file mode 100644 index 0000000..f7cf894 --- /dev/null +++ b/Sources/Tracing/Docs.docc/Guides/TraceYourApplication.md @@ -0,0 +1,502 @@ +# Trace Your Application + +## Overview + +This guide is aimed at **application developers** who have some server-side system and want to make use of distributed tracing +in order to improve their understanding and facilitate performance tuning and debugging their services in production or development. + +Distributed tracing offers a way to gain additional insight into how your application is performing in production, without having to reconstruct the "big picture" from manually piecing together log lines and figuring out what happened +after what else and _why_. Distributed traces, as the name implies, also span multiple nodes in a microservice architecture +or clustered system, and provide a profiler-like experience to debugging the handling of a "request" or otherwise defined span. + +### Setting up + +The first step to get metadata propagation and tracing working in your application is picking an instrumentation or tracer. +A complete [list of swift-distributed-tracing implementations](http://github.com/apple/swift-distributed-tracing) +is available in this project's README. Select an implementation you'd like to use and follow its bootstrap steps. + +> Note: Since instrumenting an **application** in practice will always need to pull in an existing tracer implementation, +> in this guide we'll use the community maintained [`swift-otel`](https://github.com/slashmo/swift-otel) +> tracer, as an example of how you'd start using tracing in your real applications. +> +> If you'd rather implement your own tracer, refer to . + +Once you have selected an implementation, add it as a dependency to your `Package.swift` file. + +```swift +// Depend on the instrumentation library, e.g. swift-otel: +.package(url: "https://github.com/slashmo/swift-otel.git", from: ""), + +// This will automatically include a dependency on the swift-distributed-tracing API: +// .package(url: "https://github.com/apple/swift-distributed-tracing.git", from: "1.0.0"), +``` + +Next, add the dependency to your application target. You should follow the [instructions available in the package's README](https://github.com/slashmo/swift-otel) if unsure how to do this. + +### Bootstrapping the Tracer + +Similar to [swift-log](https://github.com/apple/swift-log) and [swift-metrics](https://github.com/apple/swift-metrics), +the first thing you'll need to do in your application to use tracing, is to bootstrap the global instance of the tracing system. + +This will allow not only your code, that we're about to write, to use tracing, but also all other libraries which +have been implemented against the distributed tracing API to use it as well. For example, by configuring the global +tracing system, an HTTP server or client will automatically handle trace propagation for you, so make sure to always +bootstrap your tracer globally, otherwise you might miss out on its crucial context propagation features. + +How the tracer library is initialized will differ from library to library, so refer to the respective implementation's +documentation. Once you're ready, pass the tracer or instrument to the `InstrumentationSystem/bootstrap(_:)` method, +e.g. like this: + +```swift +import Tracing // this library + +// Import and prepare whatever the specific tracer implementation needs. +// In our example case, we'll prepare the OpenTelemetry tracing system: +import NIO +import OpenTelemetry + +let group = MultiThreadedEventLoopGroup(numberOfThreads: 1) +let otel = OTel(serviceName: "onboarding", eventLoopGroup: group) +try otel.start().wait() + +// Bootstrap the tracing system: +InstrumentationSystem.bootstrap(otel.tracer()) +``` + +You'll notice that the API specifically talks about Instrumentation rather than just Tracing. +This is because it is also possible to use various instrumentation systems, e.g. which only take care +of propagating certain `Baggage` values across process boundaries, without using tracing itself. + +In other words, all tracers are instruments, and the `InstrumentationSystem` works equally for `Instrument`, +as well as ``Tracer`` implementations. + +Our guide focuses on tracing through, so let's continue with that in mind. + +#### 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 Distributed Tracing](https://github.com/apple/swift-distributed-tracing)'s `InstrumentationSystem` +4. Finally, any other parts of your application + +This is because tracing systems may attempt to emit logs or metrics about their status etc. + +If you intend to use trace identifiers for log correlation (i.e. logging a `trace-id` in every log statement that is part of a trace), +then don't forget to also configure a swift-lot `MetadataProvider`. + +A typical bootstrap could look something like this: + +```swift +import Tracing // API +import Logging // API + +import OpenTelemetry // specific Tracing library +import StatsdMetrics // specific Metrics library + +extension Logger.MetadataProvider { + + // Include the following OpenTelemetry tracer specific metadata in log statements: + static let otel = Logger.MetadataProvider { baggage in + guard let spanContext = baggage?.spanContext else { return nil } + return [ + "trace-id": "\(spanContext.traceID)", + "span-id": "\(spanContext.spanID)", + ] + } +} + +// 1) bootstrap swift-log: stdout-logger +LoggingSystem.bootstrap( + StreamLogHandler.standardOutput, + metadataProvider: .otel +) + +// 2) bootstrap metrics: statsd +let statsdClient = try StatsdClient(host: host, port: port) +MetricsSystem.bootstrap(statsdClient) + +// 3) bootstrap swift-distributed-tracing: open-telemetry +let group: MultiThreadedEventLoopGroup = ... +let otel = OTel(serviceName: "onboarding", eventLoopGroup: group) + +try otel.start().wait() +InstrumentationSystem.bootstrap(otel.tracer()) + +// 4) Continue starting your application ... +``` + +#### Bootstrapping multiple instruments using MultiplexInstrument + +If you'd find yourself in need of using multiple instrumentation or tracer implementations you can 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. + +### Introducing Trace Spans + +The primary way you interact with distributed tracing is by starting ``Span``s. + +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. + +In order to discuss how tracing works, let us first look at a sample trace, before we even take a look at the any source code. This reflects how you may find yourself using tracing once it has been adopted in your microservice or distributed system architecture: there are many services involved, and often times only from a trace you can know where to start looking at a performance or logical regression in the system. + +> Experiment: **Follow along!** You can follow along and explore the generated traces, and the code producing them by opening the sample project located in `Samples/Dinner`! +> +> The sample includes a docker-compose file which starts an [OpenTelemetry](https://opentelemetry.io) [collector](https://opentelemetry.io/docs/collector/), as well as two UIs which can be used to explore the generated traces: +> +> - [Zipkin](http://zipkin.io) - available at [http://127.0.0.1:9411](http://127.0.0.1:9411) +> - [Jaeger](https://www.jaegertracing.io) - available at [http://127.0.0.1:16686](http://127.0.0.1:16686) +> +> In order to start these containers, navigate to the `Samples/Dinner` project and run `docker-compose`, like this: +> +> ```bash +> $ cd Samples/Dinner +> $ docker-compose -f docker/docker-compose.yaml up --build +> # Starting docker_zipkin_1 ... done +> # Starting docker_jaeger_1 ... done +> # Recreating docker_otel-collector_1 ... done +> # Attaching to docker_jaeger_1, docker_zipkin_1, docker_otel-collector_1 +> ``` +> +> This will run docker containers with the services described above, and expose their ports via localhost, +> including the collector to which we now can export our traces from our development machine. +> +> Keep these containers running, and then, in another terminal window run the sample app that will generate some traces: +> +> ```bash +> $ swift run -c release +> ``` + +Once you have run the sample app, you need to hit "search" in either trace visualization UI, and navigate through to expand the trace view. You'll be greeted with a trace looking somewhat like this (in Zipkin): + +![Make dinner trace diagram](makeDinner-zipkin-01) + +Or, if you prefer Jaeger, it'd look something like this: + +![Make dinner trace diagram](makeDinner-jaeger-01) + +Take a moment to look at the trace spans featured in these diagrams. + +By looking at them, you should be able to get a rough idea what the code is doing. That's right, it is a top-level `makeDinner` method, that seems to be performing a bunch of tasks in order to prepare a nice meal. + +You may also notice that all those traces are executing in the same _service_: the `DinnerService`. This means that we only had one process involved in this trace. Further, by investigating this trace, we can spot that the `chopVegetables` parent span starts two child spans: `chop-carrot` and `chop-potato`, but does so **sequentially**! If we were looking to optimize the time it takes for `makeDinner` to complete, parallelizing these vegetable chopping tasks could be a good idea. + +Now, let us take a brief look at the code creating all these spans. + +> Tip: You can refer to the full code located in `Samples/Dinner/Sources/Onboarding`. + +```swift +import Tracing + +func makeDinner() async throws -> Meal { + try await withSpan("makeDinner") { _ in + async let veggies = try chopVegetables() + async let meat = marinateMeat() + async let oven = preheatOven(temperature: 350) + // ... + return try await cook(veggies, meat, oven) + } +} + +func chopVegetables() async throws -> [Vegetable] { + await withSpan("chopVegetables") { + // Chop the vegetables...! + // + // However, since chopping is a very difficult operation, + // one chopping task can be performed at the same time on a single service! + // (Imagine that... we cannot parallelize these two tasks, and need to involve another service). + let carrot = try await chop(.carrot) + let potato = try await chop(.potato) + return [carrot, potato] + } +} + +// ... +``` + +It seems that the sequential work on the vegetable chopping is not accidental... we cannot do two of those at the same time on a single service. Therefore, let's introduce new services that will handle the vegetable chopping for us! + +For example, we could split out the vegetable chopping into a service on its own, and request it (via an HTTP, gRPC, or `distributed actor` call), to chop some vegetables for us. The resulting trace will have the same information, even though a part of it now has been executing on a different host! To further illustrate that, let us re-draw the previous diagram, while adding node designations to each span: + +A trace of such system would then look like this: + +![A new service handling "chopping" tasks is introduced, it has 3 spans about chopping](makeDinner-zipkin-02) + +The `DinnerService` reached out to `ChoppingService-1` that it discovered, and then to parallelize the work, it submitted the secondary chopping task to another service (`ChoppingService-2`). Those two tasks are now performed in parallel, leading to a an improved response time of `makeDinner` service call. + +Let us have another look at these spans in Jaeger. The search UI will show us both the previous, and latest execution traces, so we can compare how the execution changed over time: + +![Search view in Jaeger, showing the different versions of traces](makeDinner-jaeger-02) + +The different services are color coded, and we can see them execute in parallel here as well: + +![Trace view in Jaeger, spans are parallel now](makeDinner-jaeger-03) + +One additional view we can explore in Jaeger is a **flamegraph** based off the traces. Here we can compare the "before" and "after" flamegraphs: + +**Before:** + +![](makeDinner-jaeger-040-before) + +**After:** + +![](makeDinner-jaeger-041-after) + +By investigating flamegraphs, you are able to figure out the percentage of time spent and dominating certain functions. Our example was a fairly typical change, where we sped up the `chopVegetables` from taking 65% of the `makeDinner` execution, to just 43%. The flamegraph view can be useful in complex applications, in order to quickly locate which methods or services are taking the most time, and would be worth optimizing, as the span overview sometime can get pretty "busy" in a larger system, performing many calls. + +This was just a quick introduction to tracing, but hopefully you are now excited to learn more about tracing and using it to monitor and improve your server side Swift applications! In the following sections we'll discuss how to actually instrument your code, and how to make spans effective by including as much relevant information in them as possible. + +### Efficiently working with Spans + +We already saw the basic API to spawn a trace span, the ``withSpan(_:baggage:ofKind:at:function:file:line:_:)-4o2b`` method, but we didn't discuss it in depth yet. In this section we'll discuss how to efficiently work with spans and some common patterns and practices. + +Firstly, spans are created using a `withSpan` call and performing the operation contained within the span in the trailing operation closure body. This is important because it automatically, and correctly, delimits the lifetime of the span: from its creation, until the operation closure returns: + +```swift +withSpan("Working on my novel") { span in + write(.novel) +} + + +try await withSpan("Working on my exceptional novel") { span in + try await writeExceptional(.novel) +} +``` + +The `withSpan` is available both in synchronous and asynchronous contexts. The closure also is passed a `span` object which is a reference-semantics type that is mutable and `Sendable` that tracer implementations must provide. + +A `Span` is an in memory representation of the trace span that can be enriched with various information about this execution. For example, if the span represents an HTTP request, one would typically add **span attributes** for `http.method`, `http.path` etc. + +Throwing an error out of the withSpan's operation closure automatically records an error in the `span`, and ends the span. + +> Warning: A ``Span`` must not be ended multiple times and doing so is a programmer error. + +#### Span Attributes + +Span ``Span/attributes`` are additional information you can record in a ``Span`` which are then associated with the span and accessible in tracing visualization systems. + +While you are free to record any information you want in attributes, it usually is best to to stick to "well known" and standardized values, in order to make querying for them _across_ services more consistent. We will discuss pre-defined attributes below. + +Recording extra attributes in a Span is simple. You can record any information you want into the ``Span/attributes`` object using the subscript syntax, like this: + +```swift +withSpan("showAttributes") { span in + span.attributes["http.method"] = "POST" + span.attributes["http.status_code"] = 200 +} +``` + +Once the span is ``Span/end()``-ed the attributes are flushed along with it to the backend tracing system. + +> Tip: Some "well known" attributes are pre-defined for you in [swift-distributed-tracing-extras](https://github.com/apple/swift-distributed-tracing-extras). Or you may decide to define a number of type-safe attributes yourself. + +Attributes show up when you click on a specific ``Span`` in a trace visualization system. For example, like this in Jaeger: + +![Attributes show up under the Span in Jaeger](jaeger-attribute) + +Note that some attributes, like for example the information about the process emitting the trace are included in the span automatically. Refer to your tracer's documentation to learn more about how to configure what attributes it should include by default. Common things to include are hostnames, region information or other things which can identify the node in a cluster. + +#### Predefined type-safe Span Attributes + +The tracing API provides a way to declare and re-use well known span attributes in a type-safe way. Many of those are defined in `swift-distributed-tracing-extras`, and allow e.g. for setting HTTP values like this: + +For example, you can include the `TracingOpenTelemetrySemanticConventions` into your project like this: + +```swift +import PackageDescription + +let package = Package( + // ... + dependencies: [ + .package(url: "https://github.com/apple/swift-distributed-tracing.git", from: "..."), + .package(url: "https://github.com/apple/swift-distributed-tracing-extras.git", from: "..."), + ], + targets: [ + .target( + name: "MyTarget", + dependencies: [ + .product(name: "Tracing", package: "swift-distributed-tracing"), + .product(name: "TracingOpenTelemetrySemanticConventions", package: "swift-distributed-tracing-extras"), + ] + ), + // ... + ] +) +``` + +> Note: The extras library is versioned separately from the core tracing package, and at this point has not reached a source-stable 1.0 release yet. + +In order to gain a whole set of well-typed attributes which are pre-defined by the [OpenTelemetry](http://opentelemetry.io) initiative. + +For example, like these for HTTP: + +```swift +attributes.http.method = "GET" +attributes.http.url = "https://www.swift.org/download" +attributes.http.target = "/download" +attributes.http.host = "www.swift.org" +attributes.http.scheme = "https" +attributes.http.statusCode = 418 +attributes.http.flavor = "1.1" +attributes.http.userAgent = "test" +attributes.http.retryCount = 42 +``` + +or these, for database operations–which can be very useful to detect slow queries in your system: + +```swift +attributes.db.system = "postgresql" +attributes.db.connectionString = "test" +attributes.db.user = "swift" +attributes.db.statement = "SELECT name, display_lang FROM Users WHERE id={};" +``` + +Using such standardized attributes allows you, and other developers of other services you interact with, have a consistent and simple to search by attribute namespace. + +#### Declaring your own type-safe Span Attributes + +You can define your own type-safe span attributes, which is useful if your team or company has a certain set of attributes you like to set in all services; This way it is easier to remember what attributes one should be setting, and what their types should be, because the attributes pop up in your favorite IDE's autocompletion. + +Doing so requires some boilerplate, but you only have to do this once, and later on the use-sites of those attributes look quite neat (as you've seen above). Here is how you would declare a custom `http.method` nested attribute: + +```swift +extension SpanAttributes { + /// Semantic conventions for HTTP spans. + /// + /// OpenTelemetry Spec: [Semantic conventions for HTTP spans](https://github.com/open-telemetry/opentelemetry-specification/blob/v1.11.0/specification/trace/semantic_conventions/http.md#semantic-conventions-for-http-spans) + public var http: HTTPAttributes { + get { + .init(attributes: self) + } + set { + self = newValue.attributes + } + } +} +``` + +```swift +/// Semantic conventions for HTTP spans. +/// +/// OpenTelemetry Spec: [Semantic conventions for HTTP spans](https://github.com/open-telemetry/opentelemetry-specification/blob/v1.11.0/specification/trace/semantic_conventions/http.md#semantic-conventions-for-http-spans) +@dynamicMemberLookup +public struct HTTPAttributes: SpanAttributeNamespace { + public var attributes: SpanAttributes + + public init(attributes: SpanAttributes) { + self.attributes = attributes + } + + public struct NestedSpanAttributes: NestedSpanAttributesProtocol { + public init() {} + + /// HTTP request method. E.g. "GET". + public var method: Key { "http.method" } + } +} +``` + +### Span Events + +Events are similar to logs in the sense that they signal "something happened" during the execution of the ``Span``. + +> Note: There is a general tension between logs and trace events, as they can be used to achieve very similar outcomes. Consult the documentation of your tracing solution and how you'll be reading and investigating logs correlated to traces, and vice versa, and stick to a pattern that works best for your project. + +Events are recorded into a span like this: + +```swift +withSpan("showEvents") { span in + if cacheHit { + span.addEvent("cache-hit") + return cachedValue + } + + span.addEvent("cache-miss") + return computeValue() +} +``` + +An event is actually a value of the ``SpanEvent`` type, and carries along with it a ``SpanEvent/nanosecondsSinceEpoch`` as well as additional ``SpanEvent/attributes`` related to this specific event. In other words, if a ``Span`` represents an interval–something with a beginning and an end–a ``SpanEvent`` represents something that happened at a specific point-in-time during that span's execution. + +Events usually show up in a in a trace view as points on the timeline (note that some tracing systems are able to do exactly the same when a log statement includes a correlation trace and span ID in its metadata): + +**Jaeger:** + +![An event during the cook span](makeDinner-jaeger-event) + +**Zipkin:** + +![An event during the cook span](makeDinner-zipkin-event) + +Events cannot be "failed" or "successful", that is a property of a ``Span``, and they do not have anything that would be equivalent to a log level. When a trace span is recorded and collected, so will all events related to it. In that sense, events are different from log statements, because one can easily change a logger to include the "debug level" log statements, but technically no such concept exists for events (although you could simulate it with attributes). + +### Where (and how) do Baggage and Spans propagate? + +### Integrations + +#### Swift-log integration + +Swift-log, the logging package for the server ecosystem, offers native integration with task local values using the `Logger/MetadataProvider`, and its primary application is logging tracing metadata values. + +The snippet below shows how one can write a metadata provider and manually extract the baggage and associated metadata value to be included in log statements automatically: + +```swift +import Logging +import Tracing + +// Either manually extract "some specific tracer"'s context or such library would already provide it +let metadataProvider = Logger.MetadataProvider { + guard let baggage = Baggage.current else { + return [:] + } + guard let context = baggage.someSpecificTracerContext else { + return [:] + } + var metadata: Logger.Metadata = [:] + metadata["trace-id"] = "\(someSpecificTracerContext.traceID)" + metadata["span-id"] = "\(someSpecificTracerContext.spanID)" + return metadata +} + +LoggingSystem.bootstrap( + StreamLogHandler.standardOutput, + metadataProvider: metadataProvider) +``` + +Often times writing such provider by hand will not be necessary since the tracer library would be providing one for you. So you'd only need to remember to bootstrap the `LoggingSystem` with the specific tracer's metadata provider: + +``` +import Logging +import Tracing +import OpenTelemetry // https://github.com/slashmo/swift-otel + +LoggingSystem.bootstrap( + StreamLogHandler.standardOutput, + metadataProvider: .otel) // OTel library's metadata provider +``` + +A metadata provider will then be automatically invoked whenever log statements are to be emitted, and therefore e.g. such "bare" log statement: + +```swift +let log = Logger(label: "KitchenService") + +withSpan("cooking") { _ in + log.info("Cooking a meal") +} +``` + +would include the expected trace metadata: + +```bash +[info] trace_id:... span_id:... Cooking a meal +``` diff --git a/Sources/Tracing/Docs.docc/Images/jaeger-attribute.png b/Sources/Tracing/Docs.docc/Images/jaeger-attribute.png new file mode 100644 index 0000000..48dac7a Binary files /dev/null and b/Sources/Tracing/Docs.docc/Images/jaeger-attribute.png differ diff --git a/Sources/Tracing/Docs.docc/Images/makeDinner-jaeger-01.png b/Sources/Tracing/Docs.docc/Images/makeDinner-jaeger-01.png new file mode 100644 index 0000000..b5eed13 Binary files /dev/null and b/Sources/Tracing/Docs.docc/Images/makeDinner-jaeger-01.png differ diff --git a/Sources/Tracing/Docs.docc/Images/makeDinner-jaeger-02.png b/Sources/Tracing/Docs.docc/Images/makeDinner-jaeger-02.png new file mode 100644 index 0000000..ae9d430 Binary files /dev/null and b/Sources/Tracing/Docs.docc/Images/makeDinner-jaeger-02.png differ diff --git a/Sources/Tracing/Docs.docc/Images/makeDinner-jaeger-03.png b/Sources/Tracing/Docs.docc/Images/makeDinner-jaeger-03.png new file mode 100644 index 0000000..b3ad7f5 Binary files /dev/null and b/Sources/Tracing/Docs.docc/Images/makeDinner-jaeger-03.png differ diff --git a/Sources/Tracing/Docs.docc/Images/makeDinner-jaeger-040-before.png b/Sources/Tracing/Docs.docc/Images/makeDinner-jaeger-040-before.png new file mode 100644 index 0000000..554c908 Binary files /dev/null and b/Sources/Tracing/Docs.docc/Images/makeDinner-jaeger-040-before.png differ diff --git a/Sources/Tracing/Docs.docc/Images/makeDinner-jaeger-041-after.png b/Sources/Tracing/Docs.docc/Images/makeDinner-jaeger-041-after.png new file mode 100644 index 0000000..005682e Binary files /dev/null and b/Sources/Tracing/Docs.docc/Images/makeDinner-jaeger-041-after.png differ diff --git a/Sources/Tracing/Docs.docc/Images/makeDinner-jaeger-event.png b/Sources/Tracing/Docs.docc/Images/makeDinner-jaeger-event.png new file mode 100644 index 0000000..e3f2920 Binary files /dev/null and b/Sources/Tracing/Docs.docc/Images/makeDinner-jaeger-event.png differ diff --git a/Sources/Tracing/Docs.docc/Images/makeDinner-zipkin-01.png b/Sources/Tracing/Docs.docc/Images/makeDinner-zipkin-01.png new file mode 100644 index 0000000..fbfaad0 Binary files /dev/null and b/Sources/Tracing/Docs.docc/Images/makeDinner-zipkin-01.png differ diff --git a/Sources/Tracing/Docs.docc/Images/makeDinner-zipkin-02.png b/Sources/Tracing/Docs.docc/Images/makeDinner-zipkin-02.png new file mode 100644 index 0000000..16ebb2f Binary files /dev/null and b/Sources/Tracing/Docs.docc/Images/makeDinner-zipkin-02.png differ diff --git a/Sources/Tracing/Docs.docc/Images/makeDinner-zipkin-event.png b/Sources/Tracing/Docs.docc/Images/makeDinner-zipkin-event.png new file mode 100644 index 0000000..f6e1d5e Binary files /dev/null and b/Sources/Tracing/Docs.docc/Images/makeDinner-zipkin-event.png differ diff --git a/Sources/Tracing/Docs.docc/InDepthGuide.md b/Sources/Tracing/Docs.docc/InDepthGuide.md deleted file mode 100644 index 99d9ca6..0000000 --- a/Sources/Tracing/Docs.docc/InDepthGuide.md +++ /dev/null @@ -1,332 +0,0 @@ -# In-Depth Guide - -An in-depth guide on using the Distributed Tracing API. - -## Overview - -When instrumenting server applications there are typically three parties involved: - -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 - -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 are -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](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: any 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) (see ): - -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 (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. -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`` - -> ``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") -``` - diff --git a/Sources/Tracing/Docs.docc/LegacyTracer.md b/Sources/Tracing/Docs.docc/LegacyTracer.md new file mode 100644 index 0000000..eb70bbb --- /dev/null +++ b/Sources/Tracing/Docs.docc/LegacyTracer.md @@ -0,0 +1,7 @@ +# ``Tracing/LegacyTracer`` + +## Topics + +### Future-proof Tracer API + +- ``Tracer`` diff --git a/Sources/Tracing/Docs.docc/Tracer.md b/Sources/Tracing/Docs.docc/Tracer.md new file mode 100644 index 0000000..32eef33 --- /dev/null +++ b/Sources/Tracing/Docs.docc/Tracer.md @@ -0,0 +1,12 @@ +# ``Tracing/Tracer`` + +## Topics + +### Creating Spans + +- ``withSpan(_:baggage:ofKind:at:function:file:line:_:)-4o2b`` + +### Manual Span management + +- ``startSpan(_:baggage:ofKind:at:function:file:line:)-u1y4`` +- ``Span/end()`` diff --git a/Sources/Tracing/Docs.docc/index.md b/Sources/Tracing/Docs.docc/index.md index f541c06..26c6136 100644 --- a/Sources/Tracing/Docs.docc/index.md +++ b/Sources/Tracing/Docs.docc/index.md @@ -6,199 +6,23 @@ A Distributed Tracing API for Swift. This is a collection of Swift libraries enabling the instrumentation of server side applications using tools such as tracers. Our goal is to provide a common foundation that allows to freely choose how to instrument systems with minimal changes to your actual code. -While Swift Distributed Tracing allows building all kinds of _instruments_, which can co-exist in applications transparently, its primary use is instrumenting multi-threaded and distributed systems with Distributed Traces. +While Swift Distributed Tracing allows building all kinds of _instruments_, which can co-exist in applications transparently, its primary use is instrumenting multithreaded and distributed systems with _distributed traces_. +### Quickstart Guides ---- +We provide a number of guides aimed at getting started with tracing your systems, and have prepared them from three "angles": -This project uses the context progagation type defined independently in: +1. , for **Application developers** who create server-side applications, +2. , for **Library/Framework developers** who provide building blocks to create these applications, +3. , for **Instrument developers** who provide tools to collect distributed metadata about your application. -- 🧳 [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) - -## 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 (?) | ... | - -## 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 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 (). - -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 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) { - 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](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() -} -``` +If unsure where to start, we recommend starting at the first guide and continue reading until satisfied, +as the subsequent guides dive deeper into patterns and details of instrumenting systems and building instruments yourself. ## Topics -### Articles +### Guides -- +- +- +- diff --git a/Sources/Tracing/SpanProtocol.swift b/Sources/Tracing/SpanProtocol.swift index b8feb1d..4bc995c 100644 --- a/Sources/Tracing/SpanProtocol.swift +++ b/Sources/Tracing/SpanProtocol.swift @@ -15,10 +15,13 @@ @_exported import InstrumentationBaggage /// A `Span` represents an interval from the start of an operation to its end, along with additional metadata included -/// with it. A `Span` can be created from a `Baggage` or `LoggingContext` which MAY contain existing span identifiers, +/// 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. +/// Spans are created by invoking the `withSpan`` method which delegates to the currently configured bootstrapped +/// tracer.By default the task-local "current" `Baggage` is used to perform this association. /// /// ### Reference semantics /// A `Span` always exhibits reference semantics. Even if a span were to be implemented using a struct (or enum), @@ -52,12 +55,20 @@ public protocol Span: _SwiftTracingSendableSpan { nonmutating set } - /// Set the status. + /// Set the status of the span. /// /// - Parameter status: The status of this `Span`. func setStatus(_ status: SpanStatus) - /// Add a ``SpanEvent`` in place. + /// Add a ``SpanEvent`` to this span. + /// + /// Span events are similar to log statements in logging systems, in the sense + /// that they can carry a name of some event that has happened as well as an associated timestamp. + /// + /// Events can be used to complement a span with "interesting" point-in-time information. + /// For example if code executing a span has been cancelled it might be useful interesting + /// to emit an event representing this task cancellation, which then (presumably) leads + /// to an quicker termination of the task. /// /// - Parameter event: The ``SpanEvent`` to add to this `Span`. func addEvent(_ event: SpanEvent) @@ -629,7 +640,9 @@ extension SpanAttributes: ExpressibleByDictionaryLiteral { // ==== ---------------------------------------------------------------------------------------------------------------- // MARK: Span Status -/// Represents the status of a finished Span. It's composed of a status code in conjunction with an optional descriptive message. +/// Represents the status of a finished Span. +/// +/// It's composed of a status code in conjunction with an optional descriptive message. public struct SpanStatus: Equatable { public let code: Code public let message: String? diff --git a/Sources/Tracing/Tracer.swift b/Sources/Tracing/Tracer.swift index 31a5f95..c2a2ac1 100644 --- a/Sources/Tracing/Tracer.swift +++ b/Sources/Tracing/Tracer.swift @@ -24,7 +24,7 @@ import Dispatch /// we're about to start a top-level span, or if a span should be started from a different, /// stored away previously, /// -/// - Note: Prefer ``withSpan(_:baggage:ofKind:at:function:file:line:operation:)`` to start +/// - Note: Prefer ``withSpan(_:baggage:ofKind:at:function:file:line:_:)-4o2b`` to start /// a span as it automatically takes care of ending the span, and recording errors when thrown. /// Use `startSpan` iff you need to pass the span manually to a different /// location in your source code to end it. @@ -71,7 +71,7 @@ public func startSpan( /// we're about to start a top-level span, or if a span should be started from a different, /// stored away previously, /// -/// - Note: Prefer ``withSpan(_:baggage:ofKind:at:function:file:line:operation:)`` to start +/// - Note: Prefer ``withSpan(_:baggage:ofKind:at:function:file:line:_:)-4o2b`` to start /// a span as it automatically takes care of ending the span, and recording errors when thrown. /// Use `startSpan` iff you need to pass the span manually to a different /// location in your source code to end it. @@ -117,7 +117,7 @@ public func startSpan( /// we're about to start a top-level span, or if a span should be started from a different, /// stored away previously, /// -/// - Note: Prefer ``withSpan(_:baggage:ofKind:at:function:file:line:operation:)`` to start +/// - Note: Prefer ``withSpan(_:baggage:ofKind:at:function:file:line:_:)-4o2b`` to start /// a span as it automatically takes care of ending the span, and recording errors when thrown. /// Use `startSpan` iff you need to pass the span manually to a different /// location in your source code to end it. diff --git a/Sources/Tracing/TracerProtocol+Legacy.swift b/Sources/Tracing/TracerProtocol+Legacy.swift index 5cae8dd..13361b0 100644 --- a/Sources/Tracing/TracerProtocol+Legacy.swift +++ b/Sources/Tracing/TracerProtocol+Legacy.swift @@ -16,6 +16,14 @@ import Dispatch @_exported import Instrumentation @_exported import InstrumentationBaggage +/// A tracer protocol intended to support Swift 5.6 specifically. +/// +/// **This protocol will be deprecated as soon as possible**, and the library will continue recommending Swift 5.7+ +/// in order to make use of new language features that make expressing the tracing API free of existential types when not necessary. +/// +/// When possible, prefer using ``Tracer`` and ``withSpan(_:baggage:ofKind:at:function:file:line:_:)-4o2b`` APIs, +/// rather than these `startAnySpan` APIs which unconditionally always return existential Spans even when not necessary +/// (under Swift 5.7+ type-system enhancement wrt. protocols with associated types).. @available(macOS 10.15, iOS 13, tvOS 13, watchOS 6, *) // for TaskLocal Baggage public protocol LegacyTracer: Instrument { /// Start a new span returning an existential ``Span`` reference. @@ -30,7 +38,7 @@ public protocol LegacyTracer: Instrument { /// /// - Note: Legacy API, prefer using ``startSpan(_:baggage:ofKind:at: /// - /// - Note: Prefer ``withSpan(_:baggage:ofKind:at:function:file:line:operation:)`` to start + /// - Note: Prefer ``withSpan(_:baggage:ofKind:at:function:file:line:_:)-4o2b`` to start /// a span as it automatically takes care of ending the span, and recording errors when thrown. /// Use `startSpan` iff you need to pass the span manually to a different /// location in your source code to end it. @@ -84,7 +92,7 @@ extension LegacyTracer { /// /// - Note: Legacy API, prefer using ``startSpan(_:baggage:ofKind:at: /// - /// - Note: Prefer ``withSpan(_:baggage:ofKind:at:function:file:line:operation:)`` to start + /// - Note: Prefer ``withSpan(_:baggage:ofKind:at:function:file:line:_:)-4o2b`` to start /// a span as it automatically takes care of ending the span, and recording errors when thrown. /// Use `startSpan` iff you need to pass the span manually to a different /// location in your source code to end it. @@ -133,7 +141,7 @@ extension LegacyTracer { /// /// - Note: Legacy API, prefer using ``startSpan(_:baggage:ofKind:at: /// - /// - Note: Prefer ``withSpan(_:baggage:ofKind:at:function:file:line:operation:)`` to start + /// - Note: Prefer ``withSpan(_:baggage:ofKind:at:function:file:line:_:)-4o2b`` to start /// a span as it automatically takes care of ending the span, and recording errors when thrown. /// Use `startSpan` iff you need to pass the span manually to a different /// location in your source code to end it. @@ -393,7 +401,7 @@ extension Tracer { /// /// - Note: Legacy API, prefer using ``startSpan(_:baggage:ofKind:at: /// - /// - Note: Prefer ``withSpan(_:baggage:ofKind:at:function:file:line:operation:)`` to start + /// - Note: Prefer ``withSpan(_:baggage:ofKind:at:function:file:line:_:)-4o2b`` to start /// a span as it automatically takes care of ending the span, and recording errors when thrown. /// Use `startSpan` iff you need to pass the span manually to a different /// location in your source code to end it. @@ -442,7 +450,7 @@ extension Tracer { /// /// - Note: Legacy API, prefer using ``startSpan(_:baggage:ofKind:at: /// - /// - Note: Prefer ``withSpan(_:baggage:ofKind:at:function:file:line:operation:)`` to start + /// - Note: Prefer ``withSpan(_:baggage:ofKind:at:function:file:line:_:)-4o2b`` to start /// a span as it automatically takes care of ending the span, and recording errors when thrown. /// Use `startSpan` iff you need to pass the span manually to a different /// location in your source code to end it. @@ -497,7 +505,7 @@ extension Tracer { /// /// - Note: Legacy API, prefer using ``startSpan(_:baggage:ofKind:at: /// - /// - Note: Prefer ``withSpan(_:baggage:ofKind:at:function:file:line:operation:)`` to start + /// - Note: Prefer ``withSpan(_:baggage:ofKind:at:function:file:line:_:)-4o2b`` to start /// a span as it automatically takes care of ending the span, and recording errors when thrown. /// Use `startSpan` iff you need to pass the span manually to a different /// location in your source code to end it. diff --git a/Sources/Tracing/TracerProtocol.swift b/Sources/Tracing/TracerProtocol.swift index f4d5c24..4e88341 100644 --- a/Sources/Tracing/TracerProtocol.swift +++ b/Sources/Tracing/TracerProtocol.swift @@ -36,7 +36,7 @@ public protocol Tracer: LegacyTracer { /// we're about to start a top-level span, or if a span should be started from a different, /// stored away previously, /// - /// - Note: Prefer ``withSpan(_:baggage:ofKind:at:function:file:line:operation:)`` to start + /// - Note: Prefer ``withSpan(_:baggage:ofKind:at:function:file:line:_:)-4o2b`` to start /// a span as it automatically takes care of ending the span, and recording errors when thrown. /// Use `startSpan` iff you need to pass the span manually to a different /// location in your source code to end it. @@ -73,7 +73,7 @@ extension Tracer { /// we're about to start a top-level span, or if a span should be started from a different, /// stored away previously, /// - /// - Note: Prefer ``withSpan(_:baggage:ofKind:at:function:file:line:operation:)`` to start + /// - Note: Prefer ``withSpan(_:baggage:ofKind:at:function:file:line:_:)-4o2b`` to start /// a span as it automatically takes care of ending the span, and recording errors when thrown. /// Use `startSpan` iff you need to pass the span manually to a different /// location in your source code to end it. diff --git a/Tests/TracingTests/SpanTests.swift b/Tests/TracingTests/SpanTests.swift index 4d46e35..598f48b 100644 --- a/Tests/TracingTests/SpanTests.swift +++ b/Tests/TracingTests/SpanTests.swift @@ -12,7 +12,7 @@ // //===----------------------------------------------------------------------===// -import Instrumentation +@testable import Instrumentation import InstrumentationBaggage import Tracing import XCTest @@ -89,6 +89,20 @@ final class SpanTests: XCTestCase { s.attributes["hi"] = [1, 2, 34] } + func testSpanAttributeSetEntireCollection() { + InstrumentationSystem.bootstrapInternal(TestTracer()) + defer { + InstrumentationSystem.bootstrapInternal(NoOpTracer()) + } + + let s = InstrumentationSystem.legacyTracer.startAnySpan("", baggage: .topLevel) + var attrs = s.attributes + attrs["one"] = 42 + attrs["two"] = [1, 2, 34] + s.attributes = attrs + XCTAssertEqual(s.attributes["one"]?.toSpanAttribute(), SpanAttribute.int(42)) + } + func testSpanAttributesUX() { var attributes: SpanAttributes = [:] diff --git a/scripts/preview_docc.sh b/scripts/docs/preview_docc.sh similarity index 85% rename from scripts/preview_docc.sh rename to scripts/docs/preview_docc.sh index eca74c6..289203f 100755 --- a/scripts/preview_docc.sh +++ b/scripts/docs/preview_docc.sh @@ -3,7 +3,7 @@ ## ## This source file is part of the Swift Distributed Tracing open source project ## -## Copyright (c) 2022 Apple Inc. and the Swift Distributed Tracing project +## Copyright (c) 2020-2023 Apple Inc. and the Swift Distributed Tracing project ## authors ## Licensed under Apache License v2.0 ## @@ -12,7 +12,6 @@ ## SPDX-License-Identifier: Apache-2.0 ## ##===----------------------------------------------------------------------===## - ##===----------------------------------------------------------------------===## ## ## This source file is part of the Swift Distributed Actors open source project @@ -27,4 +26,4 @@ ## ##===----------------------------------------------------------------------===## -swift package --disable-sandbox preview-documentation --target $1 +xcrun swift package --disable-sandbox preview-documentation --target Tracing