Choosing a Prometheus Client for Ruby

[Alain Kuchta]

Hello,

Want to add Prometheus metric to a few Rails applications. I'm having a hard time choosing between the two primary client libraries. I'm looking for thoughts from other folks. 

prometheus/client_ruby VS discourse/prometheus_exporter

Here's my current assessment:

client_ruby
+ maintained in Prometheus org

+ doesn't require running a sidecar process

? handles multi-process using files

- doesn't come with many collectors

? doesn't seem to have many community collectors built on top

+ more mature project

prometheus_eporter

+ has lots of useful built-in collectors

? handles multi-process using a sidecar process with streaming JSON. Basically a PushGateway

- completely incompatible with client_ruby

- younger project

Any thoughts or suggestions are much appreciated!

[Brian Candler]

If you're considering the "sidecar exporter" approach, then also look at statsd_exporter (maintained in Prometheus org), and use a simple statsd client to fire updates to it.

In general, I'd say that the ideal approach is to instrument your application directly: it will have direct access to application state on every scrape.  However if your application is deployed as multiple processes, then having a sidecar might make things simpler: otherwise, as you've already noted, you need to access shared state in files or redis etc.

"Doesn't seem to have many community collectors built on top" may simply reflect that ruby isn't the go-to language for writing low-level collectors.  The go-to language is go :-)

[Alain Kuchta]

Thanks Brian! Your recommendations are helpful.

What I said regarding community-made collectors w.r.t. client_ruby was considering Ruby/Rails specific collectors, such as the ones that `prometheus_exporter` has for Rails, Puma, Resque etc.

I'm trying to weigh the value of the initial time savings of starting with those out-of-the-box collectors vs the feeling that `prometheus_exporter` is kind of an island of it's own.