Commit Graph

47 Commits

Author SHA1 Message Date
Rick Newton-Rogers d720898dbf
Migrate to GitHub Actions (#151) 2024-11-06 22:32:20 +09:00
Gustavo Cairo e0165b53d4
Fix Sendability warnings (#137)
* Fix Sendability warnings

* Apply suggestions from code review

* Fix another warning and @unknown default issue

---------

Co-authored-by: Konrad `ktoso` Malawski <konrad.malawski@project13.pl>
2024-06-21 17:18:13 +01:00
Franz Busch d067b0e0f7
Add missing `Sendable` annotations (#148)
# Motivation
We were missing a few `Sendable` annotations on our public types.

# Modification
This PR adds `Sendable` to the missing types.
2024-06-21 05:40:32 +09:00
Si Beaumont 33d3f71e00
Update API breakage CI script (#143)
* Update API breakage CI script

* restate sendable conformance to avoid warning/as-error

---------

Co-authored-by: Konrad `ktoso` Malawski <konrad_malawski@apple.com>
2024-05-14 13:09:54 +09:00
Franz Busch 7e53749103
Align supported Swift versions with rest of the ecosystem (#141)
# 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.
2024-05-09 11:19:06 +09:00
tomer doron 971ba26378
add increment and decrement public API to Meter (#132)
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
2023-06-21 14:15:23 -07:00
tomer doron 32eef8ae84
add "meter" - a new type of metric and metric handler (#123)
motivation: seperate gauge from recorder in a backwards compatible way

changes:
* add new meter and meter handler pair
* add increment and decrement to meter handler
* add default implementation based on recorder for backwards compatibility
* add and adjust tests
2023-05-24 13:55:56 -07:00
Gustavo Cairo e8bced74bc
Propagate displayUnit when using MultiplexMetricsHandler (#122) 2023-02-01 11:42:39 -08:00
Fabian Fett bd1b935c8e
Make `MetricsFactory` Sendable (#116) 2022-07-21 10:53:47 +09:00
Fabian Fett 53be78637e
Remove testable import from TestMetrics. (#113) 2022-07-20 17:25:45 +09:00
tomer doron d885a4f5e9
adopt sendable (#109)
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
2022-07-01 16:38:50 -07:00
tomer doron fd0ee6956b
better abstration for MetricsSystem state (#112)
motivation: prepare for sendable checks (they dont work well with static state)

changes:
* abstract the MetricsSystem state into a "boxed" class that handles the locking
* adjust call sites
2022-06-29 11:08:12 -07:00
Rauhul Varma 3edd2f57af update comment 2021-08-16 11:49:56 +09:00
Rauhul Varma 2c58b010a2 remove assertions 2021-08-16 11:49:56 +09:00
Rauhul Varma 42372a8598 Introduce FloatingPointCounter
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.
2021-08-16 11:49:56 +09:00
Jari (LotU) e382458581 Remove reader lock 2020-11-12 18:10:16 +09:00
Jari (LotU) 2b6e31e1b3 Expose lock functionality 2020-11-12 18:10:16 +09:00
Konrad `ktoso` Malawski f5ed78cb26 =core remove not used import (Dispatch) 2020-10-13 10:39:24 +09:00
Moritz Lang 44e8bfc7f5
Add Timer.recordInterval method (#83)
* Add Timer.recordInterval method

Co-authored-by: Konrad `ktoso` Malawski <ktoso@apple.com>
2020-10-12 12:18:21 -07:00
Konrad `ktoso` Malawski 5702ee1174
metrics should include their labels when printed to ease debugging (#82)
motivation: ease debugging

changes: confirm metrics types to CustomStringConvertible
2020-10-08 15:08:43 -07:00
tomer doron 708b960b46
Add microseconds to TimeUnit (#64)
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>
2020-03-03 17:51:39 -08:00
Christian Priebe f1514a4c74
Bugfix: Print correct error message if bootstrap is called multiple times (#57)
MetricsSystem.bootstrap verifies that the metric system has not been previously
initialized. Otherwise it should fail with a corresponding error message. The
precondition error message includes the name of the currently used factory and
for that accesses self.factory. However, because bootstrap already holds
self.lock as a writer lock, self.factory fails to get it as a reader and
crashes with a less useful precondition error message. This commit ensures that
the correct error message is printed.
2020-02-10 11:11:28 -08:00
Jari (LotU) 3fefedaaef TimeUnits (#42)
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
2019-09-09 09:53:03 -07:00
Konrad `ktoso` Malawski e0ec4aea36 define record() more explicitly that it is a "set the value" (#35)
motivation: define record() more explicitly that it is a "set the value" operation as it seemed to be confusing when implementing or using the API.

changes: update API docs accordingly
2019-07-30 14:55:38 -07:00
tomer doron 25c2c17b45 test formatting issues as part of sanity check
motivaiton: unified format

changes:
* use official docker image 🎉
* fix outstanding formatting issues
* add a call to swiftformat as part of sanity script
* fix sanity script language check debugging statements
2019-07-30 14:10:30 +09:00
Konrad `ktoso` Malawski c7bbb2c55f Docs #26 shuffle around definitions to show user API first (#31) 2019-07-09 16:43:48 +01:00
Nathan Harris 8e5110dcd6 Add `Timer.recordNanoseconds` Generic Overload (#28) (#30)
Motivation:

As discussed in Issue #28, there are a few preferred lightweight APIs for getting timestamps such as `DispatchTime` but those APIs return `UInt64` types, which need to be handled for overflow.

Modifications:

Added a generic `BinaryInteger` overload method for `recordNanoseconds` that guards against accidental overflows from `UInt64` to `Int64`

Result:

Users now have access to a new method to record nanosecond measurements with `Timer` that guards against overflows.
2019-05-25 21:36:56 -07:00
Nathan Harris e4883dab79 Add guards for Int64 overflow in `Timer` methods (#29)
Motivation:

`Timer.record*` methods are generic to cover all cases of `BinaryInteger` values and converts the passed value into `Int64` before doing time unit conversions and overflow checks.

Modifications:

All methods that accept `BinaryInteger` types and converts to `Int64` now guards against values higher than `Int64.max`

Result:

Users can reliably use the `Timer.record*` APIs with `BinaryInteger` types without concern for unknowing fatal errors.
2019-05-24 22:41:41 -07:00
Konrad `ktoso` Malawski 4a9e0de637
doc: #26 clarify which init to use, reformat docs for easier noticing this (#27)
* doc: #26 clarify which init to use, reformat docs for easier noticing this

* Mark all "we do not expect this API to be used in normal..." as warnings
2019-05-25 14:33:16 +09:00
Yim Lee e7de07004c Fix API documentation (#24)
Motivation:

API documentation contains typos and grammatical errors.

Modifications:

Fix typos and grammatical errors. Update to use code syntax where
appropriate.

Result:

Eliminate typos and grammatical errors found.
2019-04-24 22:54:53 -07:00
tomer doron b017e02759
add note about convergence tag (#20)
motivation: starting convergence period for swift-metrics 1.0.0 release

changes:
* add info in readme about the convergence phase/version
* format
2019-04-22 10:20:44 -07:00
tomer doron 6db51d5f32
overflow (#19)
motivation: highlight the need to address overflow in metric objects that are integer based

changes:
* add section in the readme about addressing woverflow
* fix timer's unit conversion to address potential overflow
2019-04-22 09:47:46 -07:00
Konrad `ktoso` Malawski d9f63df00c Introduce metric.destroy() to enable lifecycle management (#17)
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
2019-04-19 10:33:58 -07:00
tomer doron 867072f4cb
use consistent, swifty naming convention (#6)
motivation: prepare to release

changes: refer to package as SwiftMetrics across the board isntead of swift-metrics
2019-04-10 09:37:22 -07:00
tomer doron 4729bac3a1
rename Counter::increment "value" parameter to "by" (#4)
* rename Counter::increment "value" parameter to "by"

motivation: nicer API signature

changes: rename Counter::increment and  CounterHandler::increment "value" parameter to "by"
2019-04-08 19:59:15 -07:00
tomer doron 585a41d684
prepare to release (#1)
* 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
2019-04-08 18:58:55 -07:00
tomer doron 5c1c739969
make protocol functions data type specific
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
2019-04-05 10:30:46 -07:00
tomer doron 187653d466
address feedback (#13)
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
2019-04-05 07:28:52 -07:00
Jari (LotU) 20b998220e make MetricSystem factory property public
motivation: make it possible to create extensions that want to expose specific implementations  

changes: make MetricSystem factory property public
2019-03-31 13:36:36 +01:00
tomer doron b24e6b2fb3 fixing typos
motivation: documentation cleanup

changes: fix various typos in method documentation
2019-03-07 16:05:36 -08:00
tomer doron 1f44332af3
refactor APIs to make them closer to swift-log APIs
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
2019-02-25 15:04:43 -08:00
tomer doron 2953390316
remove CachingMetricsHandler
motivation: CachingMetricsHandler represents an optimization that is better handled by implementations than dictated by the API

see: https://forums.swift.org/t/discussion-server-metrics-api/19600/2?u=tomerd

changes:
* remove CachingMetricsHandler
* adjust tests
2019-02-24 18:03:07 -08:00
tomer doron 02eeee08d9 license 2019-02-21 19:47:50 -08:00
Konrad `ktoso` Malawski 4554b8eea6 Align proposal code with proposal README, add missing make* on Metrics (#5)
May resolve #4 if that was the original intent of using the API
2019-01-17 23:09:00 -08:00
tomer doron 9907101ff8 format 2019-01-14 02:00:18 -08:00
tomer doron da46fbb762 better caching
motivation: better metrics cache, seperate mutex per type

changes:
* seperate mutex per metric type
* more tests
2019-01-11 10:51:57 -08:00
tomer doron d01123e590 initial commit 2019-01-08 13:25:21 -08:00