# Motivation
This PR supersedes https://github.com/apple/swift-metrics/pull/135. The
goal is to make it easier to measure asynchronous code when using
`Metrics`.
# Modification
This PR does:
- Deprecate the current static method for measuring synchronous code
- Add a new instance method to measure synchronous code
- Add a new instance method to measure asynchronous code
# Motivation
Most of the server ecosystem follows the supported Swift versions from `swift-nio`. This means supporting the latest 3 Swift releases.
# Modification
This PR drops support for all Swift versions before 5.8.
# Result
This makes maintaining this repository easier and allows us to clean up some no longer needed stuff.
Motivation:
`Duration` is available starting Swift 5.7, and we
should probably support it in our convinience API.
Modifications:
- Timer.record(_ duration: Duration) implementation
- A unit test case
- Generated Linux tests
motivation: expose increment and decrement public APIs
changes:
* add increment and decrement public API to Meter
* improve the implementation of AccumulatingMeter and TestMeter
* add tests for new APIs
* refactor/modernize other tests
motivation: It is not currently possible to record floating point values via the swift-metrics API even if the metrics backend supports it.
modifications: Adds a `FloatingPointCounter` type to allow users to accumulate non-integral metrics backed by a `FloatingPointCounterHandler`. Introduces a default implementation for creating and destroying `FloatingPointCounterHandler`s for metric backends that do not natively support floating point counters. On such backends, `FloatingPointCounter` is backed by a `AccumulatingRoundingFloatingPointCounter` which accumulates floating point values internally and record increments to a wrapped `CounterHandler` after crossing integer boundaries.
result: Users can create `FloatingPointCounter`s to record floating point values and get enhanced behavior for backends that support floating point values.
Motivation:
I have a metrics backend where I need to store timer values in
microseconds. The "preferred display unit" models this exactly, but it
seems to have (inadvertently?) omitted the possibility to express
microseconds. Note that among the timer "report" methods there is
already a microseconds option.
Changes:
* change TimeUnit from enum to struct with static members to support non-api breaking future evolution
* add scaleFromNanoseconds to TimeUnit to make it easy to compute the values without switching over
* add tests
Co-authored-by: Chris Burrows <cburrows@gmail.com>
motivation: some metrics backend prefer to be given a hint about the preferred display unit (seconds, milliseconds, etc) to drive the ux
changes: add a `preferedUnit` to TimerHandler (and `TimeUnits`) to capture the prefer display unit
* prepare to release
motivation: the sswg voted to adopt the API. this is to prepare to a release
changes:
* rewrite readme
* add API docs
* add utilitiy scripts and docker setup for CI
* adjust linux tests
motivation: after much discussion around logging API, we settled on a different API style, primairly the fact that we will use initializers instead of factories
changes:
* introduce intermediate classes for Counter, Timer and Recorder which are designed to replace the Metrics.makeCounter, Metrics.makeTimer and Metrics.makeRecorder APIs and wrap corresponding CounterHandler, TimerHandler and ReorderHandler coming from the metrics implmentation
* rename Metrics to MetricsSystem
* rename MetricsHandler -> MetricsFactory
* remove Metrics.withCounter, Metrics.withTimer and Metrics.withRecorder syntactic sugar
* rename Metrics.timed with Timer.measure
* make sure metrics system can only be initialized/bootstrapped once per process
* adjust and add tests
* add a bit of docs on key APIs
Franz Busch
Rick Newton-Rogers
Gustavo Cairo
hamzahrmalik
Franz Busch
Natik Gadzhi
tomer doron
hamzahrmalik
Fabian Fett
Rauhul Varma
Moritz Lang
Jari (LotU)
tomer doron