54 lines
2.8 KiB
Markdown
54 lines
2.8 KiB
Markdown
|
---
|
||
|
|
stage: Data Stores
|
||
|
|
group: Memory
|
||
|
|
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
|
||
|
|
---
|
||
|
|
|
||
|
|
# Web exporter (dedicated metrics server) **(FREE SELF)**
|
||
|
|
|
||
|
|
When [monitoring GitLab with Prometheus](index.md), 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.
|
||
|
|
|
||
|
|
NOTE:
|
||
|
|
This page is about web application metrics.
|
||
|
|
To export background job metrics, learn how to [configure the Sidekiq metrics server](../../sidekiq.md#configure-the-sidekiq-metrics-server).
|
||
|
|
|
||
|
|
We provide two mechanisms by which web application metrics can be exported:
|
||
|
|
|
||
|
|
- Through the main Rails application. This means [Puma](../../operations/puma.md), the application server we use,
|
||
|
|
makes metric data available via its own `/-/metrics` endpoint. This is the default,
|
||
|
|
and is described in [GitLab Metrics](index.md#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:
|
||
|
|
|
||
|
|
1. [Enable Prometheus](index.md#configuring-prometheus).
|
||
|
|
1. Edit `/etc/gitlab/gitlab.rb` to add (or find and uncomment) the following lines. Make sure
|
||
|
|
`puma['exporter_enabled']` is set to `true`:
|
||
|
|
|
||
|
|
```ruby
|
||
|
|
puma['exporter_enabled'] = true
|
||
|
|
puma['exporter_address'] = "127.0.0.1"
|
||
|
|
puma['exporter_port'] = 8083
|
||
|
|
```
|
||
|
|
|
||
|
|
1. When using the GitLab-bundled Prometheus, make sure that its `scrape_config` is pointing
|
||
|
|
to `localhost:8083/metrics`. Refer to the [Adding custom scrape configurations](index.md#adding-custom-scrape-configurations) page
|
||
|
|
for how to configure scraper targets. For external Prometheus setup, refer to
|
||
|
|
[Using an external Prometheus server](index.md#using-an-external-prometheus-server) instead.
|
||
|
|
1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure)
|
||
|
|
for the changes to take effect.
|
||
|
|
|
||
|
|
Metrics can now be served and scraped from `localhost:8083/metrics`.
|