Налаштування довгострокового зберігання Prometheus через VictoriaMetrics

Налаштування довгострокового зберігання Prometheus через VictoriaMetrics

Зазначимо: коли Prometheus починає споживати терабайти диска на короткому retention, а Thanos або Cortex здаються надлишковими, настає час VictoriaMetrics. Ця TSDB приймає remote_write від будь-якої кількості Prometheus, зберігає дані роками та витрачає в 5–10 разів менше пам’яті, ніж рідний TSDB. За даними офіційного репозиторію на GitHub, стиснення даних у VictoriaMetrics сягає 0.4–0.8 байта на точку — для кластера з 500 000 активних серій це економія диска до 80% порівняно з нативним Prometheus. MetricsQL повністю сумісний з PromQL, тому ваші дашборди Grafana продовжать працювати без змін.

Ми вже розгортали VictoriaMetrics для інфраструктур з 2 млн активних серій та запитним навантаженням 3000 QPS. Після переходу час запиту до сховища скоротився з 3 с до 50 мс, а витрати на диск впали в 5 разів. Зв'яжіться з нами, щоб отримати аналогічні результати.

Як налаштувати remote_write між Prometheus та VictoriaMetrics?

Конфігурація зводиться до двох кроків. Запускаємо VictoriaMetrics:

---
services:
  victoriametrics:
    image: victoriametrics/victoria-metrics:v1.101.0
    ports:
      - "8428:8428"
    volumes:
      - vm-data:/storage
    command:
      - -storageDataPath=/storage
      - -retentionPeriod=12
      - -httpListenAddr=:8428
      - -dedup.minScrapeInterval=15s

Додаємо remote_write у Prometheus:

remote_write: - url: http://victoriametrics:8428/api/v1/write queue_config: max_samples_per_send: 10000 max_shards: 8 

Усе. Жодних Sidecar, Store Gateway, Distributor, Compactor. VictoriaMetrics одразу отримує дані, одразу зберігає, одразу відповідає на запити. Один процес, один volume. У Grafana — datasource типу Prometheus, URL http://victoriametrics:8428.

Чому VictoriaMetrics ефективніший за Prometheus у зберіганні?

VictoriaMetrics використовує свій формат зберігання з кращою компресією: дані часових рядів з маленькою дельтою між точками стискаються до 0.4–0.8 байт на точку проти 1–2 байт у Prometheus TSDB. На рік метрик з 200k активних серій це кілька сотень гігабайт проти терабайтів у Prometheus. Додатково включена дедуплікація duplicate-даних при HA-зборі. Як говорить одна з документацій, VictoriaMetrics досягає таких показників за рахунок бітової компресії та алгоритму Gorilla.

Single-node чи кластер: що обрати?

Single-node підходить для більшості on-premise інфраструктур малого та середнього масштабу. Кластер потрібен, коли ingestion перевищує ~1M samples/sec або потрібна горизонтальна масштабованість сховища.

Кластерна версія VictoriaMetrics

Архітектура кластера:

vmagent (scraping / remote_write forwarding) |
vminsert (ingestion, stateless, N replicas) |
vmstorage (зберігання, StatefulSet, шардування за label hash) |
vmselect (query, stateless, N replicas)

Розгортається через Helm:

helm repo add vm https://victoriametrics.github.io/helm-charts/
helm install victoria-metrics-cluster vm/victoria-metrics-cluster \
  -f values.yaml \
  --namespace monitoring

Ключові параметри values.yaml:

---
vmstorage:
  replicaCount: 2
  persistentVolume:
    size: 500Gi
  extraArgs:
    retentionPeriod: "12"
    dedup.minScrapeInterval: "15s"
vminsert:
  replicaCount: 2
  extraArgs:
    replicationFactor: "2"
vmselect:
  replicaCount: 2
  extraArgs:
    dedup.minScrapeInterval: "15s"

replicationFactor: 2 — кожна точка даних записується на 2 vmstorage ноди. dedup.minScrapeInterval має збігатися на insert та select.

Що входить у роботу з впровадження?

1. Аудит поточної системи моніторингу (Prometheus, таргети, retention, навантаження).
2. Проектування архітектури: single-node або кластер, розрахунок storage.
3. Розгортання VictoriaMetrics (docker-compose, Helm або bare metal).
4. Налаштування remote_write на всіх Prometheus-інстансах.
5. Моніторинг VictoriaMetrics: дашборди Grafana, алерти (наприклад, низький free disk).
6. Міграція історичних даних з Prometheus за допомогою vmctl.
7. Навчання команди адмініструванню та типовим операціям.
8. Передача документації: схеми, runbook по інцидентах, конфігурації.

Терміни та вартість

Терміни: від 2 до 5 робочих днів залежно від складності (кількість інстансів, обсяг даних, необхідність міграції). Вартість розраховується індивідуально після аудиту. Замовте консультацію — ми оцінимо вашу інфраструктуру та підберемо оптимальне рішення. Наш досвід: 5+ років на ринку, десятки впроваджень VictoriaMetrics у production. Сертифіковані інженери гарантують надійність та продуктивність.

Приклад розрахунку економії

Критерії вибору VictoriaMetrics

Для більшості on-premise інфраструктур малого та середнього масштабу (до 5–10 Prometheus інстансів, до кількох мільйонів активних серій) single-node VictoriaMetrics — найпростіший та найефективніший шлях. Кластер рекомендується при необхідності горизонтального масштабування або високої відмовостійкості. VictoriaMetrics також чудово працює як заміна Thanos у хмарних середовищах (AWS, GCP, Yandex Cloud). Отримайте консультацію — ми допоможемо вибрати конфігурацію, розгорнемо систему та налаштуємо моніторинг від початку до кінця.