Skip to content

Draft: Break up 7_prometheus into several setup modules

What does this MR do and why?

This builds on top of !81133 (merged) by extracting runtime specific metrics setup modules from the 7_prometheus metrics initializer. It uses the same FF, prometheus_initializer_refactor, which is tracked in #353446 (closed).

The new structure is as follows:

  • Gitlab::Metrics::Setup - shared initialization logic; should always run
  • Gitlab::Metrics::Setup::Puma - Puma specific initialization logic
  • Gitlab::Metrics::Setup::Sidekiq - Sidekiq specific initialization logic

The main initializer now merely calls into the appropriate modules. I tried to be careful not to change the order in which things run. If I did somewhere, then because I was confident that it wouldn't change semantics. Apart from clear responsibilities, it also allows for better test coverage (the initializer was not covered by tests at all previously.)

NOTE: Just as with the previous MR, the change looks big but really isn't, it's just that code has moved from A to B. Nothing new has been added, except tests. So outside of general structure, there is no need to review the contents of the individual setup files, unless something stands out as was-broken-before.

TODO:

  • puma and sidekiq setup test coverage
  • emit log line on this code path so we know it triggered

How to set up and validate locally

  1. Make sure Prometheus metrics are enabled in gitlab.yml
  2. Start Puma and/or Sidekiq; all metrics should still be emitted via /-/metrics and /metrics

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #350548 (closed)

Edited by Matthias Käppler

Merge request reports