Два года на VictoriaMetrics + Grafana + Loki: что прижилось, где болит

Примерно два года назад мы начали переводить наших managed-клиентов с классической связки Zabbix + Prometheus на стек VictoriaMetrics + Grafana + Loki. Не потому что Zabbix плохой - Zabbix 7 был вполне годным, и сейчас восьмая версия с anomaly detection выглядит интересно. Просто на горизонте в несколько кластеров и сотен сервисов Prometheus начинал задыхаться, а VictoriaMetrics давала заметно лучшую компактность хранения при том же объёме метрик. Пора подвести промежуточные итоги.

Что прижилось

VictoriaMetrics как хранилище метрик. Здесь без оговорок - работает. Сжатие лучше Prometheus-а, single-node держит нагрузку, которую раньше тянул только Prometheus в федерации. Cluster-режим подняли на двух проектах с особенно активными сервисами - там это оправдано. На остальных single-node и не думает потеть. Удобная вещь - vmbackup/vmrestore: бэкапы и восстановление без танцев с iptables и снапшотами.

Grafana как единый фронт. Три источника данных в одном дашборде - VictoriaMetrics, Loki, Tempo - это то, ради чего весь стек вообще имеет смысл. Когда дежурный видит spike latency на графике и кликом открывает связанные логи за тот же интервал - это реальное ускорение диагностики, а не демо с конференции. Grafana On-Premise держится стабильно, обновления выходят регулярно, ничего принципиально сломанного в последних версиях не попадалось.

Loki для логов. С оговорками, но в целом - да, прижился. Модель «только индекс по лейблам, остальное в объекте» работает при правильных лейблах. Если лейблы сделаны плохо - и запросы медленные, и объём индекса раздутый. Мы набили шишки на первых инсталляциях: лейбл pod_name с уникальными значениями на каждый под - почти то же самое, что вообще без индекса. Переделали на namespace, app, component - стало нормально.

Где всё ещё больно

Alertmanager-маршрутизация - самое больное место. Логика маршрутизации в yaml-конфиге Alertmanager устроена так, что при попытке описать нетривиальные правила («этот алерт - в дежурный канал, но только ночью и только если severity=critical, а если днём - просто в общий чат») быстро получается нечитаемая матрёшка из routes, matchers и continue: true. Мы сделали несколько итераций, написали внутреннюю документацию с примерами - помогло, но каждый новый человек в команде всё равно спотыкается об это место.

Cardinality под нагрузкой. VictoriaMetrics справляется лучше Prometheus-а, но высокая cardinality метрик всё равно бьёт по памяти. На одном проекте разработчики добавили в метрики лейбл user_id - и мы получили несколько миллионов уникальных time series за сутки. VictoriaMetrics не упала, но потребление памяти выросло неприятно. Пришлось добавить в процесс code review отдельный чеклист на лейблы метрик. Это организационная проблема, не техническая, но она реальна.

Loki и долгосрочное хранение. Loki хранит данные хорошо, пока объём умеренный. Когда логов много и retention длинный - появляются вопросы к стоимости хранения и скорости compaction. На двух проектах с compliance-требованиями, где логи надо хранить год, мы пришли к тому, что Loki держит горячий период (30-60 дней), а холодный архив идёт в object storage через конфигурацию storage и compactor. Работает, но настройка не тривиальная.

Отсутствие нормальной RBAC в Grafana на уровне дашбордов. Enterprise-функции Grafana с fine-grained permissions нам недоступны - клиенты не хотят платить за подписку поверх On-Premise. Дефолтная ролевая модель Grafana грубая: либо viewer для всего, либо editor почти для всего. Для клиентов, где разные команды должны видеть только свои namespace-ы, мы используем Organizations - несколько изолированных «организаций» внутри одного Grafana. Работает, но это костыль, и поддерживать одинаковые дашборды в нескольких Organizations - боль.

Почему не SaaS

Нас иногда спрашивают - почему мы не перевели хотя бы некритичные сервисы на какой-нибудь облачный мониторинг? Дешевле же, меньше операционной нагрузки.

Ответ несложный. Во-первых, у большинства наших клиентов данные в метриках и логах - чувствительная информация: имена хостов, внутренние адреса, параметры запросов, иногда персональные данные в трейсах. Отправлять это в иностранный SaaS - не вариант, это не про паранойю, а про compliance. Отечественных SaaS-мониторингов с нормальным Prometheus-совместимым API и Loki-совместимым приёмником пока нет в том виде, который нас устроил бы.

Во-вторых, операционная нагрузка на поддержку стека оказалась меньше, чем мы ожидали. VictoriaMetrics не требует постоянного ухода. Grafana обновляется раз в несколько месяцев. Основная работа - это именно настройка дашбордов, алертов и разбор проблем с cardinality. Это осмысленная работа, а не просто «держи инфраструктуру живой».

Что с Zabbix

Zabbix мы не выкинули. На нескольких проектах он остался как основной источник алертов по инфраструктурным метрикам - хост недоступен, диск заканчивается, процесс упал. Zabbix 8 с встроенным anomaly detection выглядит как шаг вперёд, но мы пока смотрим на это осторожно: anomaly detection хорошо работает на предсказуемых паттернах, а на нагрузке с большой дисперсией даёт ложные срабатывания. Будем тестировать.

Для нас Zabbix и VictoriaMetrics/Grafana - не конкуренты. Zabbix хорош для агентного мониторинга хостов, network devices, windows-серверов с нестандартными метриками. VictoriaMetrics + Grafana - для cloud-native сервисов, где метрики отдаются через /metrics endpoint. На большинстве проектов оба стека работают параллельно, и дежурный смотрит в Grafana, потому что там всё в одном месте.

Промежуточный итог такой: стек рабочий, производительный и поддерживаемый. Боль не в инструментах, а в организации данных и правилах работы с ними. Это, наверное, честный результат для двух лет эксплуатации.