Add requests_count measure

[indiebrain]

Summary

Closes: #19

Expose the number of requests a puma worker has processed.

Context

Since puma/puma#2106, puma workers keep track of how many requests they have processed. This exposes Puma's requests_count stat via the yabeda-puma-plugin.

Examples

Standalone mode

[...snip...]
# TYPE puma_requests_count gauge
# HELP puma_requests_count Number of requests this worker has served since starting
puma_requests_count{index="0"} 103.0
[...snip...]

Clustered mode (4 workers)

[...snip...]
# TYPE puma_requests_count gauge
# HELP puma_requests_count Number of requests this worker has served since starting
puma_requests_count{index="0"} 82.0
puma_requests_count{index="1"} 76.0
puma_requests_count{index="2"} 61.0
puma_requests_count{index="3"} 44.0
[...snip...]

[indiebrain]

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?

[Envek]

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.

[Envek]

Thanks again for the pull request! I fixed tests, they are passing (and this is worrying, see below).

My concerns are as follows:

1. It is a gauge, however actually it should be a counter. 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). See metric types docs for details.

   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)

2. 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'm totally fine with dropping Puma 4 support, as Puma 5 was released almost 4 years ago already.

[indiebrain]

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?