# Overview > **NOTE:** This epic used to suggest that we drop gitlab-exporter entirely. We have come to understand that this might not be the best solution or only option. The epic has been updated to reflect that. During ~"group::memory"'s [GitLab in 2GB research week](https://gitlab.com/groups/gitlab-org/memory-team/-/epics/2) we identified `gitlab-exporter` as a component that contributes significantly to overall memory use of GitLab. As we worked on reducing its memory impact, several issues have come to light that question whether gitlab-exporter should continue to exist in its current form. Gitlab-exporter has been much cause for debate in the past for other reasons than resource use, too, since it comes with intrinsic limitations such as not being able to report Ruby VM specific metrics for our Ruby services. We have meanwhile moved to an approach where metrics are exported from application services themselves instead. Below is a list of issues we see with gitlab-exporter and that should be addressed: 1. **It nowadays serves a minor role in a GitLab deployment.** Since we have moved to an approach where the vast majority of GitLab metrics are exported from the app itself, most of the functionality that remains in gitlab-exporter is redundant. ~"group::memory" has made some progress in removing redundant functionality such as [process metrics](https://gitlab.com/gitlab-org/gitlab/-/issues/290765), but several others remain. Some metrics it exports, however, have proved difficult to export from application services. We will have to identify a way forward for such metrics to exist, whether that be in gitlab-exporter or some place else. 1. **It consumes an outsized amount of memory, given its overall minor role.** This is already being worked on by ~"group::memory", for instance by looking to [swap out the Rack server](https://gitlab.com/gitlab-org/gitlab/-/issues/293687) used to run it, and by [tuning Ruby GC settings](https://gitlab.com/gitlab-org/gitlab/-/issues/297241). 1. **We are not running an up-to-date version on some parts of SaaS.** We accidentally discovered that the gitlab-exporter instance that collects Sidekiq metrics from Redis has not been updated in a very long time. It runs [v2.2 of "gitlab-monitor"](https://ops.gitlab.net/gitlab-cookbooks/chef-repo/-/blob/bb9cb4c27f84d3d044901a0e98802a6176e8e66e/roles/gprd-base-db-redis-server-sidekiq.json#L30), which is what gitlab-exporter was called back then. The latest version at the time I write this is 9.0. 1. **It uses a hand-rolled Prometheus client library.** Where there is official tooling, we should rely on that rather than rolling our own, unless there is a strong reason not to. 1. **It contains functionality that is unclear whether it's in use.** By this I'm referring for instance to a Lua script that collects Sidekiq metrics, but which we found to have been [retired for SaaS due to performance concerns](https://gitlab.com/gitlab-org/gitlab-exporter/-/merge_requests/28#note_476416136) (it needs to execute in Redis), and which also raises questions about testability and maintainability. We should retire and remove functionality that cannot prove itself useful, especially when its functionality can be replicated in simpler ways. 1. **Most metrics it exports are undocumented.** We aim to document metrics we export for our users [here](https://docs.gitlab.com/ee/administration/monitoring/prometheus/gitlab_metrics.html), but I found that none of the gitlab-exporter metrics can be found here, except for those that happen to be duplicated by in-app metrics. **We need to come to a decision of toss vs keep.** If we want to keep building on gitlab-exporter, at least some of the issues mentioned above should be addressed, otherwise we continue to accrue tech debt. If we want to toss it, we need to propose a strategy for how to port the remaining metrics. There are some use cases, such as cluster-wise metrics (database row counts, sidekiq global queue metrics) that have [proven difficult to extract](https://gitlab.com/gitlab-org/gitlab/-/issues/290768). We may decide instead to keep gitlab-exporter with reduced functionality, hosting only those metrics that should be sampled infrequently from shared resources (Redis, postgres). # References ## Metrics overview Below are all metrics that I could find are exported from gitlab-exporter, and whether they are in use or not, along with issue links describing how they could be extracted. | **metric pattern** | **source** | **owner** | **documented** | **exported to .com** | **Used in runbooks** | migration issue | |-----------------------------------|----------|-----|------------|------------------|----|----------------| | `gitlab_database_bloat_*` | database | Database | no | yes | no | https://gitlab.com/gitlab-org/gitlab/-/issues/290747 | | `gitlab_database_rows` | database | Database | no | yes | [yes](https://gitlab.com/search?utf8=%E2%9C%93&snippets=false&scope=&repository_ref=master&search=gitlab_database_rows&group_id=6543&project_id=1148549) | https://gitlab.com/gitlab-org/gitlab/-/issues/290747 | | `gitlab_database_stat_table_*` | database | Database | no | yes | no | https://gitlab.com/gitlab-org/gitlab/-/issues/290747 | | `ci_*_builds` | database | Verify/Runner | no | yes | [yes](https://gitlab.com/search?utf8=%E2%9C%93&snippets=false&scope=&repository_ref=master&search=ci_pending_builds&group_id=6543&project_id=1148549) | https://gitlab.com/gitlab-org/gitlab/-/issues/290751 | | `project_remote_mirror_*` | database | Create | no | yes | [yes](https://gitlab.com/search?utf8=%E2%9C%93&snippets=false&scope=&repository_ref=master&search=project_remote_mirror*&group_id=6543&project_id=1148549) | https://gitlab.com/gitlab-org/gitlab/-/issues/290755 | | `git_*_time_milliseconds` | procfs | Create | no | no | no | https://gitlab.com/gitlab-org/gitlab/-/issues/290755 | | `process_*` | procfs | Memory/Infra | no | yes | [yes](https://gitlab.com/search?utf8=%E2%9C%93&snippets=false&scope=&repository_ref=master&search=process_*&group_id=6543&project_id=1148549) | https://gitlab.com/gitlab-org/gitlab/-/issues/290765 | | `process_smaps_*` | procfs | Memory/Infra | no | no | no | https://gitlab.com/gitlab-org/gitlab/-/issues/290765 | | `sidekiq_*` | redis | ? | no | yes | [yes](https://gitlab.com/search?utf8=%E2%9C%93&snippets=false&scope=&repository_ref=master&search=sidekiq_*&group_id=6543&project_id=1148549) | https://gitlab.com/gitlab-org/gitlab/-/issues/290768 | ## Outcome Due to the level of complexity, we will not be dropping gitlab-exporter. We will drop areas of the code no longer in use and [reduce this process memory usage by over 40%](https://gitlab.com/groups/gitlab-org/-/epics/5035#note_483759995)