VictoriaMetrics single-node на VDS: быстрый старт и импорт метрик

Если вам нужен быстрый и экономичный TSDB для метрик, VictoriaMetrics в режиме single-node — один из самых простых и мощных вариантов. Он совместим с Prometheus по API, потребляет меньше памяти на единицу кардинальности, держит высокий ingest rate и легко переносится между серверами. Ниже — установка на VDS, импорт истории, ретеншн, бэкапы и тюнинг производительности.

Зачем выбирать VictoriaMetrics single-node

Классический Prometheus отлично справляется со сбором и хранением на одном сервере, но при росте метрик становится чувствителен к памяти и диску. VictoriaMetrics (далее — VM) оптимизирован под высокую кардинальность и интенсивную запись, экономит RAM и CPU при сопоставимой или более высокой производительности. При этом VM понимает PromQL, совместим с большинством клиентов и давно используется как drop-in хранилище через remote_write.

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

Архитектура и совместимость с Prometheus

В минимальной конфигурации запускается один процесс VictoriaMetrics, который:

• слушает HTTP API (по умолчанию порт 8428);
• принимает данные по /api/v1/write (совместимо с Prometheus remote_write);
• отдаёт результаты запросов PromQL (/api/v1/query, /api/v1/query_range);
• экспортирует внутренние метрики на /metrics;
• поддерживает snapshot API для консистентных бэкапов.

Для сбора метрик оставьте существующий Prometheus как скрапер и включите remote_write в VM, либо используйте vmagent — лёгкий агент с конфигом в стиле Prometheus, который пишет напрямую в VM. Для алёртинга поверх VM обычно используют vmalert, а маршрутизацию уведомлений — Alertmanager. Для активных проверок сервисов будет уместна интеграция с Blackbox Exporter — см. материал про HTTP/TCP/ICMP проверки на базе Blackbox в обзоре «Blackbox-экспортера».

Требования к VDS и подготовка

Рекомендации зависят от скорости записи и кардинальности:

• CPU: 2–4 vCPU для начальных нагрузок (до сотен тысяч точек/с), 4–8 vCPU — с ростом.
• RAM: 4–8 ГБ для малого/среднего инжеста, 16+ ГБ — при высокой кардинальности и длинном ретеншне.
• Диск: SSD/NVMe, важны IOPS и latency. Размер — под ретеншн + 20–30% запас.
• ФС: ext4 или xfs, опция noatime снизит лишние записи.

Системные настройки под нагрузку:

• vm.swappiness=1 (минимизировать своппинг);
• fs.file-max и ulimit nofile повыше (например, 262144);
• для NVMe системный планировщик по умолчанию обычно оптимален.

Облачный VDS-сервер

Виртуальные серверы с быстрым запуском и гибкой конфигурацией от 390₽ / мес

Доступные локации

Россия Нидерланды

Смотреть тарифы

Установка: Docker или systemd

Вариант A: Docker (быстрый старт)

Самый быстрый способ — контейнер. Подготовьте каталог данных и запустите контейнер с ретеншном (в месяцах):

mkdir -p /var/lib/victoriametrics

docker run -d --name victoriametrics -p 8428:8428 -v /var/lib/victoriametrics:/victoria-metrics-data victoriametrics/victoria-metrics:latest -storageDataPath=/victoria-metrics-data -retentionPeriod=12

Параметр -retentionPeriod=12 — хранить 12 месяцев. Часто добавляют -search.maxQueryDuration=60s и -loggerLevel=INFO.

Вариант B: нативный binary + systemd

Удобно запускать VM как системную службу:

useradd --system --no-create-home --shell /usr/sbin/nologin victoriametrics

mkdir -p /opt/victoriametrics /var/lib/victoriametrics

chown -R victoriametrics:victoriametrics /opt/victoriametrics /var/lib/victoriametrics

Скопируйте бинарник victoria-metrics в /opt/victoriametrics/, сделайте исполняемым и добавьте unit:

[Unit]
Description=VictoriaMetrics single-node TSDB
After=network-online.target
Wants=network-online.target

[Service]
User=victoriametrics
Group=victoriametrics
ExecStart=/opt/victoriametrics/victoria-metrics -storageDataPath=/var/lib/victoriametrics -retentionPeriod=12 -httpListenAddr=:8428 -search.maxQueryDuration=60s -loggerLevel=INFO
Restart=on-failure
LimitNOFILE=262144
NoNewPrivileges=true
ProtectSystem=full
ProtectHome=true
ProtectControlGroups=true
ProtectKernelModules=true
ProtectKernelTunables=true
LockPersonality=true

[Install]
WantedBy=multi-user.target

systemctl daemon-reload

systemctl enable --now victoriametrics.service

Убедитесь, что процесс слушает порт 8428 и пишет данные в /var/lib/victoriametrics.

Открываем порт и базовая безопасность

Если включён файрвол, ограничьте доступ к API источниками из подсетей мониторинга. Для простоты — открытие порта всем (в проде ограничивайте!):

ufw allow 8428/tcp

Поверх API часто ставят обратный прокси с базовой авторизацией и ограничением методов, либо закрывают VM во внутренней сети. Если добавляете Nginx, поднимите client_max_body_size для bulk-импорта и таймауты проксирования. При публикации наружу включайте TLS — оформите SSL-сертификаты для домена и проксируйте на VM.

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Подключаем Prometheus через remote_write

Самый простой путь миграции на хранение в VictoriaMetrics — включить отправку метрик из существующего Prometheus. Пример фрагмента конфига:

remote_write:
  - url: http://VM_HOST:8428/api/v1/write
    queue_config:
      capacity: 20000
      max_shards: 8
      max_samples_per_send: 10000
    write_relabel_configs:
      - action: keep
        regex: .+
        source_labels: [__name__]

Где VM_HOST:8428 — адрес вашего инстанса. При многопользовательском доступе можно добавить vmauth.

vmagent как замена Prometheus-скрапера

Если не нужен локальный TSDB Prometheus и хотите лёгкий сбор, используйте vmagent. Он читает конфиг в стиле Prometheus и пишет напрямую в VM:

vmagent -promscrape.config=/etc/vmagent.yml -remoteWrite.url=http://VM_HOST:8428/api/v1/write

Конфиг /etc/vmagent.yml выглядит как prometheus.yml — переносите секции scrape_configs с минимальными изменениями.

Импорт исторических метрик

Чтобы не потерять историю, перенесите старые данные из Prometheus. Варианты:

1) Онлайн-миграция через remote_write

Оставляете существующий Prometheus и включаете remote_write. Новые точки окажутся в VM, старая история остаётся на диске Prometheus. Без остановки скрейпа — самый безопасный старт.

2) Импорт из snapshots/TSDB блоков через vmctl

vmctl умеет читать блоки TSDB Prometheus и импортировать в VM:

1. Сделайте снапшот данных Prometheus или остановите его на время копирования.
2. Скопируйте блоки на сервер с VM или к vmctl.
3. Запустите импорт, указав адрес VM и каталог блоков.

vmctl prometheus --vm-addr=http://VM_HOST:8428 --dir=/path/to/prometheus/blocks --concurrency=4

При больших объёмах задайте разумную --concurrency и следите за I/O.

3) Импорт форматов Prometheus/OpenMetrics

Для разовых подгрузок используйте bulk API импорта. Пример:

curl -X POST --data-binary @metrics.prom VM_HOST:8428/api/v1/import/prometheus

Крупные файлы шлите по частям и поднимайте лимиты реверс‑прокси, иначе поймаете 413.

Проверка запросов и совместимость PromQL

VM поддерживает большую часть PromQL и агрегаций. Для проверки прогоните типовые запросы: up, агрегаты по job, rate(), sum by(). Если ответы «не сходятся», проверьте лейблы (relabel) и диапазоны времени. Для продвинутой маршрутизации уведомлений пригодится подробный разбор в статье «Alertmanager: маршрутизация и шаблоны».

Ретеншн, компакшн и структура данных

Ключевая настройка — -retentionPeriod в месяцах: срок хранения и расход диска. Планируйте место под пиковую кардинальность и нужный горизонт истории. VM выполняет компакшн и хранит данные в сегментах, эффективно сжимая записи.

Полезные флаги:

• -search.maxQueryDuration — ограничение длительности запроса;
• -httpListenAddr — адрес и порт API;
• -loggerLevel — уровень логирования;
• -selfScrapeInterval — выключить самоскрапинг, если указать 0s.

Бэкапы и перенос хранилища

Для консистентного бэкапа используйте snapshot API. Он моментально создаёт срез данных и возвращает путь к каталогу снапшота, который можно забрать rsync-ом или запаковать:

curl -X POST VM_HOST:8428/snapshot/create

rsync -a /var/lib/victoriametrics/snapshots/SNAPSHOT_ID/ backup-host:/backups/vm/SNAPSHOT_ID/

Восстановление: остановить VM, заменить каталог данных содержимым снапшота, запустить снова. Следите, чтобы версия VM не была существенно старее формата данных.

Мониторинг самой VictoriaMetrics

Метрики на /metrics помогают контролировать ingest, latency и ошибки. Полезные метрики:

• vm_rows_inserted_total, vm_ingested_samples_total, vm_concurrent_inserts;
• vm_cache_entries и показатели hit/miss;
• vm_http_request_duration_seconds по хендлерам;
• process_open_fds, go_memstats_alloc_bytes.

Не забудьте Node Exporter на VDS для диска, I/O, CPU steal и latency — узкие места чаще в хранилище и сети.

Тюнинг производительности

Практические приёмы, которые часто помогают:

• Диск: NVMe и выделенный том под данные VM; noatime на ФС.
• Память: низкий vm.swappiness, контроль кардинальности (лишние лейблы быстро раздувают данные).
• CPU: увеличивайте max_shards в remote_write на стороне отправителей.
• Сеть: приближайте скрапер к VM; при высоком RTT повышайте буферы и размер пачек.
• Запросы: ограничивайте тяжёлые регекспы по лейблам, не отдавайте дашбордам гигантские диапазоны по умолчанию.

Типовые ошибки и их устранение

• 413 Request Entity Too Large при импорте через реверс‑прокси — поднимите client_max_body_size и таймауты либо шлите напрямую на порт VM.
• 429 Too Many Requests или задержки записи — уменьшите скорость импорта, аккуратно увеличьте параллелизм, проверьте I/O и CPU.
• Out of space — сократите -retentionPeriod или увеличьте том; держите запас под компакшн.
• Несовпадения PromQL — проверьте relabel и одинаковые шаги/диапазоны.
• Открытый в интернет API — ограничьте источники firewall’ом, используйте прокси с аутентификацией и TLS.

План миграции без простоя

1. Поднять VictoriaMetrics single-node на отдельном VDS и проверить здоровье.
2. Включить remote_write в Prometheus и убедиться, что новые данные попадают в VM.
3. Сделать тестовый снапшот Prometheus и прогнать импорт через vmctl на стенде.
4. Импортировать исторические блоки на прод, наблюдая ресурсы и ошибки.
5. Переключить источники графиков и алёртинга на VM (или vmalert) поэтапно.
6. Отключить хранение в Prometheus, оставив его как скрапер, либо заменить на vmagent.

Итоги

VictoriaMetrics single-node — быстрый способ получить производительное и экономичное хранилище метрик на VDS. Совместимость с Prometheus упрощает миграцию: подключаем remote_write, импортируем историю и продолжаем использовать привычные запросы и дашборды. При корректных лимитах, аккуратном ретеншне и внимании к диску такая установка выдерживает серьёзные нагрузки и остаётся простой в сопровождении.