Run gem install bundler -v '~> 2.0'
  gem install bundler -v '~> 2.0'
  shell: sh -e {0}
ERROR:  Error installing bundler:
	The last version of bundler (~> 2.0) to support your Ruby & RubyGems was 2.3.27. Try installing it with `gem install bundler -v 2.3.27`
	bundler requires Ruby version >= 3.0.0. The current ruby version is 2.5.9.229.
Error: Process completed with exit code 1.

These CI failures seem related to this project's CI matrix including end-of-life rubies, how the CI task installs bundler, and bundler's policy for dropping support for End-of-Life rubies.

Bundler supports Ruby and RubyGems versions until the next major release after the Ruby core team drops support. For example, the Ruby core team will drop all Ruby 2.4 support on March 31, 2020. The next Bundler major release after that date will drop support for Ruby 2.4. -- https://github.com/rubygems/bundler/blob/master/doc/POLICIES.md#compatibility-guidelines

FWIW, Ruby 2.7 reached end-of-life on 2023-03-31 and is even outside of its security maintenance window -- https://www.ruby-lang.org/en/downloads/branches/

I've not found any policy documentation from this project on compatibility expectations. Any guidance from the maintainers on how to proceed? Would it be appropriate for the next release of the yabeda-puma-plugin to drop unsupported / end-of-life'ed rubies and puma versions from its CI compatibility matrix?

Thanks for the pull request!

Ignore CI failures for outdated rubies, I will drop them from the CI matrix.

I will review your pull request soon, hopefully in a few days.

It is a gauge, however actually it should be a counter.

The way the requests_count stat works seems very much in line with gauge measurements, and is how similar exporter gems expose the requets_count measure to Prometheus.

Gauges are typically used for measured values ..., but also "counts" that can go up and down -- https://prometheus.io/docs/concepts/metric_types/#gauge

requests_count: the number of requests this worker has served since starting -- https://github.com/puma/puma/blob/master/docs/stats.md#single-mode-and-individual-workers-in-cluster-mode

Puma, itself, handles the incrementing a resets of the measure; the yabeda-puma-plugin is only acting as a proxy to expose measures already made by the pumactl stats module. Counters, by contrast, are much more suitable for tallying events over which the implementer has control or direct oversight.

Given the comment:

But of course we can't make it counter in current way (parsing value from control app), unless there is a way to hook into Puma processing request (like by maybe prepending here)

...I think we're more aligned than not, and probably saying the same thing from different angles. Please let me know if I've misunderstood the argument, or if there are other recommendations / considerations for moving this particular conversation forward.

I'm not sure whether e.g. Prometheus will be able to correctly handle gauge reset to 0 on puma restarts (as it do for counters).

I feel like I'm not fully understanding this concern. Given Prometheus' guidance on how to implement gauges in client libraries, it is unclear to me why a this value being reset to 0 or decreasing after a process restart would be detrimental. Would you mind providing a bit more context on the concern?

This feature was added in Puma 5.0, but test for Puma 4 passed fine. Probably because we're using mocked control app response.

I suppose the mantra "Only mock the things you own." is relevant here 😉. Perhaps I missed some integration level examples?

Hi, great job to add puma_requests_count metric introduced in Puma 5.0 (changelog) 👍

I think that is ok to use gauge, instead of counter, becase we are not controlling that value and in fact are not interested into saving previous value to calculate the difference