Implement collector interface

[grobie]

The client library should follow our standard collector design and not scrape metrics directly: https://prometheus.io/docs/instrumenting/writing_clientlibs/#overall-structure

[grobie]

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

[dmagliola]

@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

:)

[nieltg]

@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.

[dmagliola]

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?

[brian-brazil]

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).

[dmagliola]

Ah, right, excellent.
I'll do a quick proof of concept in the next couple of weeks, and get your feedback.

Thank you!