Commit Graph

39 Commits

Author SHA1 Message Date
Honza Dvorsky 98d36172c1
Allow providing a custom MetricsFactory to Counter and friends (#172)
### Motivation:

To allow for things like parallel testing, it'd be useful if we can
explicitly provide a MetricsFactory to the existing Counter/... types.

### Modifications:

Added a `factory: MetricsFactory` parameter to all the initializers of
Counter/... types, and kept the existing methods that continue to
default to `MetricsSystem.factory`.

### Result:

Adopters can use a custom MetricsFactory explicitly passed in at metric
creation time. Existing adopters are not affected, unless you opt in,
you continue to use the global factory.
2025-04-29 15:07:30 +02:00
Franz Busch 3c0f419970
Add `Timer.measure` methods (#140)
# 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
2025-03-10 10:46:27 +01:00
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
Peter Adams 79e5fb4fe4
Raise minimum swift version to 5.8 (#147)
Motivation:

It's consistant with support policy (see https://github.com/apple/swift-metrics/pull/141).
It matches what's being tested.
It will make future changes adopting new features easier.

Modifications:

Bump swift tools version to 5.8
Remove linux tests and test discovery flag which are not required.

Result:

Will not longer build using swift before 5.8 - older compilers will find older
versions of this library when resolving versions.
2024-06-12 10:53:26 +01:00
hamzahrmalik 0124d9ad5c
Change Timer.record(duration: Duration) signature to avoid source breakage (#144) 2024-05-15 14:36:25 +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
Natik Gadzhi 13ea1fe7fc
Introducing Timer.record(_ duration:), closes #114 (#133)
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
2023-06-28 14:56:55 -07: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
hamzahrmalik 3402510406
Make 'values' on TestCounter, TestRecorder and TestMeter public (#129)
Co-authored-by: Hamzah Malik <hamzah_malik@apple.com>
2023-05-26 14:49:59 +02:00
hamzahrmalik 9d5ff3d48f
Use the MetricsTestKit in the MetricsTests rather than using a copy of the TestMetrics utilities (#128)
Co-authored-by: Hamzah Malik <hamzah_malik@apple.com>
2023-05-26 13:25:08 +02: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
Fabian Fett 78b6238009
Use UUID instead of NSUUID in MetricsTests (#126) 2023-05-05 11:01:45 +09:00
Gustavo Cairo e8bced74bc
Propagate displayUnit when using MultiplexMetricsHandler (#122) 2023-02-01 11:42:39 -08: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
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
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 aa197a1c15
Fix typos in test output (#59) 2020-02-10 17:26:55 +00:00
tomer doron 998de4b2cf better format
motivation: adjust format to xcode format

changes:
* update .swiftformat no-indent setting and run formatter
* update test generation script to match correct format
2019-12-18 12:14:01 +09: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
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
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 feafca5bb9
fix linux tests formatting (#13)
motivation: use consistent formatting

changes: update generate_linux_tests to match the formatting rules we use: `swiftformat --self insert --patternlet inline --stripunusedargs unnamed-only --comments ignore`
2019-04-12 10:57:04 -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
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
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