VictoriaMetrics — открытая СУБД для временных рядов, написанная на Go и совместимая с Prometheus API и языком запросов PromQL. Её выбирают, когда один Prometheus с сотнями тысяч активных серий уже не помещается в память, а запросы за неделю выполняются десятки секунд. VictoriaMetrics компактнее хранит данные, умеет принимать remote_write и отдавать результаты в Grafana без переделки дашбордов. Разберём установку single-node-версии, сбор метрик через vmagent, перенос истории, алерты и диагностику.

Когда миграция оправдана

Prometheus — эталонная реализация, но он не предназначен для долгого хранения и горизонтального масштабирования: одна нода, локальный диск, ограниченный объём памяти. VictoriaMetrics решает три практические задачи.

  • Долгое хранение. Сжатие позволяет держать месяцы метрик на том же диске, где Prometheus хранил бы недели.
  • Высокая кардинальность. Метки с идентификаторами контейнеров и пользователей не приводят к мгновенному OOM.
  • Единый бинарник. Нет отдельной БД, отдельного remote storage adapter и зоопарка компонентов.

Важно: VictoriaMetrics не заменяет экспортёры. node_exporter, mysqld_exporter и прочие остаются, меняется только приёмник и хранилище. Отдельно стоит учитывать размер: база хранит образцы плотнее, но не бесконечно. Перед покупкой диска оцените прирост серий в месяц и умножьте на коэффициент сжатия, который зависит от длины имён метрик и количества уникальных значений.

Установка и запуск

В репозиториях Debian и Ubuntu пакета нет, поэтому берём официальный релиз с GitHub. Скрипт ниже определяет последний тег через API и скачивает архив для amd64.

TAG=$(curl -s https://api.github.com/repos/VictoriaMetrics/VictoriaMetrics/releases/latest | grep -oP '"tag_name": "\K[^"]+')
curl -LO "https://github.com/VictoriaMetrics/VictoriaMetrics/releases/download/$TAG/victoria-metrics-linux-amd64-$TAG.tar.gz"
tar -xzf victoria-metrics-linux-amd64-$TAG.tar.gz
sudo install -m 0755 victoria-metrics-prod /usr/local/bin/victoria-metrics

Создаём системного пользователя и каталог данных, затем unit.

sudo useradd -r -s /usr/sbin/nologin victoriametrics
sudo mkdir -p /var/lib/victoria-metrics
sudo chown victoriametrics:victoriametrics /var/lib/victoria-metrics
[Unit]
Description=VictoriaMetrics single node
After=network-online.target

[Service]
User=victoriametrics
ExecStart=/usr/local/bin/victoria-metrics \
  -storageDataPath=/var/lib/victoria-metrics \
  -retentionPeriod=12 \
  -httpListenAddr=:8428
Restart=on-failure
LimitNOFILE=1048576

[Install]
WantedBy=multi-user.target

Флаг -retentionPeriod=12 означает двенадцать месяцев: без суффикса значение считается в месяцах. Для теста хватит 2 ГБ RAM и 20 ГБ диска, для продакшена считайте ресурсы по числу активных серий. После systemctl daemon-reload и systemctl enable —now victoria-metrics проверяем http://сервер:8428/health — в ответе должно быть OK.

Сбор метрик через vmagent

Установленный node_exporter отдаёт метрики на порту 9100. Чтобы VictoriaMetrics их забирала, нужен vmagent — он входит в тот же архив. Конфиг почти совпадает с prometheus.yml.

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: node
    static_configs:
      - targets: ["127.0.0.1:9100"]
sudo install -m 0755 vmagent-prod /usr/local/bin/vmagent
vmagent -promscrape.config=/etc/vmagent/scrape.yml \
  -remoteWrite.url=http://127.0.0.1:8428/api/v1/write \
  -remoteWrite.tmpDataPath=/var/lib/vmagent

tmpDataPath обязателен: при недоступности хранилища vmagent складывает данные в очередь на диске и не теряет их при перезапуске. Если Prometheus уже работает и вы не готовы сразу менять схему, добавьте в prometheus.yml блок remote_write с тем же адресом — оба источника будут писать в одну базу.

Перенос истории и проверка данных

Для миграции старых данных используется vmctl. Сначала создаём snapshot в Prometheus, предварительно включив admin API флагом —web.enable-admin-api.

curl -X POST http://127.0.0.1:9090/api/v1/admin/tsdb/snapshot
sudo vmctl prometheus --prom-snapshot=/var/lib/prometheus/snapshots/ID \
  --vm-addr=http://127.0.0.1:8428

После импорта проверяем, что серии видны, а Grafana получает данные. В качестве источника добавьте Prometheus с URL http://127.0.0.1:8428 — отдельный плагин не нужен.

curl -s 'http://127.0.0.1:8428/api/v1/query' --data-urlencode 'query=up' | jq '.data.result | length'
curl -s 'http://127.0.0.1:8428/api/v1/labels' | jq '.data'

Одна нода или кластер

Single-node-версия обслуживает десятки миллионов активных серий и терабайты данных, если хватает диска и памяти. Кластер из vmstorage, vminsert и vmselect нужен, когда требуется отказоустойчивость или запись из нескольких дата-центров. Начинать с кластера в домашней лаборатории почти всегда — ошибка: три компонента добавляют хлопот, но не ускоряют запросы.

  • vminsert принимает данные по remote_write и распределяет их по vmstorage.
  • vmselect выполняет запросы и собирает части ответа.
  • vmstorage хранит ряды; его нельзя масштабировать вниз без потери данных.

Запросы и алерты

MetricsQL — надмножество PromQL, поэтому привычные выражения работают без изменений. Проверить их удобно через API, а не через графический интерфейс.

100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)
histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))
node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100

Алерты удобно держать в vmalert: он читает правила в формате Prometheus и сам пишет состояние алертов обратно в базу. Правила стоит хранить в git и проверять на стенде перед выкаткой.

groups:
  - name: node
    rules:
      - alert: HighCPU
        expr: 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "CPU выше 85% на {{ $labels.instance }}"
vmalert -rule=/etc/vmalert/rules.yml \
  -datasource.url=http://127.0.0.1:8428 \
  -notifier.url=http://127.0.0.1:9093 \
  -remoteWrite.url=http://127.0.0.1:8428

Диагностика и обслуживание

У VictoriaMetrics есть несколько полезных эндпоинтов. /api/v1/status/tsdb показывает топ серий по числу меток — это первый инструмент при росте памяти. /api/v1/status/active_queries помогает поймать тяжёлый запрос. Логи смотрите через journalctl -u victoria-metrics.

Рост памяти чаще связан не с объёмом данных, а с кардинальностью: миллион уникальных значений метки user_id съедает кэш быстрее, чем терабайт аккуратных метрик. Начинайте с аудита меток, а не с увеличения RAM. Если серии растут равномерно, диск кончится предсказуемо, и это лучший сценарий.

curl -s http://127.0.0.1:8428/api/v1/status/tsdb | jq '.data.seriesCountByLabelValuePair[0:5]'
curl -s http://127.0.0.1:8428/metrics | grep -E 'vm_rows|vm_cache_size'
sudo journalctl -u victoria-metrics -n 50 --no-pager

Чек-лист перед продакшеном:

  • Задайте -search.maxSeries и -search.maxSamplesPerQuery, чтобы один запрос не съел всю память.
  • Включите дедупликацию -dedup.minScrapeInterval=15s, если пишут два vmagent.
  • Настройте vmbackup по расписанию и проверьте восстановление на тестовом хосте.
  • Ограничьте число меток -maxLabelsPerTimeseries и следите за «тяжёлыми» сериями.

Итог

VictoriaMetrics даёт предсказуемое потребление ресурсов и совместимость с Prometheus, поэтому миграция сводится к замене приёмника и источника в Grafana. Начните с одной ноды, подключите vmagent, перенесите историю через vmctl и только после этого усложняйте схему. Для большинства домашних и небольших корпоративных инсталляций single-node-версии достаточно на годы вперёд.

Насколько публикация полезна?

Нажмите на звезду, чтобы оценить!

Средняя оценка 0 / 5. Количество оценок: 0

Оценок пока нет. Поставьте оценку первым.

Поделиться: Telegram ВКонтакте