Comments (8)
Counters are (relatively) cheap. Why would you avoid creating many of them? Especially for paths, which usually are relatively static?
If you want to get this API to get "look and feel parity with prometheus without using prometheus" you can get there without changing all of the metrics APIs -- by providing an extension
func boringCounter.withLabels(...).increment()
which internally would create another counter based on the previous one; this does not have to live in this package, as it can be easily added on top as extensions.
But having that said... Some APIs work like that, some don't. With this SPI we aim to do the common ground of all APIs such that we backends do not need to go do great lengths to adopt these types -- the more surface we add, the more complex it becomes to adopt.
Note also, that the prime use of this SPI package is to offer metrics without knowing what backend one has -- e.g. in other libraries. If you are an end user application (webapp or something else) and really really need to use specific backend features, you are free to do so. Not all those patterns of features have to be exposed on the "common currency" types which this package represents.
Given an easy way to implement what you ask for exists, maybe you could start with that and we keep the ticket to see if it becomes a strongly demanded pattern across many backends and consider it then? We think this package needs to be very careful when adopting API changes, as it is the "common ground" API for many backends.
from swift-metrics.
Not sure if this is clear, but you can easily use dimensions as labels today. What you are asking for it just a slightly shuffled around syntax, but in the end it really boils down to the same thing. A web framework might emit request count metrics like this eg:
public let metrics: Middleware = { req, res, ctx in
res.whenComplete { r in
switch r {
case .success:
Counter(label: "http_requests_total", dimensions: [
( "route", req.header.path ),
("method", req.header.method.rawValue),
("status", "\(res.status.code)") ]).increment()
case .failure:
Counter(label: "http_requests_total", dimensions: [
( "route", req.header.path ),
("method", req.header.method.rawValue),
("status", "error") ]).increment()
}
}
ctx.next()
}
Isnβt this exactly what you want? Note, that it is not your job as an adopter of swift-metrics to worry about the lifecycle of the counter. The implementation has to worry about this. You just create one out of thin air when you need it.
from swift-metrics.
Great example there @t089, thanks for chiming in π
There's more ways one could get to the "code shape" you're after, but they all will end up as something like the above.
Please report back if there's more discussion to be had here or if we can close the ticket once you've confirmed on your end if the solution works for you @Yasumoto :)
from swift-metrics.
Here's where I wound up in case it helps anyone in the future: vapor-community/VaporMonitoring#5
from swift-metrics.
Yep, this was exactly what I was looking for, thank y'all so much for the help!
I'm wondering if there's value in expanding out the documentation (maybe a "usage guide" ?) to help point folks in this direction, or maybe this existed and I just missed it. If not, happy to have this closed!
from swift-metrics.
Yep, thanks for talking through the additional context πββοΈ
I think we're running into the "generic solutions get us some of the way there" but in this case it'd lead to a non-idiomatic solution for a particular backend (Prometheus) which isn't ideal.
I wonder if there's something along the lines of only exporting high-level metrics for core libraries. But if an application bootstraps a specific backend, we can rely on the additional features (like labels) to provide tighter integration with various backends instead in some way. I'll keep pondering, and of course more ideas appreciated!
from swift-metrics.
You just create one out of thin air when you need it.
@t089 that might be where my mental block was. Thank you!! I'll follow that path then report back π
from swift-metrics.
Closing since this is rad. Thanks again, folks!
from swift-metrics.
Related Issues (20)
- consider changing `Timer`, `Counter`, `Gauge` and `Recorder` to a value type.
- Import TestMetrics from swift-metrics-extras to swift-metrics proper
- Make use of Swift 5.7 Duration and friends for Timer
- Move to docc for documentation
- Consider a type preserving API HOT 3
- Release notes for 2.x should do a better job explaining what happened HOT 4
- github hosted docs have a link to install in dash, but no generated docset HOT 2
- Logging metrics factory HOT 11
- Sanity script should check for missing `return` statements HOT 4
- API for creating metrics with specific buckets or quantiles HOT 10
- Pattern: Document how one might use multiple metrics backends in one process
- Allow including baggage in reporting metrics?
- Additional sugar: Timer.recordInterval(since: DispatchTime, now: DispatchTime = .now()) HOT 1
- API for setting list of dimensions on `record`, rather than on Metric creation HOT 6
- README: add links to metrics extras
- Explicitly set counter values HOT 1
- Should recordInterval live in CoreMetrics? HOT 1
- There are several copy of the SwiftNIO Locks HOT 1
- API docs are for version 1.2.1 but we're at 2.x HOT 1
- [Question] What is the utility of aggregate?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from swift-metrics.