Configure gitlab-metrics-exporter logs

What does this MR do and why?

We are getting ready to migrate to a new application metrics exporter, gitlab-metrics-exporter, which aims to replace our Ruby exporter(s) with a single Golang application.

As part of production readiness, we are adding logging support. Support for logging via labkit in the exporter itself was completed in gitlab-metrics-exporter!10 (merged). Since the Rails application is responsible for spawning and observing this process (it runs alongside Rails to read metrics from disk), we need to also set the new config switches that map log config from gitlab.yml to settings the exporter understands.

NOTE: The new exporter is not enabled yet; it is guarded by an environment switch (GITLAB_GOLANG_METRICS_SERVER) that defaults to false. So deploying this change should be a no-op for now.

Related to gitlab-metrics-exporter#5 (closed)

How to set up and validate locally

The exporter can be used by both Puma and Sidekiq, but it's better to test this for Sidekiq, since only for sidekiq_exporter we interpret the log_enabled setting:

1. Set GITLAB_GOLANG_METRICS_SERVER=1 for Puma or Sidekiq (the exporter is used by both)
2. Enable the respective exporter and make sure log_enabled is true in gitlab.yml, e.g.:

   monitoring:
     sidekiq_exporter:
       enabled: true
       address: 127.0.0.1
       port: 8083
       log_enabled: true

3. Verify: a file called log/sidekiq_exporter.log exists in RAILS_ROOT and contains the server start message, e.g.:

   time="2022-05-09T07:38:07Z" level=info msg="server start" address="0.0.0.0:3807" pid=637

4. Now disable logs: log_enabled: false and restart Sidekiq
5. The log file should not receive any more messages

MR acceptance checklist

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

• I have evaluated the MR acceptance checklist for this MR.