When monitoring GitLab with Prometheus, GitLab runs various collectors that sample the application for data related to usage, load and performance. GitLab can then make this data available to a Prometheus scraper by running one or more Prometheus exporters. A Prometheus exporter is an HTTP server that serializes metric data into a format the Prometheus scraper understands.
We provide two mechanisms by which web application metrics can be exported:
- Through the main Rails application. This means Puma, the application server we use,
makes metric data available via its own
/-/metricsendpoint. This is the default, and is described in GitLab Metrics. We recommend this default for small GitLab installations where the amount of metrics collected is small.
- Through a dedicated metrics server. Enabling this server will cause Puma to launch an additional process whose sole responsibility is to serve metrics. This approach leads to better fault isolation and performance for very large GitLab installations, but comes with additional memory use. We recommend this approach for medium to large GitLab installations that seek high performance and availability.
Both the dedicated server and the Rails
/-/metrics endpoint serve the same data, so
they are functionally equivalent and differ merely in their performance characteristics.
To enable the dedicated server:
- Enable Prometheus.
/etc/gitlab/gitlab.rbto add (or find and uncomment) the following lines. Make sure
puma['exporter_enabled']is set to
puma['exporter_enabled'] = true puma['exporter_address'] = "127.0.0.1" puma['exporter_port'] = 8083
- When using the GitLab-bundled Prometheus, make sure that its
scrape_configis pointing to
localhost:8083/metrics. Refer to the Adding custom scrape configurations page for how to configure scraper targets. For external Prometheus setup, refer to Using an external Prometheus server instead.
- Save the file and reconfigure GitLab for the changes to take effect.
Metrics can now be served and scraped from