Swiftpack.co - Package - apple/swift-log

SwiftLog

A Logging API package for Swift. Version 1.0.0 requires Swift 5.0 but there is a version 0.x.y series available for Swift 4 to ease your transition towards Swift 5. If you intend to use or support SwiftLog for Swift 4, please check the paragraph at the end of the document.

First things first: This is the beginning of a community-driven open-source project actively seeking contributions, be it code, documentation, or ideas. Apart from contributing to SwiftLog itself, there's another huge gap at the moment: SwiftLog is an API package which tries to establish a common API the ecosystem can use. To make logging really work for real-world workloads, we need SwiftLog-compatible logging backends which then either persist the log messages in files, render them in nicer colors on the terminal, or send them over to Splunk or ELK.

What SwiftLog provides today can be found in the API docs.

Getting started

If you have a server-side Swift application, or maybe a cross-platform (for example Linux & macOS) app/library, and you would like to log, we think targeting this logging API package is a great idea. Below you'll find all you need to know to get started.

Adding the dependency

SwiftLog is designed for Swift 5, the 1.0.0 release requires Swift 5 (however we will soon tag a 0.x version that will work with Swift 4 for the transition period). To depend on the logging API package, you need to declare your dependency in your Package.swift:

.package(url: "https://github.com/apple/swift-log.git", from: "1.0.0"),

and to your application/library target, add "Logging" to your dependencies, e.g. like this:

.target(name: "BestExampleApp", dependencies: ["Logging"]),

Let's log

// 1) let's import the logging API package
import Logging

// 2) we need to create a logger, the label works similarly to a DispatchQueue label
let logger = Logger(label: "com.example.BestExampleApp.main")

// 3) we're now ready to use it
logger.info("Hello World!")

Output

2019-03-13T15:46:38+0000 info: Hello World!

Default Logger behavior

SwiftLog provides for very basic console logging out-of-the-box by way of StreamLogHandler. It is possible to switch the default output to stderr like so:

LoggingSystem.bootstrap(StreamLogHandler.standardError)

StreamLogHandler is primarily a convenience only and does not provide any substantial customization. Library maintainers who aim to build their own logging backends for integration and consumption should implement the LogHandler protocol directly as laid out in the "On the implementation of a logging backend" section.

For further information, please check the API documentation.

Selecting a logging backend implementation (applications only)

As the API has just launched, not many implementations exist yet. If you are interested in implementing one see the "Implementation considerations" section below explaining how to do so. List of existing SwiftLog API compatible libraries:

| Repository | Handler Description| | ----------- | ----------- | | IBM-Swift/HeliumLogger |a logging backend widely used in the Kitura ecosystem | | ianpartridge/swift-log-syslog | a syslog backend| | Adorkable/swift-log-format-and-pipe | a backend that allows customization of the output format and the resulting destination | | chrisaljoudi/swift-log-oslog | an OSLog Unified Logging backend for use on Apple platforms. Important Note: we recommend using os_log directly as decribed here. Using os_log through swift-log using this backend will be less efficient and will also prevent specifying the privacy of the message. The backend always uses %{public}@ as the format string and eagerly converts all string interpolations to strings. This has two drawbacks: 1. the static components of the string interpolation would be eagerly copied by the unified logging system, which will result in loss of performance. 2. It makes all messages public, which changes the default privacy policy of os_log, and doesn't allow specifying fine-grained privacy of sections of the message. In a separate on-going work, Swift APIs for os_log are being improved and made to align closely with swift-log APIs. References: Unifying Logging Levels, Making os_log accept string interpolations using compile-time interpretation. | | Brainfinance/StackdriverLogging | a structured JSON logging backend for use on Google Cloud Platform with the Stackdriver logging agent | | DnV1eX/GoogleCloudLogging | a client-side library for logging application events in Google Cloud via REST API v2. | | vapor/console-kit | print log messages to a terminal with stylized (ANSI) output | | neallester/swift-log-testing | provides access to log messages for use in assertions (within test targets) | | wlisac/swift-log-slack | a logging backend that sends critical log messages to Slack | | NSHipster/swift-log-github-actions | a logging backend that translates logging messages into workflow commands for GitHub Actions. | | stevapple/swift-log-telegram | a logging backend that sends log messages to any Telegram chat (Inspired by and forked from wlisac/swift-log-slack) | | jagreenwood/swift-log-datadog | a logging backend which sends log messages to the Datadog log management service | | google/SwiftLogFireCloud | a logging backend for time series logging which pushes logs as flat files to Firebase Cloud Storage. | | Your library? | Get in touch! |

What is an API package?

Glad you asked. We believe that for the Swift on Server ecosystem, it's crucial to have a logging API that can be adopted by anybody so a multitude of libraries from different parties can all log to a shared destination. More concretely this means that we believe all the log messages from all libraries end up in the same file, database, Elastic Stack/Splunk instance, or whatever you may choose.

In the real-world however, there are so many opinions over how exactly a logging system should behave, what a log message should be formatted like, and where/how it should be persisted. We think it's not feasible to wait for one logging package to support everything that a specific deployment needs whilst still being easy enough to use and remain performant. That's why we decided to cut the problem in half:

  1. a logging API
  2. a logging backend implementation

This package only provides the logging API itself and therefore SwiftLog is a 'logging API package'. SwiftLog (using LoggingSystem.bootstrap) can be configured to choose any compatible logging backend implementation. This way packages can adopt the API and the application can choose any compatible logging backend implementation without requiring any changes from any of the libraries.

Just for completeness sake: This API package does actually include an overly simplistic and non-configurable logging backend implementation which simply writes all log messages to stdout. The reason to include this overly simplistic logging backend implementation is to improve the first-time usage experience. Let's assume you start a project and try out SwiftLog for the first time, it's just a whole lot better to see something you logged appear on stdout in a simplistic format rather than nothing happening at all. For any real-world application, we advise configuring another logging backend implementation that logs in the style you like.

The core concepts

Loggers

Loggers are used to emit log messages and therefore the most important type in SwiftLog, so their use should be as simple as possible. Most commonly, they are used to emit log messages in a certain log level. For example:

// logging an informational message
logger.info("Hello World!")

// ouch, something went wrong
logger.error("Houston, we have a problem: \(problem)")

Log levels

The following log levels are supported:

  • trace
  • debug
  • info
  • notice
  • warning
  • error
  • critical

The log level of a given logger can be changed, but the change will only affect the specific logger you changed it on. You could say the Logger is a value type regarding the log level.

Logging metadata

Logging metadata is metadata that can be attached to loggers to add information that is crucial when debugging a problem. In servers, the usual example is attaching a request UUID to a logger that will then be present on all log messages logged with that logger. Example:

var logger = logger
logger[metadataKey: "request-uuid"] = "\(UUID())"
logger.info("hello world")

will print

2019-03-13T18:30:02+0000 info: request-uuid=F8633013-3DD8-481C-9256-B296E43443ED hello world

with the default logging backend implementation that ships with SwiftLog. Needless to say, the format is fully defined by the logging backend you choose.

On the implementation of a logging backend (a LogHandler)

Note: If you don't want to implement a custom logging backend, everything in this section is probably not very relevant, so please feel free to skip.

To become a compatible logging backend that all SwiftLog consumers can use, you need to do two things: 1) Implement a type (usually a struct) that implements LogHandler, a protocol provided by SwiftLog and 2) instruct SwiftLog to use your logging backend implementation.

A LogHandler or logging backend implementation is anything that conforms to the following protocol

public protocol LogHandler {
    func log(level: Logger.Level, message: Logger.Message, metadata: Logger.Metadata?, file: String, function: String, line: UInt)

    subscript(metadataKey _: String) -> Logger.Metadata.Value? { get set }

    var metadata: Logger.Metadata { get set }

    var logLevel: Logger.Level { get set }
}

Instructing SwiftLog to use your logging backend as the one the whole application (including all libraries) should use is very simple:

LoggingSystem.bootstrap(MyLogHandler.init)

Implementation considerations

LogHandlers control most parts of the logging system:

Under control of a LogHandler

Configuration

LogHandlers control the two crucial pieces of Logger configuration, namely:

  • log level (logger.logLevel property)
  • logging metadata (logger[metadataKey:] and logger.metadata)

For the system to work, however, it is important that LogHandler treat the configuration as value types. This means that LogHandlers should be structs and a change in log level or logging metadata should only affect the very LogHandler it was changed on.

However, in special cases, it is acceptable that a LogHandler provides some global log level override that may affect all LogHandlers created.

Emitting
  • emitting the log message itself

Not under control of LogHandlers

LogHandlers do not control if a message should be logged or not. Logger will only invoke the log function of a LogHandler if Logger determines that a log message should be emitted given the configured log level.

Source vs Label

A Logger carries an (immutable) label and each log message carries a source parameter (since SwiftLog 1.3.0). The Logger's label identifies the creator of the Logger. If you are using structured logging by preserving metadata across multiple modules, the Logger's label is not a good way to identify where a log message originated from as it identifies the creator of a Logger which is often passed around between libraries to preserve metadata and the like.

If you want to filter all log messages originating from a certain subsystem, filter by source which defaults to the module that is emitting the log message.

SwiftLog for Swift 4

First of, SwiftLog 1.0.x and SwiftLog 0.0.x are mostly compatible so don't be afraid. In fact, SwiftLog 0.0.0 is the same source code as SwiftLog 1.0.0 with a few changes made to make it Swift 4 compatible.

How can I use SwiftLog 0 library or application?

If you have a application or a library that needs to be compatible with both Swift 4 and 5, then we recommend using the following in your Package.swift:

.package(url: "https://github.com/apple/swift-log.git", Version("0.0.0") ..< Version("2.0.0")),

This will instruct SwiftPM to allow any SwiftLog 0 and any SwiftLog 1 version. This is an unusual form because usually packages don't support multiple major versions of a package. Because SwiftLog 0 and 1 are mostly compatible however, this should not be a real issue and will enable everybody to get the best. If compiled with a Swift 4 compiler, this will be a SwiftLog 0 version but if compiled with a Swift 5 compiler everybody will get the best experience and performance delivered by SwiftLog 1.

In most cases, there is only one thing you need to remember: Always use string literals and string interpolations in the log methods and don't rely on the fact that SwiftLog 0 also allows String.

Good:

logger.info("hello world")

Bad:

let message = "hello world"
logger.info(message)

If you have a String that you received from elsewhere, please use

logger.info("\(stringIAlreadyHave)")

For more details, have a look in the next section.

What are the differences between SwiftLog 1 and 0?

  • SwiftLog 0 does not use @inlinable.
  • Apart from accepting Logger.Message for the message, SwiftLog 0 has a String overload.
  • In SwiftLog 0, Logger.Message is not ExpressibleByStringLiteral or ExpressibleByStringInterpolation.
  • In SwiftLog 0, Logger.MetadataValue is not ExpressibleByStringLiteral or ExpressibleByStringInterpolation.

Why these differences?

@inlinable

Swift 4.0 & 4.1 don't support @inlinable, so SwiftLog 0 can't use them.

Logger.Message

Because all Swift 4 versions don't have a (non-deprecated) mechanism for a type to be ExpressibleByStringInterpolation we couldn't make Logger.Message expressible by string literals. Unfortunately, the most basic form of our logging API is logger.info("Hello \(world)"). For this to work however, "Hello \(world)" needs to be accepted and because we can't make Logger.Message ExpressibleByStringInterpolation we added an overload for all the logging methods to also accept String. In most cases, you won't even notice that with SwiftLog 0 you're creating a String (which is then transformed to a Logger.Message) and with SwiftLog 1 you're creating a Logger.Message directly. That is because both String and Logger.Message will accept all forms of string literals and string interpolations. Unfortunately, there is code that will make this seemingly small difference visible. If you write

let message = "Hello world"
logger.info(message)

then this will only work in SwiftLog 0 and not in SwiftLog 1. Why? Because SwiftLog 1 will want a Logger.Message but let message = "Hello world" will make message to be of type String and in SwiftLog 1, the logging methods don't accept Strings.

So if you intend to be compatible with SwiftLog 0 and 1 at the same time, please make sure to always use a string literal or a string interpolation inside of the logging methods.

In the case that you already have a String handy that you want to log, don't worry at all, just use

let message = "Hello world"
logger.info("\(message)")

and again, you will be okay with SwiftLog 0 and 1.

Design

This logging API was designed with the contributors to the Swift on Server community and approved by the SSWG (Swift Server Work Group) to the 'sandbox level' of the SSWG's incubation process.

Github

link
Stars: 2040

Dependencies

Used By

Total: 0

Releases

SwiftLog 1.4.0 - 2020-07-16 02:06:49

Highlights

This release addresses a missing public init in the newly introduced NoOpLogHandler. Please use 1.4.0 rather than 1.3.0 to be able to actually instantiate the that handler.

SemVer Minor

  • Add public init to NoOpLogHandler introduced in 1.3.0 https://github.com/apple/swift-log/pull/142

Credits

This release contains a single PR: https://github.com/apple/swift-log/pull/146

The complete change-list is available on the 1.4.0 milestone.

Thank you @adam-fowler for spotting and fixing the mistake!

SwiftLog 1.3.0 - 2020-07-07 03:44:44

Highlights

LogHandler implementations should take care adjust their implementations moving forward to implement the following log function:

func log(
    level: Logging.Logger.Level, 
    message: Logging.Logger.Message, 
    metadata: Logging.Logger.Metadata?, 
    source: String, // new (!)
    file: String, function: String, line: UInt
)

rather than the previous function:

func log(
    level: Logging.Logger.Level, 
    message: Logging.Logger.Message, 
    metadata: Logging.Logger.Metadata?, 
    file: String, function: String, line: UInt
)

Compatibility shims are provided and existing implementations will continue to work as-is. However in order to reap benefits of the new source (which will contain the "module name from which this log message originates") parameter, they will have to change which log overload they implement. We suggest moving to implementing the new overload (with source:) as soon as possible, allowing the logging ecosystem to make use of this new capability.

For details see:

  • Add "source" for log messages https://github.com/apple/swift-log/pull/135

SemVer Minor

  • Add "source" for log messages https://github.com/apple/swift-log/pull/135
  • Add NoOpLogHandler for when you don't want logging https://github.com/apple/swift-log/pull/142
  • Logging: port to Windows https://github.com/apple/swift-log/pull/118
  • =multiplex #139 more properly handle logLevel in multiplex handler https://github.com/apple/swift-log/pull/140
    • Note that previous behavior of the MultiplexLogHandler was very surprising and this change makes it more consistent, see the PR for details if you are using multiplex handlers

SemVer Patch

  • silence #file to #filePath warnings https://github.com/apple/swift-log/pull/133
  • a number of readme and docs improvements:
    • docs: =doc #82 avoid showcasing internal lock in public docs https://github.com/apple/swift-log/pull/144
    • Fix doc typo #134
    • Add more syntax highlighting to the readme file #114
  • and more, see the 1.3.0 milestone for all closed issues.

Credits

This release includes 15 issues/PRs, which were made possible with the help of 18 contributors 🎉

We would like to thank all everyone for their feedback and contributions:

Tomer Doron, Johannes Weiss, Konrad ktoso Malawski, Saleem Abdulrasool, Gwynne Raskind, prafsoni, Adam Fowler, Neal Lester, Artur Dryomov, Franz Busch, Shiva Huang, zach wick, Ravi Kandhadai, YR Chen, Jeremy Greenwood, Will Lisac, Mattt, Tanner

Thank you!

SwiftLog 1.2.0 - 2019-11-04 11:10:56

SemVer Major

  • Make log levels codable (#99)

SemVer Minor

  • docs: remove level parameter from log helpers (#91)
  • list more logging backends in readme (#95, #92, #88)

SwiftLog 1.1.1 - 2019-08-20 12:45:08

SemVer Patch

  • add flush api to default stdout/stderr logger (#87)
  • Fix typo in LogHandler doc comment (#76)
  • Link to ianpartridge/swift-log-syslog backend impl (#73)
  • Fix documented ordering of Level (#78)
  • Add Adorkable/swift-log-format-and-pipe to Backend list (#83)
  • test formatting issues as part of sanity check (#84)
  • better documentation around MetadataValue being expressible by literal
  • Add HeliumLogger to README (#88)

SwiftLog 1.1.0 - 2019-05-17 13:03:34

SemVer Minor

  • Expose an API for configuring basic stdio log handling (#61)
  • Added CaseIterable to Logger.Level enum (#46)

SemVer Patch

  • Add internal section link to README.md (#71)
  • add a CocoaPods podspec generator (#54)
  • Update README.md
  • explain the upcoming SwiftLog 0 (#69)
  • changed to isEmpty. (#65)
  • docs: improve API documentation coverage (#67)
  • Fix API documentation (#66)
  • Add 'Show on GitHub' link to API docs (#64)
  • add git commit template (#62)
  • fix docs #file -> #function (#59)
  • Fixed typo. (#58)
  • add contribution guidelines and github default config (#55)
  • fix linux tests formatting (#45)
  • fix docker setup to use release version of swift 5 (#48)
  • Link to more appropriate (still open) Swift issue (#50)
  • Fix typo in "critical" words in docs (#49)
  • retain SwiftNIO copyright header (#44)
  • readme: fix log levels (#43)
  • fix typo in API docs (#42)
  • use consistent, swifty naming convention (#41)

swift-log 1.0.0 - 2019-04-10 15:53:24

The initial release.