motivation: adjust to swift 5.6
changes:
* define sendable shims for protocols and structs that may be used in async context
* refactor Gauge to include rather than inherit Recorder
* adjust tests
* add a test to make sure no warning are emitted
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
motivation: allow middleware libraries better control of metric object lifecycle to reduce potential memory footprint when using metrics libraries that use some kind of registry or cache (eg polling backends)
changes:
* Introduce metric.destroy() to enable lifecycle management
* Add destroy functions to example impl in readme
* rename Counter::increment "value" parameter to "by"
motivation: nicer API signature
changes: rename Counter::increment and CounterHandler::increment "value" parameter to "by"
motivation: it's very beneficial for the protocols to use functions with concrete types because then there's no need for specialisation. At compile time, the compiler can often not know what concrete type will be used so it needs to create a 'generic at runtime' version of the function. If however all functions on the protocol do not use generics, there's no need for a 'generic at runtime' version of the function
changes:
* change CounterHandler::increment to take Int64 instead of <DataType: BinaryInteger>
* change RecorderHandler::record to take Int64 and Double instead of <DataType: BinaryInteger> and <DataType: BinaryFloatingPoint>
* adjust example and test implementation
* adjust docs
motivation: address feedback from community, prepare for moving api to official repo
changes:
* add reset method to counter
* do not force the user facing metric object to implement the mteric handler protocol. this was done for convinience and confuses matters
* adjust tests
* fix a few typos
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
tomer doron
Rauhul Varma
Christian Priebe
Jari (LotU)
Konrad `ktoso` Malawski
tomer doron