Мониторинг: Часть 5 — VictoriaMetrics

VictoriaMetrics — база данных временных рядов, совместимая с Prometheus. Её используют как долговременное хранилище метрик для Prometheus или целиком вместо него — вместе со сборщиком vmagent и модулем оповещений vmalert. Основная редакция распространяется под лицензией Apache 2.0; часть возможностей (например, понижение детализации старых данных и разные сроки хранения для разных наборов данных) доступна только в платной редакции Enterprise.

Зачем она нужна

Prometheus хранит данные на локальном диске одного сервера, по умолчанию 15 дней. Когда нужно хранить метрики год, собирать данные с нескольких Prometheus в одном месте или экономить диск, появляется отдельное хранилище. VictoriaMetrics принимает данные по протоколу remote write, отвечает на запросы через тот же HTTP API, что и Prometheus, поэтому Grafana подключает её как обычный источник типа Prometheus без переделки панелей.

Редакции и режимы работы

• Single-node — один исполняемый файл, который принимает, хранит и отдаёт данные. Подходит для большинства небольших и средних установок и проще всего в обслуживании.
• Кластер — отдельные компоненты vminsert (приём), vmstorage (хранение) и vmselect (запросы). Масштабируется горизонтально, поддерживает несколько арендаторов на одной установке.

MetricsQL

Язык запросов VictoriaMetrics называется MetricsQL. Он обратно совместим с PromQL: панели Grafana, построенные для Prometheus, работают без изменений. Сверх этого MetricsQL умеет:

• не указывать окно в квадратных скобках — rate(node_network_receive_bytes_total) подберёт его сам по шагу запроса и интервалу сбора;
• выносить повторяющиеся части запроса в шаблоны WITH (...);
• использовать дополнительные функции: range_median, range_linear_regression, range_trim_outliers и другие.

Стек без Prometheus: vmagent, VictoriaMetrics и vmalert

Схема, в которой все компоненты — от VictoriaMetrics:

1. vmagent на сервере сбора читает привычный prometheus.yml (разделы global и scrape_configs), опрашивает цели и отправляет данные в хранилище. Если хранилище недоступно, он складывает данные в буфер на диске и досылает после восстановления связи.
2. VictoriaMetrics single-node хранит данные и отвечает на запросы на порту 8428.
3. vmalert выполняет правила оповещений и правила записи в формате Prometheus и отправляет сработавшие оповещения в Alertmanager.
4. Grafana подключается к VictoriaMetrics как к источнику Prometheus.

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

# хранилище: данные в /var/lib/victoria-metrics, хранить 12 месяцев
victoria-metrics -storageDataPath=/var/lib/victoria-metrics -retentionPeriod=12

# сборщик: цели из prometheus.yml, отправка в хранилище
vmagent -promscrape.config=/etc/vmagent/prometheus.yml \
  -remoteWrite.url=http://localhost:8428/api/v1/write

# оповещения: правила в формате Prometheus, уведомления через Alertmanager
vmalert -rule='/etc/vmalert/rules/*.yml' \
  -datasource.url=http://localhost:8428 \
  -notifier.url=http://localhost:9093 \
  -remoteWrite.url=http://localhost:8428 \
  -remoteRead.url=http://localhost:8428

Параметр -retentionPeriod задаёт срок хранения; число без суффикса означает месяцы, по умолчанию хранится один месяц. Можно указывать и другие единицы, например -retentionPeriod=90d. Флаги -remoteWrite.url и -remoteRead.url у vmalert нужны, чтобы сохранять состояние оповещений и результаты правил записи; для одних только оповещений достаточно -datasource.url и -notifier.url.

Шаблон пути в -rule берут в кавычки, иначе оболочка сама раскроет его в список файлов. Правила оповещений из Prometheus переносятся без изменений: vmalert понимает тот же формат файлов.

Если Prometheus уже работает

Переходить целиком не обязательно. В prometheus.yml добавляют отправку копии данных:

remote_write:
  - url: http://192.0.2.30:8428/api/v1/write

Prometheus продолжает работать как прежде, а в VictoriaMetrics накапливается долгая история. Срок локального хранения в Prometheus после этого можно сократить.

Достоинства

• Экономия диска и памяти. Разработчики и многие пользователи отмечают, что тот же объём метрик занимает заметно меньше места, чем в Prometheus; точный выигрыш зависит от данных, его стоит проверить на своих метриках.
• Простота single-node. Один процесс, один каталог с данными, резервное копирование через снимки (/snapshot/create) и утилиту vmbackup.
• Совместимость. Экспортеры, панели Grafana и правила Prometheus работают без изменений.
• Приём данных в разных форматах: remote write Prometheus, InfluxDB line protocol, Graphite, OpenTSDB.

Недостатки

• Отдельные компоненты. VictoriaMetrics — хранилище; сбор, оповещения и визуализация — это vmagent, vmalert, Alertmanager и Grafana, каждый со своей конфигурацией.
• Часть функций только в Enterprise. Прежде чем строить схему, стоит сверить нужные возможности со списком Enterprise-функций в документации.
• Небольшие расхождения с PromQL. Совместимость обратная, но отдельные функции ведут себя иначе; сложные запросы при переносе стоит проверить.

Типичные ошибки

• Не задан срок хранения. По умолчанию данные хранятся месяц, и при переходе с «хранилища для долгой истории» это становится неприятной неожиданностью.
• Порт 8428 открыт наружу. API хранилища позволяет и читать, и записывать, и удалять данные. Доступ ограничивают сетью или обратным прокси с авторизацией.
• Буфер vmagent на маленьком диске. При долгой недоступности хранилища буфер заполняет диск сервера сбора; его размер ограничивают параметром -remoteWrite.maxDiskUsagePerURL.
• Высокая кардинальность. Как и в Prometheus, уникальные значения в метках быстро увеличивают число рядов и потребление ресурсов.