We have an existing OPENPROJECT_PROMETHEUS_EXPORT which is
using the yabeda gems for prometheus metrics including ones
for puma.
We have found even just requiring those gems to cause a
memory leak in the past so I don't want to rely on this
for this auto scaling use case, especially when we just
need a very reduced set of puma metrics for it.
We have also evaluated the prometheus_exporter gem
as an alternative but it too suffers from a memory leak
in the puma collector specifically.
Hence this very simple metrics endpoint implementation on
top of the existing prometheus metrics.
That being said, by default both cannot be used at the same
time as they use the same port.
You can, however, configure the port for this feature to
avoid it.
We may want to include the web brick server in the health check
in the future, although there is not a whole lot going on
that could cause it to crash.
Because when starting the application with `puma -C config/puma.rb` leads to the Rails class not being defined, since it has not been loaded yet.
This solves our usage in production, since we dropped unicorn a long time ago.
Klaus Zanders