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

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

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

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

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

Примечание

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

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

Для работы с данными внутри 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 выполните следующие действия:

  1. В конфигурационном файле региона (по умолчанию /globals.d/REGION.yml) добавьте или измените переменную victoriametrics_vmstorage_cmdline_extras. Пример конфигурации с ограничением по длительности хранения данных в 15 дней:

    victoriametrics_vmstorage_cmdline_extras: "-retentionPeriod 15d"

  2. Создайте новый пайплайн: Build > Pipelines > New Pipeline.

  3. В открывшемся окне добавьте переменную KOLLA_ARGS со значением -t victoriametrics.

  4. Запустите пайплайн, нажав кнопку New pipeline.

  5. Запустите задачу deploy в созданном пайплайне.

  6. Дождитесь завершения выполнения задачи.

Prometheus server

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

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

Установка

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

  1. В конфигурационный файл региона (по умолчанию /globals.d/REGION.yml) добавьте переменную enable_prometheus со значением yes. Пример конфигурации:

    enable_prometheus: "yes"

  2. Создайте новый пайплайн: Build > Pipelines > New Pipeline.

  3. В открывшемся окне добавьте переменную KOLLA_ARGS со значением -t prometheus.

  4. Запустите пайплайн, нажав кнопку New pipeline.

  5. Запустите задачу deploy в созданном пайплайне.

  6. Дождитесь завершения выполнения задачи.

  7. После завершения пайплайна должны быть развёрнуты и предварительно настроены: Prometheus, набор экспортёров, Alertmanager.

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

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

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

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

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

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

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

  1. В конфигурационном файле региона (по умолчанию /globals.d/REGION.yml) добавьте или измените переменную prometheus_cmdline_extras. Пример конфигурации с ограничением по длительности хранения данных 15 дней и без ограничения по размеру базы данных:

    prometheus_cmdline_extras: "--storage.tsdb.retention.time 15d --storage.tsdb.retention.size 0"

  2. Создайте новый пайплайн: Build > Pipelines > New Pipeline.

  3. В открывшемся окне добавьте переменную KOLLA_ARGS со значением -t prometheus.

  4. Запустите пайплайн, нажав кнопку New pipeline.

  5. Запустите задачу deploy в созданном пайплайне.

  6. Дождитесь завершения выполнения задачи.

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

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

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

  1. В конфигурационный файл региона (по умолчанию /globals.d/REGION.yml) добавьте переменную prometheus_use_victoriametrics_as_backend со значением yes. Пример конфигурации:

    prometheus_use_victoriametrics_as_backend: "yes"

  2. Создайте новый пайплайн: Build > Pipelines > New Pipeline.

  3. В открывшемся окне добавьте переменную KOLLA_ARGS со значением -t prometheus.

  4. Запустите пайплайн, нажав кнопку New pipeline.

  5. Запустите задачу deploy в созданном пайплайне.

  6. Дождитесь завершения выполнения задачи.

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

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

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

  • Должен быть развёрнут сервис VictoriaMetrics.

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

  1. Развёртывание VictoriaMetrics, если данный сервис ещё не был развёрнут. Подробнее о развёртывании VictoriaMetrics перед началом миграции см. в разделе Установка VictoriaMetrics.

  2. Миграция данных с помощью утилиты vmctl одним из способов:

    • Использование Prometheus remote read protocol. Данный способ менее трудозатратен, так как не требует включения административного API Prometheus.

    • Создание снапшота базы данных Prometheus и его импорт в VictoriaMetrics.

  3. Выключение Prometheus server.

Пошаговое руководство для каждого из способов миграции приведено ниже.

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

Установка VictoriaMetrics

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

  1. В конфигурационный файл региона (по умолчанию это globals.d/REGION.yml) добавьте переменную enable_victoriametrics со значением yes.

    enable_victoriametrics: "yes"

  2. Создайте новый пайплайн: Build > Pipelines > New Pipeline.

  3. В открывшемся окне добавьте переменную KOLLA_ARGS со значением -t victoriametrics.

  4. Запустите пайплайн, нажав кнопку New pipeline.

  5. Запустите задачу deploy в созданном пайплайне.

  6. Дождитесь завершения выполнения задачи.

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

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

  1. Скопируйте утилиту vmctl на хост.

    Данная утилита располагается на контроллерах в контейнерах victoriametrics_vmagent и victoriametrics_vmalert по пути /opt/victoriametrics/vmctl-prod. Копирование утилиты осуществляется следующей командой:

    $ podman cp victoriametrics_vmalert:/opt/victoriametrics/vmctl-prod

  2. Запустите миграцию командой:

    $ ./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 <путь к цепочке корневых сертификатов>

    Пример запуска команды:

    $ ./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

  3. В случае успешной миграции отобразится соответствующее сообщение со статистикой миграции.

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

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

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

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

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

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

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

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

  1. В конфигурационный файл региона (по умолчанию это /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 на этих контроллерах.

  2. Создайте снапшот базы данных 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

    Поскольку 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/.

  3. Скопируйте утилиту vmctl на хост. Данная утилита располагается на контроллерах в контейнерах victoriametrics_vmagent и victoriametrics_vmalert по пути /opt/victoriametrics/vmctl-prod. Копирование утилиты осуществляется следующей командой:

    $ podman cp victoriametrics_vmalert:/opt/victoriametrics/vmctl-prod

  4. Запустите миграцию командой:

    $ ./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 <путь к цепочке корневых сертификатов>

    По умолчанию процесс миграции идёт в два потока. Изменение количества потоков осуществляется с помощью флага 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

  5. В случае успешной миграции отобразится соответствующее сообщение со статистикой миграции.

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

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

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

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

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

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

Выключение Prometheus

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

  1. В конфигурационном файле региона (по умолчанию это /globals.d/REGION.yml) добавьте переменную enable_prometheus со значением no.

    enable_prometheus: "no"

  2. Создайте новый пайплайн: Build > Pipelines > New Pipeline.

  3. В открывшемся окне добавьте переменную KOLLA_ARGS со значением -t victoriametrics,prometheus,grafana.

  4. Запустите пайплайн, нажав кнопку New pipeline.

  5. Запустите задачу deploy в созданном пайплайне.

  6. Дождитесь завершения выполнения задачи.

  7. После завершения пайплайна вручную удалите на контроллерах Docker/Podman-контейнеры, Docker/Podman-volumes, System-сервисы и все конфигурационные файлы, связанные с Prometheus server.