Мультитенантность в VictoriaMetrics, VictoriaLogs и Grafana: механизмы изоляции клиентов и проблемы архитектуры

Источник
Мультитенантность в VictoriaMetrics, VictoriaLogs и Grafana: как мы изолируем клиентов и что ломается

Команда Voltir реализовала мультитенантную архитектуру на базе единого стека VictoriaMetrics, VictoriaLogs, Grafana и vmalert для обслуживания множества клиентов. Изоляция данных строится вокруг числового идентификатора account_id, который используется в путях запросов VictoriaMetrics (/insert//...) и передается через заголовки для VictoriaLogs. Доступ к хранилищам защищен через nginx, который валидирует Bearer-токены и определяет владельца запроса перед проксированием. В Grafana для каждого клиента создается отдельная организация, где пользователи имеют роли Viewer или Editor, но не Org Admin, чтобы предотвратить изменение источников данных и доступ к чужим метрикам. Алертинг централизован: один vmalert читает файлы правил всех клиентов, а изоляция обеспечивается фильтрами по vm_account_id внутри групп правил.

Критическая уязвимость была обнаружена при тестировании: ошибка в синтаксисе правила одного клиента (например, опечатка в длительности) приводила к тому, что vmalert переставал применять обновления и останавливал алертинг для всех остальных клиентов. Проблема усугублялась тем, что платформа проглатывала ошибки при перезагрузке конфигурации, а глобальный процесс vmalert мог падать из-за OOM или зависания, блокируя мониторинг всего сервиса. Для решения проблемы была внедрена строгая валидация на входе API и проверка сгенерированных файлов перед заменой, а также атомарная запись через временные файлы. Дополнительно каждый запрос к хранилищу теперь включает явный фильтр по аккаунту, предотвращая чтение чужих данных даже при прямом обращении.

Управление жизненным циклом клиентов выявило проблему накопления «мусора»: при удалении тенанта оставались сиротские организации в Grafana, файлы правил в каталоге vmalert и данные в хранилищах, что приводило к перегрузке ресурсов и падению тестовых барьеров. Изначально использовалась страховочная процедура с SQL-очисткой, но она создавала рассинхронизацию между базой данных и состоянием Grafana. В итоге была создана единая модульная система очистки, которая удаляет все внешние артефакты клиента сразу и проводит фоновую сверку остатков раз в час. Также были устранены аномалии в VictoriaMetrics, когда удаленные аккаунты продолжали отображаться в админ-панели до конца срока хранения, а метрики доступности хостов создавали лишние серии после физического удаления данных.

Текст подготовлен нейросетью Loople по материалам источника.

Читайте также

Похожие новости

ВКонтакте перевел продукт на сервисную архитектуру при ежедневной аудитории 65 млн человек

Как ВКонтакте разделила продукт на сценарии, создала платформу разработки и перевела веб на SPA, пока соцсетью продолжали пользоваться кажд…

Поиск по Loople

Назад