Comments (7)
Usually, I'd say I agree with @ktoso that one module would probably be better. But the point @MrLotU makes sense (that there might be users who need more power than the 'currency API' gives you).
There seems to be a misunderstanding here I think?
It can be:
- 1 module
- swift-metrics handler implementations
- the PromCounter et al types
- users pick whichever they
And users should:
- use the powerful apis if they want, sure!
- do bootstrap the
If you are the "normal" case and you want to use SwiftMetrics with Prometheus as a backend, why would you ever want any of the symbols from Prometheus?
There is no one "normal case" I'd argue, there are two:
a library; never even has access to Prometheus -- uses SwiftMetrics
an end user app:
- should bootstrap
PrometheusMetrics.bootstrap(....)
- MAY want to use the
PromGauge
types in some places, since e.g. it provides add/sub which SwiftMetrics does not ( apple/swift-metrics#36 ), or similar "has more features" cases- in other places is totally fine with plain
Counter
etc, since those sources are then maybe easier to rip into mini libraries etc etc.
@ktoso Yes, you're totally right, agree with you. I was worried about the 'pollution' of the namespace by having both the Prometheus APIs as well as the 'Prometheus for SwiftMetrics boostrapping' bits imported. However I think that concern is mostly moot because there are two cases:
- user uses the SwiftLog API (the "normal" case): apart from one file (where they bootstrap), they only ever
import Metrics
, so they wouldn't see the direct Prometheus APIs - they are a power Prometheus user and use the Prometheus APIs directly: The pollution is restricted to just one function (the
Prometheus.bootstrap
function) which is acceptable.
So in both cases, the pollution is minimal: In case (1) it's restricted to one file and in (2) it's just one function. So in hindsight I think this should just be one module.
from swift-prometheus.
I'm wondering if there is a reason to have the two in separate modules really btw...
Does not really cost much to have just Prometheus
and it also implement the Metrics
it is "shared currency" API after all, wdyt @weissi
// Finding those as I'm trying to use it today btw :-)
from swift-prometheus.
Fixed in 31d6964. Though I'm still not sure how to handle this. I know for a fact that Vapor uses @_exported
a lot. I also think that in this specific usecase, it doesn't have many of the drawbacks it normally gives you.
The reason I separated the two is because I don't want to pressure people into using the swift-metrics
APIs because in my case, the standalone Prometheus APIs give you more power.
Curious to hear input on this though. CC @weissi
from swift-prometheus.
Usually, I'd say I agree with @ktoso that one module would probably be better. But the point @MrLotU makes sense (that there might be users who need more power than the 'currency API' gives you).
Regarding the @_exported import
: What exactly are the things that you would need to have exported? I thought unless you're a special prometheus power-user you'd just live off the API that SwiftMetrics gives you?
So what I was thinking (please correct me if I'm wrong), you'd do in your main.swift
import Metrics
import PrometheusMetrics
PrometheusMetrics.bootstrap(....)
but in all other files, you'd just do
import Metrics
// use the metrics
So rephrasing the question: If you are the "normal" case and you want to use SwiftMetrics with Prometheus as a backend, why would you ever want any of the symbols from Prometheus
?
from swift-prometheus.
Usually, I'd say I agree with @ktoso that one module would probably be better. But the point @MrLotU makes sense (that there might be users who need more power than the 'currency API' gives you).
There seems to be a misunderstanding here I think?
It can be:
- 1 module
- swift-metrics handler implementations
- the PromCounter et al types
- users pick whichever they
And users should:
- use the powerful apis if they want, sure!
- do bootstrap the
If you are the "normal" case and you want to use SwiftMetrics with Prometheus as a backend, why would you ever want any of the symbols from Prometheus?
There is no one "normal case" I'd argue, there are two:
- a library; never even has access to Prometheus -- uses SwiftMetrics
- an end user app:
- should bootstrap
PrometheusMetrics.bootstrap(....)
- MAY want to use the
PromGauge
types in some places, since e.g. it provides add/sub which SwiftMetrics does not ( apple/swift-metrics#36 ), or similar "has more features" cases - in other places is totally fine with plain
Counter
etc, since those sources are then maybe easier to rip into mini libraries etc etc.
- should bootstrap
from swift-prometheus.
Gave this a whirl at #9, if someone's already working on this I'm happy to defer to that!
from swift-prometheus.
Awesome work on #9 ! I left a review there. @ktoso @weissi I would greatly appreciate if the two of you could also give it a quick look 😄
from swift-prometheus.
Related Issues (20)
- Link to Prometheus project in the README
- Support a histogram backed timer.
- Numbered release soon? HOT 1
- PushGateway
- Getting prometheusFactoryNotBootstrapped HOT 1
- Summary calculation time grows with time (potentially limitless)
- Release 1.0 HOT 2
- Add dimension name sanitizer HOT 1
- Async/Await HOT 1
- TimerHandler implementation always records nanoseconds in Histogram
- Support Exemplars
- defaultRecorderBuckets not respected with swift-metrics
- Inconsistent: Summary and Histogram deal with dimensional values differently than Counter HOT 4
- Crash while collect(): Unexpectedly found nil while unwrapping an Optional value at CircularBuffer.swift HOT 5
- Use of dimensions produces empty metric
- [QUESTION] I want to use custom path for pulling endpoint
- Outdated repo link HOT 1
- False prometheusNotBoostrapped error with multiplex handler HOT 1
- Switch to swift-format
- Investigate Prometheus Native Histograms
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-prometheus.