Comments (6)
Ah, right, excellent.
I'll do a quick proof of concept in the next couple of weeks, and get your feedback.
Thank you!
from client_ruby.
Once this has been done, more performance optimizations are possible, like incrementing all affected histogram buckets during a scrape instead of during each observe. See https://github.com/prometheus/client_golang/blob/a5060f1eaab721946b185b2de468ff83ea5b89cb/prometheus/histogram.go#L240-L282
from client_ruby.
@grobie Reading that doc, I'm not sure I understand what this would be.
How is this different from the Registry
the client already supports?
As for the performance improvement mentioned, we're doing that already:
https://github.com/prometheus/client_ruby/blob/master/lib/prometheus/client/histogram.rb#L77
https://github.com/prometheus/client_ruby/blob/master/lib/prometheus/client/histogram.rb#L93
:)
from client_ruby.
@dmagliola,
I think I can answer from the Go language client library perspective.
Registry
is able to register collectors. Collector itself has two methods: Describe
and Collect
. While the scrapping process is running, the HTTP server which serves /metrics
endpoint will gather metrics from the registry and the registry will collect all of the registered metrics.
One use case which I encountered here is to create a custom collector that collects metrics when it's instructed. One example on Go language is in this LXD exporter which exports metrics as instructed. I think this isn't possible for current version of client_ruby.
from client_ruby.
Thank you for your explanation @nieltg !
I'd like to try to tackle this issue sooner than later, since it unblocks a bunch of other use cases, but i'd like to make sure I understand it fully before starting, to not end up with an inadequate solution.
My understanding so far is that the way the Ruby client works, the main difference between a "regular" Metric, and a "Custom Collector" is that the Custom Collector can actually define multiple metrics. This is what makes it non-trivial to implement.
And the other of course being that these metrics inside the Custom Collector get their value assigned at scrape time, rather than during normal app operation.
Is that correct?
If we had a solution where we have a CustomCollector
class that implementors can inherit from, which includes a metrics
method to return all its metrics, and a collect
method that tells it to set their values... Would that basically solve the problem?
Or am I missing something?
from client_ruby.
Is that correct?
Yes.
metrics method to return all its metrics, and a collect method that tells it to set their values... Would that basically solve the problem?
No. collect should return all the metrics, as a collector doesn't always know which metrics it'll return in advance (plus that'd be racy).
from client_ruby.
Related Issues (20)
- CPU usage growing over time with DirectFileStore HOT 1
- better path handling HOT 14
- Update README.md with changes to pushgateway client
- Update CHANGELOG.md for 3.0.0 release HOT 1
- `generate_path` yields incorrect values for Sinatra+Rack::Build apps HOT 6
- Exporter port option doesn't work HOT 2
- Counter metric is reset when it has no labels HOT 8
- ERROR: Permission to prometheus/client_ruby.git denied HOT 2
- The rack example does not work because of `Rack::Lint::LintError` HOT 1
- Aaup HOT 1
- How to metrify ActiveRecord sql queries and Redis jobs (sidekiq/resque)? HOT 1
- pushing metrics with instance grouping_key would result: instance is reserved HOT 6
- Fix `Rack` deprecation warning
- Improving DirectFileStore for performance and scalability HOT 18
- Implement native histograms support HOT 4
- cannot load such file -- prometheus/middleware/collector (LoadError) HOT 2
- Job name for pushgateway can't be a symbol HOT 1
- UTF-8: Implement support in Ruby client library HOT 5
- How can I change how paths are labelled? HOT 1
- undefined method `unpack1' for String (NoMethodError) when use in ruby < 2.4 HOT 2
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 client_ruby.