Сбор метрик GitLab с помощью встроенных Prometheus + Grafana

Обновлено: 09.12.2022

Опубликовано: 08.12.2022

Используемые термины: GitLab, Prometheus, Grafana.

По умолчанию, GitLab идет в комплекте с сервисом сбора и хранения метрик Prometheus, а также средствами визуализации Grafana. Мы рассмотрим, как можно воспользоваться данными инструментами после развертывания GitLab (при необходимости, в конце инструкции можно найти ссылки на руководства по его установке и настройке).

В результате мы получим:

Аутентификацию на Grafana через GitLab.
Возможность просмотра нативных метрик.
Дополнительные метрики для Gitlab Pipelines.

Разделы инструкции:

Настройка сертификата
Получение токена приложения в GitLab
Настройка Prometheus и Grafana
Авторизация в Grafana и получение прав администратора
Использование метрик
Входящих в комплект с GitLab
Добавление новых на примере Pipelines
Решение возможных проблем
Читайте также

Настройка SSL

Для аутентификации на Grafana через GitLab необходимо использовать корректные сертификаты, а именно:

Выданные на домен, к которому идет обращение.
Не просрочены по дате.
Выданные удостоверяющим центром, которому доверяет система.

Проще всего, использовать бесплатные сертификаты от Let's Encrypt или можно купить сертификат.

Но если в нашей сети есть локальный центр сертификации, нужно убедиться, что его корневой сертификат установлен в системе, где работает GitLab. В зависимости от дистрибутива Linux, действия будут отличаться.

а) Для DEB (Ubuntu / Astra Linux / Debian).

Помещаем корневой сертификат в каталог /usr/local/share/ca-certificates/ и выполняем команду:

update-ca-certificates

б) Для RPM (Rocky Linux / РЕД ОС / CentOS).

Копируем сертификат в папку /etc/pki/ca-trust/source/anchors/ и выполняем:

update-ca-trust extract

При переходе на веб-интерфейс GitLab браузер не должен выдавать ошибок и предупреждений безопасности. Также можно выполнить проверку корректной работы SSL из командной строки Linux:

curl https://gitlab.dmosk.ru

* где gitlab.dmosk.ru — адрес нашего сервера GitLab.

В итоге, мы не должны получить ошибку подключения из-за неправильного сертификата

curl: (60) SSL: ...

Создание application token в GitLab

Для авторизации через GitLab создадим токен приложения. Для этого заходим на портал под пользователем с правами администратора и переходим в раздел настройки профиля:

Переходим в профиль пользователя на Gitlab

В меню слева переходим в раздел приложений:

Переходим в раздел управления приложениями

Заполняем форму — вводим название приложения, а также адрес возврата после авторизации (это будет наш URL-адрес gitlab + /-/grafana/login/gitlab):

Заполняем данные для получения токена

* где нам необходимо:

Задать произвольное имя приложения. Например, Grafana.
Указать адрес Redirect URI. В моем случае адрес сервера gitlab.dmosk.ru, а /-/grafana/login/gitlab часть для доступа к встроенной grafana.
Ставим галочки read_api и read_user для возможности получения списка пользователей и их прав.

Нажимаем на кнопку сохранения настроек — откроется окно с Application ID и Secret:

Копируем Application ID и его токен

Фиксируем эти данные — они нам будут нужны при настройке графаны.

Нажимаем Continue, чтобы сохранить Application ID и Secret в GitLab.

Включение prometheus и grafana

По умолчанию, сервисы prometheus и grafana уже включены. Нам нужно проверить, что это так и отредактировать некоторые настройки. Открываем конфигурационный файл gitlab:

vi /etc/gitlab/gitlab.rb

Приводим к виду следующие опции:

prometheus['enable'] = true
...
grafana['enable'] = true
grafana['gitlab_application_id'] = '5b38347e60679bde8fa688e91dc6b1b84f00cf49e1a574367189105cd8186bf8'
grafana['gitlab_secret'] = 'eac862acd98cf9accdde9aa27da0c81bbb8b38dcd588dbe5d9c8ea396a5ebc04'
...
gitlab_exporter['enable'] = true
...
node_exporter['enable'] = true
node_exporter['listen_address'] = 'localhost:9100'

* где:

prometheus['enable'] — включает или выключает сервис prometheus. По умолчанию включен.
grafana['enable'] — включает или выключает сервис grafana. По умолчанию включен.
grafana['gitlab_application_id'] — задаем Application ID, который получили в GitLab.
grafana['gitlab_secret'] — указываем секрет, который также получили на предыдущем этапе в гитлабе.
gitlab_exporter['enable'] — включает или выключает сбор метрик gitlab. По умолчанию включен.
node_exporter['enable'] — включает или выключает сбор метрик для ноды. Обязательно, снимаем комментарий, так как по умолчанию, отключен.
node_exporter['listen_address'] — адрес, на котором должен слушать экспортер метрик для ноды.

Доступ к сервисам grafana и prometheus предоставлен только с локального хоста. Для работы это нам не помешает, но если, по каким-либо причинам, нам нужен прямой доступ к ним по сети, приводим следующие опции к виду:

prometheus['listen_address'] = '0.0.0.0:9090'
...
grafana['http_addr'] = '0.0.0.0'

* в данном примере мы указываем, что сервисы prometheus и grafana должны слушать на всех IP-адресах, а не только на локальной петле.

Чтобы применить настройки переконфигурируем gitlab:

gitlab-ctl reconfigure

Пробуем зайти в графану. В браузере вводим адрес https://gitlab.dmosk.ru/-/grafana/, где gitlab.dmosk.ru — адрес нашего сервера gitlab. Мы должны увидеть страницу для авторизации в Grafana. Кликаем по кнопке Sign in with GitLab:

Переходим в GitLab для авторизации в Grafana

В следующем окне кликаем по Authorize, чтобы разрешить использовать текущего пользователя Gitlab для авторизации в Grafana:

Подтверждаем авторизацию на Gitlab

Мы должны авторизоваться в Grafana.

Если при авторизации портал выдает ошибку, смотрим логи командой:

gitlab-ctl tail grafana

Мы входим на графану с правами только на просмотр. На данный момент, нет возможности дать пользователю Gitlab права администратора в Grafana. Подробнее проблема описана по адресу https://gitlab.com/gitlab-org/gitlab/-/issues/31125.

Нам предлагают для административных задач использовать встроенную учетную запись. Для этого сначала создадим ей пароль:

gitlab-ctl set-grafana-password

* система запросит дважды ввести пароль.

Откроем конфигурационный файл gitlab:

vi /etc/gitlab/gitlab.rb

Приведем опцию к виду:

grafana['disable_login_form'] = false

* она разрешает на Grafana использовать авторизационную форму входа пользователя.

Опять переконфигурируем gitlab:

gitlab-ctl reconfigure

Снова заходим на страницу авторизации https://gitlab.dmosk.ru/-/grafana/ — теперь, помимо кнопки авторизации через GitLab, мы должны увидеть форму для ввода логина и пароля. Вводим пользователя admin и пароль, установленный нами ранее.

Теперь мы попали в Gitlab с полными правами.

Метрики

Рассмотрим встроенные метрики и пример добавления новых метрик.

Встроенные

В комплексе GitLab + Prometheus + Grafana идут метрики, которые позволяют оценить общее состояние нашего сервера. Посмотреть их список можно, перейдя в раздел Dashboards - Manage:

Переходим к списку дашбордов в Grafana

Мы должны увидеть список Gitlab Omnibus, в котором можно найти разные дашборды для визуализации различных групп метрик:

Список встроенных метрик Gitlab Omnibus

Попробуйте открыть каждый дашборд, чтобы проверить сбор метрик.

Добавить Pipelines Metrics

Разберемся с алгоритмом добавления новых метрик на примере мониторинга состояния CI/CD Pipelines. Забегая вперед скажу, что тут не обошлось без нюансов, больше похожих на недоработки. Обо всем, по порядку.

Для начала нам нужно запустить новый экспортер для Prometheus. Его описание доступно по ссылке https://github.com/mvisonneau/gitlab-ci-pipelines-exporter. Мы увидим, что есть много способов установки экспортера. Мы рассмотрим вариант с docker + docker-compose. За основу возьмем официальное описание для быстрого старта.

Необходимо, чтобы на нашей машине с gitlab был установлен docker и docker-compose. Подробнее про это можно почитать, перейдя по соответствующей ссылке, представленной в конце данной инструкции.

Создадим каталог для хранения данных и перейдем в него:

mkdir /opt/gitlab-ci-pipelines-exporter

cd /opt/gitlab-ci-pipelines-exporter

Создадим файл docker-compose:

vi docker-compose.yml

services:

gitlab-ci-pipelines-exporter:
image: docker.io/mvisonneau/gitlab-ci-pipelines-exporter
   container_name: gitlab-ci-pipelines-exporter
   hostname: gitlab-ci-pipelines-exporter
   restart: unless-stopped
ports:
- 8080:8080
environment:
   TZ: "Europe/Moscow"
GCPE_CONFIG: /etc/pipelines-exporter/gitlab-ci-pipelines-exporter.yml
GCPE_INTERNAL_MONITORING_LISTENER_ADDRESS: tcp://127.0.0.1:8082
volumes:
- ./config/gitlab-ci-pipelines-exporter.yml:/etc/pipelines-exporter/gitlab-ci-pipelines-exporter.yml

* обратите внимание на внешний порт 8080. Если в вашей системе он занят, назначьте другой (и учитывайте это ниже, читая в инструкции 8080). Например, если мы хотим поменять порт на 8081, то пишем 8081:8080.

Открываем портал GitLab и входим под пользователем с максимальными правами. Переходим в настройки профиля:

Переходим в профиль пользователя на Gitlab

Слева выбираем пункт для управления токенами:

Переходим к управлению токенами в GitLab

Заполняем форму для создания нового токена:

Заполнение данных для создания токена

* нам нужно указать любое удобное имя для токена (например, prometheus-pipeline-exporter) и поставить галочку для read_api.

Кликаем по Create personal access token. Мы должны увидеть токен:

Созданный токен в GitLab

Сохраняем его.

Создаем каталог для хранения конфигурации:

mkdir config

И создаем конфигурационный файл для экспортера:

vi config/gitlab-ci-pipelines-exporter.yml

---

log:
level: debug

gitlab:
url: https://gitlab.dmosk.ru
token: qAxuEHRhkzK_eoECynGW

# Pull jobs related metrics on all projects
project_defaults:
pull:
pipeline:
jobs:
enabled: true

# Example public projects to monitor
wildcards:
- {}

* подробное описание и примеры конфигурационного файла можно найти по ссылке проекта, которые были указаны в начале данного раздела. Обратите внимание на:

gitlab url — путь к порталу GitLab. К его API экспортер будет подключаться для сбора метрик.
gitlab token — токен, который должен использовать экспортер. Этот токен мы создали выше.
wildcards — перечисление правил для отображения метрик конкретных проектов. Позволяет тонко отфильтровать то, что нам нужно. Но в данном примере мы не используем никаких фильтров, предполагая, что метрики будут собираться для всех проектов.

Можно запускать контейнер:

docker-compose up -d

Сразу имеет смысл посмотреть лог сбора метрик:

docker logs gitlab-ci-pipelines-exporter

В моем случае была ошибка x509: certificate signed by unknown authority. Ее решение описано ниже.

Также можно попробовать посмотреть на метрики, которые возвращает экспортер:

curl http://127.0.0.1:8080/metrics

Теперь необходимо указать серверу prometheus собирать данные метрики. Открываем файл:

vi /var/opt/gitlab/prometheus/prometheus.yml

В подраздел scrape_configs добавим новую задачу (отмечено желтым):

scrape_configs:
- job_name: 'gitlab-ci-pipelines-exporter'
scrape_interval: 10s
scrape_timeout: 5s
static_configs:
- targets:
- localhost:8080
...

* в данном примере мы говорим прометеусу собирать метрики с узла localhost:8080. Если мы запустили экспортер не на локальном хосте и/или на другом порте, меняем значения.

Перезапускаем prometheus:

gitlab-ctl restart prometheus

Мы приблизились к финишной прямой — осталось визуализировать метрики. Нам нужно импортировать дашборд gitlab-ci-pipelines. Его описание и код импорта доступны на сайте Grafana.

Открываем импорт дашбордов:

Перехоидм к импорту дашбордов в Grafana

Вводим код для импорта — 10620:

Вводим код 10620 для импорта дашборда GitLab CI pipelines

На следующей странице выбираем в качестве источника данных Gitlab Omnibus и нажимаем Import:

Выбираем источник данных для дашборда и заканчиваем импорт

После загрузки нового дашборда немного ждем — мы должны получить информацию о pipelines.

Но также мы увидеть ошибку Panel plugin not found: grafana-polystat-panel:

Panel plugin not found: grafana-polystat-panel

Плагин grafana-polystat-panel нужен для красивой визуализации данных. Установим его:

grafana-cli --pluginsDir /opt/gitlab/embedded/service/grafana/public/app/plugins/panel/ plugins install grafana-polystat-panel

Перезапускаем графану:

gitlab-ctl restart grafana

Но портал, по прежнему, выдавал ошибку. Я заметил, что он пытается обращаться по URL, содержащем grafana-polystat-panel/module, но в каталоге с плагином скрипт называется module.js.

Перейдем в каталог плагина:

cd /opt/gitlab/embedded/service/grafana/public/app/plugins/panel/grafana-polystat-panel/

И переименуем скрипт:

mv module.js module

Готово.

Возможные проблемы

В данном разделе я рассмотрю примеры проблем, с которыми столкнулся я.

x509: certificate signed by unknown authority

Данную ошибку мы получаем в логах gitlab-ci-pipelines-exporter. Полный текст, примерно, такой:

level=warning msg="taskqtask=\"PullProjectsFromWildcard\" handler failed after retry=1: unable to list projects with search pattern '' from the GitLab API : Get \"https://gitlab.dmosk.ru/api/v4/projects?archived=false&page=1&per_page=100&search=\": x509: certificate signed by unknown authority"

Причина: экспортер pipelines-exporter пытается подключиться к порталу gitlab, но ему не нравится сертификат. Как правило, это связано с использованием не публичного центра сертификации.

Решение: мы можем перейти на использование сертификатов от Let's Encrypt. Но если нам нужен сертификат от своего центра сертификации, необходимо импортировать ключ для CA.

В нашем примере мы используем docker с образом docker.io/mvisonneau/gitlab-ci-pipelines-exporter. Он создан на основе Alpine Linux и для него достаточно, чтобы нужный сертификат оказался в каталоге /etc/ssl/certs. Для этого откроем наш файл:

vi docker-compose.yml

И добавим:

...
volumes:
- ./config/gitlab-ci-pipelines-exporter.yml:/etc/pipelines-exporter/gitlab-ci-pipelines-exporter.yml
- /etc/ipa/ca.crt:/etc/ssl/certs/ca.crt

* обратите внимание, что мой корневой сертификат хранится по пути /etc/ipa/ca.crt. Вы же должны поставить свой путь.

После запускаем: