Сервис сбора и хранения метрик¶

В качестве сервиса сбора и хранения метрик может быть установлен VictoriaMetrics или Prometheus server.

По умолчанию используется VictoriaMetrics.

Сервис хранит метрики как данные временных рядов. Иными словами, данные о метриках хранятся вместе с отметкой времени, когда эти метрики были собраны, а также с опциональными парами «ключ-значение», называемыми метками. Архитектура баз данных для хранения временных рядов и принцип формирования запросов отличаются от реляционных баз данных.

Сбор метрик происходит по pull-модели, т.е. сервис самостоятельно опрашивает экспортёры в соответствии с заданным интервалом. Перечень опрашиваемых экспортёров находится в конфигурационном файле сервиса (по умолчанию prometheus.yml), который формируется в процессе развёртывания на основе inventory. Адрес и порт экспортёра составляют так называемый «таргет» в конфигурационном файле. Однотипные таргеты обычно сгруппированы внутри параметра job_name.

Примечание

При одновременном включении Prometheus server и VictoriaMetrics оба сервиса будут работать независимо.

При развёртывании Grafana одновременно с Prometheus server и/или VictoriaMetrics будет создан источник данных (data source) с типом prometheus, который будет подключён к VictoriaMetrics.

Для работы с данными внутри VictoriaMetrics при одновременном включении и Prometheus server, и VictoriaMetrics необходимо вручную создать соответствующий data source в Grafana.

VictoriaMetrics¶

Сервис VictoriaMetrics является модульным и состоит из нескольких компонент. В составе системы мониторинга используются следующие компоненты:

vmselect - обрабатывает запросы и получает запрошенные данные из vmstorage;

vminsert - отвечает за получение данных и распределение их между vmstorage;

vmstorage - непосредственно хранит метрики как данные временных рядов;

vmagent - агент для сбора метрик и сохранения их в VictoriaMetrics или любой другой TSDB посредством Prometheus remote_write или VictoriaMetrics remote_write протоколов;

vmalert - проверяет правила алертов и направляет сообщения об алертах в Prometheus Alertmanager.

Примечание

При значении переменной prometheus_use_victoriametrics_as_backend: "yes" устанавливаются и используются только следующие компоненты:

vmselect,

vminsert,

vmstorage.

Подробная документация доступна по ссылке https://docs.victoriametrics.com/.

Настройка периода и глубины хранения метрик¶

Для ограничения периода хранения и размера хранимых данных в VictoriaMetrics для компонента vmstorage предусмотрено несколько параметров запуска, которые задаются внутри переменной victoriametrics_vmstorage_cmdline_extras. Основные параметры:

-retentionPeriod — длительность хранения данных. Данные, которые выходят за указанный период, автоматически удаляются. Минимальное значение — 24h или 1d. Поддерживаемые суффиксы: s (секунда), h (час), d (день), w (неделя), y (год). Если суффикс не указан, длительность считается в месяцах. Если параметр не задан, то по умолчанию будет установлено значение, равное 1 (1 месяц).

-storage.minFreeDiskSpaceBytes — минимальный размер свободного пространства в storageDataPath. Если свободного места останется меньше, чем было указано в параметре, vmstorage перестанет принимать новые данные. Поддерживаемые опциональные суффиксы единиц измерения: KB, MB, GB, TB, KiB, MiB, GiB, TiB. Если суффикс не указан, размер считается в байтах. Значение по умолчанию — 10000000.

Для установки ограничений с помощью параметров запуска vmstorage выполните следующие действия:

В конфигурационном файле региона (по умолчанию /globals.d/REGION.yml) добавьте или измените переменную victoriametrics_vmstorage_cmdline_extras. Пример конфигурации с ограничением по длительности хранения данных в 15 дней:
victoriametrics_vmstorage_cmdline_extras: "-retentionPeriod 15d"
Создайте новый пайплайн: Build > Pipelines > New Pipeline.
В открывшемся окне добавьте переменную KOLLA_ARGS со значением -t victoriametrics.
Запустите пайплайн, нажав кнопку New pipeline.
Запустите задачу deploy в созданном пайплайне.
Дождитесь завершения выполнения задачи.

Prometheus server¶

Prometheus server является «монолитным» сервисом, который отвечает за сбор и хранение метрик, обработку правил и пользовательских запросов.

Подробная документация доступна по ссылке https://prometheus.io/docs.

Установка¶

Для развёртывания Prometheus в качестве сервиса хранения метрик выполните следующие действия:

В конфигурационный файл региона (по умолчанию /globals.d/REGION.yml) добавьте переменную enable_prometheus_server со значением yes. Пример конфигурации:
enable_prometheus_server: "yes"
Создайте новый пайплайн: Build > Pipelines > New Pipeline.
В открывшемся окне добавьте переменную KOLLA_ARGS со значением -t prometheus.
Запустите пайплайн, нажав кнопку New pipeline.
Запустите задачу deploy в созданном пайплайне.
Дождитесь завершения выполнения задачи.
После завершения пайплайна должны быть развёрнуты и предварительно настроены: Prometheus, набор экспортёров, Alertmanager.

Настройка периода и глубины хранения метрик¶

Для ограничения периода хранения и размера хранимых данных в Prometheus предусмотрено несколько параметров запуска. Основные параметры:

--storage.tsdb.retention.time — определяет время, через которое старые данные будут перезаписаны. Если параметр не задан, то по умолчанию будет установлено значение, равное 15d (15 дней).

--storage.tsdb.retention.size — определяет максимальное количество байт сохраняемых блоков памяти. Самые старые данные будут удалены в первую очередь. Если параметр не задан, то по умолчанию будет установлено значение, равное 0, что означает отсутствие ограничения на максимальный размер. Поддерживаемые единицы измерения: B, KB, MB, GB, TB, PB, EB (например, 512MB).

При одновременном указании ограничений как по времени хранения данных, так и по их размеру будет применяться ограничение по событию, наступившему в первую очередь.

Если для действующей системы установленные ограничения окажутся меньше текущих значений, то данные, выходящие за установленные ограничения, будут удалены.

Для установки ограничений с помощью параметров запуска Prometheus server выполните следующие действия:

В конфигурационном файле региона (по умолчанию /globals.d/REGION.yml) добавьте или измените переменную prometheus_cmdline_extras. Пример конфигурации с ограничением по длительности хранения данных 15 дней и без ограничения по размеру базы данных:
prometheus_cmdline_extras: "--storage.tsdb.retention.time 15d --storage.tsdb.retention.size 0"
Создайте новый пайплайн: Build > Pipelines > New Pipeline.
В открывшемся окне добавьте переменную KOLLA_ARGS со значением -t prometheus.
Запустите пайплайн, нажав кнопку New pipeline.
Запустите задачу deploy в созданном пайплайне.
Дождитесь завершения выполнения задачи.

Долгосрочное хранение метрик¶

Для долгосрочного хранения метрик предусмотрена возможность развёртывания VictoriaMetrics с репликацией метрик из Prometheus server в VictoriaMetrics.

Для включения данного функционала:

В конфигурационный файл региона (по умолчанию /globals.d/REGION.yml) добавьте переменную prometheus_use_victoriametrics_as_backend со значением yes. Пример конфигурации:
prometheus_use_victoriametrics_as_backend: "yes"
Создайте новый пайплайн: Build > Pipelines > New Pipeline.
В открывшемся окне добавьте переменную KOLLA_ARGS со значением -t prometheus.
Запустите пайплайн, нажав кнопку New pipeline.
Запустите задачу deploy в созданном пайплайне.
Дождитесь завершения выполнения задачи.

Миграция данных из Prometheus в VictoriaMetrics¶

Предварительные требования:

Должен иметься активный и работающий Prometheus server с собранными историческими данными.
Должен быть развёрнут сервис VictoriaMetrics.

Процесс миграции данных из Prometheus в VictoriaMetrics состоит из следующих шагов:

Развёртывание VictoriaMetrics, если данный сервис ещё не был развёрнут. Подробнее о развёртывании VictoriaMetrics перед началом миграции см. в разделе Установка VictoriaMetrics.
Миграция данных с помощью утилиты vmctl одним из способов:
- Использование Prometheus remote read protocol. Данный способ менее трудозатратен, так как не требует включения административного API Prometheus.
- Создание снапшота базы данных Prometheus и его импорт в VictoriaMetrics.
Выключение Prometheus server.

Пошаговое руководство для каждого из способов миграции приведено ниже. Подробная документация по утилите vmctl доступна по ссылке https://docs.victoriametrics.com/victoriametrics/vmctl/.

В результате миграции в развёрнутую пустую VictoriaMetrics будут импортированы исторические данные за предыдущие периоды. Также VictoriaMetrics станет основным сервисом сбора метрик.

Установка VictoriaMetrics¶

Для развёртывания VictoriaMetrics в качестве сервиса сбора и хранения метрик выполните следующие действия:

В конфигурационный файл региона (по умолчанию это globals.d/REGION.yml) добавьте переменную enable_victoriametrics со значением yes.
enable_victoriametrics: "yes"
Создайте новый пайплайн: Build > Pipelines > New Pipeline.
В открывшемся окне добавьте переменную KOLLA_ARGS со значением -t victoriametrics.
Запустите пайплайн, нажав кнопку New pipeline.
Запустите задачу deploy в созданном пайплайне.
Дождитесь завершения выполнения задачи.

Миграция данных с использованием Prometheus remote read protocol¶

Для того чтобы произвести миграцию с помощью Prometheus remote read protocol, выполните следующие действия:

Скопируйте утилиту vmctl на хост, на котором будет проводиться миграция (например один из control-узлов).
Данная утилита располагается на контроллерах в контейнерах victoriametrics_vmagent и victoriametrics_vmalert по пути /opt/victoriametrics/vmctl-prod. Копирование утилиты в текущий каталог осуществляется следующей командой:
$ podman cp victoriametrics_vmalert:/opt/victoriametrics/vmctl-prod
Запустите миграцию командой:
$ ./vmctl-prod remote-read --remote-read-src-addr=<prom_addr>:9091 --remote-read-user=admin --remote-read-password=<prometheus_password> --remote-read-filter-time-start=<timestamp> --remote-read-step-interval=<interval> --vm-addr=http://<control_node_ip_or_hostname>:8480 --remote-read-use-stream=true --vm-account-id=<account_id> --vm-user=admin --vm-password=<victoriametrics_password>
где:
<prom_addr> — адрес Prometheus вида http://<control_node_ip_or_hostname> или https://<internal_FQDN_VIP>;

<timestamp> — метка времени, с которой необходимо импортировать данные в формате RFC3339, например, 2020-01-01T20:07:00Z;

<interval> — интервал, на который будут поделены данные при миграции. Доступные значения: 'month', 'week', 'day', 'hour', 'minute';

<account_id> — идентификатор кластера victoriametrics. По умолчанию имеет значение 0;

<victoriametrics_password> — пароль для сервиса victoriametrics из файла passwords.yml.
В случае использования mtls необходимо дополнительно указать следующие параметры:
--vm-cert-file <путь к файлу с сертификатом> --vm-key-file <путь к файлу с приватным ключом> --vm-CA-file <путь к файлу с цепочкой корневых сертификатов>
Примечание

Сертификат, приватный ключ и цепочку корневых сертификатов следует взять из хранилища секретов Vault. Процесс создания сертификатов описан в разделе Создание и подготовка репозитория нового региона.

Пример запуска команды:
$ ./vmctl-prod remote-read --remote-read-src-addr=http://10.224.133.216:9091 --remote-read-user=admin --remote-read-password=<password> --remote-read-filter-time-start=2025-09-01T00:00:00Z --remote-read-step-interval=day --vm-addr=http://10.224.133.216:8480 --remote-read-use-stream=true --vm-account-id=0 --vm-user=admin --vm-password=<password>
При необходимости вы можете получить полный список флагов следующей командой:
$ ./vmctl-prod remote-read --help
По завершении процесса, в случае успешной миграции, должно отобразиться соответствующее сообщение со статистикой миграции.

Информационное сообщение со статистикой миграции¶

Импортированные данные можно увидеть в Grafana.

Отображение импортированных данных в Grafana¶

После окончания миграции рекомендуется перезапустить контейнеры vmselect на всех контроллерах.

Миграция данных с помощью снапшота базы данных Prometheus¶

Для того чтобы произвести миграцию с помощью снапшота базы данных Prometheus, выполните следующие действия:

В конфигурационный файл региона (по умолчанию это /globals.d/REGION.yml) добавьте переменную prometheus_cmdline_extras со значением --web.enable-admin-api. Затем запустите пайплайн с тегом prometheus и лимитом control для включения административного API Prometheus.
Формат команды:
$ /opt/prometheus/prometheus --web.config.file=/etc/prometheus/web.yml --config.file /etc/prometheus/prometheus.yml --web.listen-address <node_addr>:9091 --web.external-url=https://<vip_addr>:9091 --storage.tsdb.path /var/lib/prometheus --web.enable-admin-api
Аналогичное действие можно выполнить, внеся изменение на контроллерах в конфигурационный файл Prometheus /etc/kolla/prometheus-server/config.json посредством добавления ключа --web.enable-admin-api в команду запуска. После внесения изменений необходимо перезапустить Prometheus server на этих контроллерах.
Создайте снапшот базы данных Prometheus с помощью запроса к эндпоинту конкретного контроллера:
$ curl -X POST -u admin http://<control_node_ip_or_hostname>:9091/api/v1/admin/tsdb/snapshot
В случае запроса fqdn vip необходимо прописать:
$ curl -X POST -u admin https://<FQDN_VIP>:9091/api/v1/admin/tsdb/snapshot
где <FQDN_VIP> соответствует значению переменной kolla_internal_fqdn или kolla_external_fqdn (в зависимости от того, через внутренний или внешний интерфейс происходит подключение) в конфигурационном файле региона (по умолчанию это /globals.d/REGION.yml).

Поскольку vip адрес находится за балансировщиком, запрос будет обработан одним из экземпляров Prometheus, и снапшот будет располагаться на одном из контроллеров.

Запрос создаёт снапшот текущих данных, сохраняет его внутри контейнера внутри каталога с данными Prometheus в подкаталоге вида snapshots/<datetime>-<rand> и возвращает в ответе название каталога.

В случае успеха в ответ на запрос будет возвращён json вида:
{"status":"success","data":{"name":"20251028T074306Z-4e5c23eb571201c1"}}
Созданный снапшот будет сохранён по пути <data-dir>/snapshots/20251028T074306Z-4e5c23eb571201c1.

Каталог <data-dir> внутри контейнера prometheus_server соответствует /var/lib/prometheus. На хосте в случае использования Podman каталог будет соответствовать /var/lib/containers/storage/volumes/prometheus/_data/; в случае использования Docker — /var/lib/docker/volumes/prometheus/_data/.
Скопируйте утилиту vmctl на хост, на котором будет проводиться миграция (например один из control-узлов). Данная утилита располагается на контроллерах в контейнерах victoriametrics_vmagent и victoriametrics_vmalert по пути /opt/victoriametrics/vmctl-prod. Копирование утилиты в текущий каталог осуществляется следующей командой:
$ podman cp victoriametrics_vmalert:/opt/victoriametrics/vmctl-prod
Запустите миграцию командой:
$ ./vmctl-prod prometheus --prom-snapshot=<snapshot_dir> --vm-addr=<vm_insert> --vm-account-id=<account_id> --vm-user=admin --vm-password=<victoriametrics_password>
где:
<snapshot_dir> — путь к каталогу со снапшотом;

<vm_insert> — адрес vminsert вида http://<vminsert-addr>:8480 (где <vminsert-addr> - имя хоста или ip-адрес сервиса vminsert) или https://<internal_FQDN_VIP>:8480;

<account_id> — идентификатор кластера victoriametrics. По умолчанию имеет значение 0;

<victoriametrics_password> — пароль для сервиса victoriametrics из файла passwords.yml.
При отсутствии необходимости проводить tls-проверку при подключении к vminsert можно добавить дополнительный флаг:
--vm-insecure-skip-verify=true
В случае использования mtls необходимо дополнительно указать следующие параметры:
--vm-cert-file <путь к файлу с сертификатом> --vm-key-file <путь к файлу с приватным ключом> --vm-CA-file <путь к файлу с цепочкой корневых сертификатов>

Примечание

Сертификат, приватный ключ и цепочку корневых сертификатов следует взять из хранилища секретов Vault. Процесс создания сертификатов описан в разделе Создание и подготовка репозитория нового региона.
По умолчанию процесс миграции идёт в два потока. Изменение количества потоков осуществляется с помощью флага vm-concurrency. Данный флаг управляет количеством одновременных потоков, занятых процессом миграции данных. Каждый поток использует до одного vCPU ядра.
--vm-concurrency <value>
Пример запуска команды:
$ ./vmctl-prod prometheus --prom-snapshot=/var/lib/containers/storage/volumes/prometheus/_data/snapshots/20251028T074306Z-4e5c23eb571201c1/ --vm-addr=http://10.224.133.216:8480 --vm-account-id=0 --vm-user=admin --vm-password=<password>
При необходимости вы можете получить полный список флагов следующей командой:
$ ./vmctl-prod remote-read --help
По окончании процесса, в случае успешной миграции, должно отобразиться соответствующее сообщение со статистикой миграции.

Информационное сообщение со статистикой миграции¶

Импортированные данные можно увидеть в Grafana.

Отображение импортированных данных в Grafana¶

После окончания миграции рекомендуется перезапустить контейнеры vmselect на всех контроллерах.

Выключение Prometheus¶

Для выключения Prometheus после проведения миграции выполните следующие действия:

В конфигурационном файле региона (по умолчанию это /globals.d/REGION.yml) добавьте переменную enable_prometheus_server со значением no.
enable_prometheus_server: "no"
Создайте новый пайплайн: Build > Pipelines > New Pipeline.
В открывшемся окне добавьте переменную KOLLA_ARGS со значением -t victoriametrics,prometheus,grafana.
Запустите пайплайн, нажав кнопку New pipeline.
Запустите задачу deploy в созданном пайплайне.
Дождитесь завершения выполнения задачи.
После завершения пайплайна вручную удалите на контроллерах Docker/Podman-контейнеры, Docker/Podman-volumes, System-сервисы и все конфигурационные файлы, связанные с Prometheus server.