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: we are not actually using symbolicate-linux-fatal in any meaningful way in CI and it's pinned to the master branch which has been removed
changes: remove symbolicate-linux-fatal fetching from Docker
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: docs scripts is broken on selinux due to restriction on ssh-agent
changes:
* change the jazzy workspace to a directory accessible by the CI node so we can push from the agent instead of from the docker container
* dont remove older docs when pushing new ones
* add version inforamtion and source links
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.
motivation: more secured ci setup
changes:
* enable :z selinux flag on bind mounts so we can enable selinux on ci
* drop potentially exploitable capabilities from docker-compose
motivation: adjust format to xcode format
changes:
* update .swiftformat no-indent setting and run formatter
* update test generation script to match correct format
motivation: better ci testing
changes:
* add api breakage script to test api breakage in ci
* add "shell" utility docker-compose task to run api breakage script
* change test task to treat warning as errors
* prepare to test with thread sanitizer in 5.1
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: 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
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
📖 Small corrections, updates to the latest API, and grammar tweaks.
Motivation:
Make sure our README is current and easy to follow.
Modifications:
Graphite is a backend for metrics, Grafana is a frontend for visualization+alerting that can be powered by many backends.
We have a tagged release.
Add a link to @MrLotU 's SwiftPrometheus (emoji optional 😄 )
Some (mostly optional) punctuation tweaks
Tried to re-word the "applications choose their backend" section so it does not use the passive voice.
Update to the latest API... do we still want to write this out this here vs. link to the auto-generated API docs? 🤔 I'm leaning toward deleting it, but there's some value in it all being present here so long as we remember to update it.
Result:
Ideally, a better README! 📖
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.
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.
* 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
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.