### Problem to solve We currently use a forked Prometheus library, [prometheus-client-mmap](https://gitlab.com/gitlab-org/prometheus-client-mmap). It is worth the effort to switch to the upstream library in order to avoid the burden of maintaining this library on our own. ### Intended users GitLab developers ### Further details The upstream Prometheus [client_ruby](https://github.com/prometheus/client_ruby) [now supports multi-process metrics](https://github.com/prometheus/client_ruby/pull/95). Now that this is complete we should switch to this upstream code. The metrics storage is [modular](https://github.com/prometheus/client_ruby#built-in-stores). We will have to evaluate which mode to use. It seems like `DirectFileStore` is the only one we can use for multi-process. We will have to evaluate the performance of this compared to the current C implementation. ### Proposal * [x] Review the upstream multi-process support. https://gitlab.com/gitlab-org/gitlab-ce/issues/59959 * [ ] Benchmark compare the multi-process support. * [ ] Upstream the C code for multi-process if necessary. * [ ] Update our instrumentation to use the new library. ### Permissions and Security N/A ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements --> ### What does success look like, and how can we measure that? When using the upstream library we get as good or better performance with the same or better functionality. ### Links / references