Per-tenant мониторинг: где общий контур теряет сигнал
Единый контур наблюдения показывает здоровье сервиса в среднем. Пока сотня арендаторов работает штатно, а у одного растёт время ответа на критичном запросе, сводный график остаётся в зелёной зоне — усреднение съедает деградацию отдельного клиента. Проблема всплывает не из алерта, а из письма арендатора: это уже не наблюдение, а разбор по факту.
Причина в том, как устроен сбор данных. Метрики помечены именем сервиса, экземпляра или узла, но не арендатора, поэтому разделить запросы по клиентам на этапе выборки нельзя. Логи уходят в общий поток без обязательного признака тенанта, а трассировка теряет привязку на первом же асинхронном переходе. Так и появляются слепые зоны метрик: цифры есть, а ответить, у кого именно просело, нечем.
Цена такой схемы — время. Деградация сервиса обнаруживается по жалобам, дальше инженер вручную сопоставляет логи, длительность ответов и идентификаторы клиентов, чтобы оценить масштаб. На разбор уходят часы, и часть арендаторов успевает уйти раньше, чем мы вообще узнаём о проблеме.
Per-tenant мониторинг снимает это ограничение: метка арендатора становится обязательной в метриках, логах и трассировке, а раздельные потоки телеметрии позволяют задать пороги чувствительности на каждого клиента отдельно. Ниже разбираем, как выстроить такой контур и что он даёт на практике.
Что даёт изоляция метрик и логов: измеримый эффект
Изоляция метрик начинается с того, что каждая серия и каждая запись лога получает обязательную метку тенанта. Prometheus с такой схемой меток позволяет строить выборку по одному клиенту, а не вычитать его из общего потока — разделение логов и метрик идёт по одному и тому же ключу, и он же становится границей для лимитов, сроков хранения и прав доступа. Пока метки нет, любой инцидент расследуется по общему графику, где всплеск одного арендатора выглядит как деградация всего сервиса.
Эффект измерим в трёх величинах. Скорость локализации инцидента сокращается с часов до минут: дежурный сразу видит, у какого тенанта выросла доля ошибок и на какой операции, вместо последовательного перебора клиентов. Доля пропущенных сбоев падает, потому что пороги считаются от базовой линии каждого тенанта, а не от усреднённой по всем.
Шум в оповещениях перестаёт быть фоном: правило, привязанное к тенанту, срабатывает на его аномалию и молчит, когда соседний клиент штатно уходит в пик. Доступность сервиса считается отдельно для каждого арендатора, поэтому деградация одного не растворяется в общей цифре и не искажает картину для остальных.
- локализация инцидента — от часов к минутам за счёт выборки по метке;
- доля ложных срабатываний — в разы ниже при порогах на тенант;
- доступность измеряется по каждому клиенту, а не в среднем по сервису;
- хранение и лимиты настраиваются индивидуально, реестр не растёт линейно от числа арендаторов.
Режимы сбора: общий контур, полная изоляция, гибрид
Три схемы различаются не инструментом, а тем, где проходит граница между инфраструктурой тенанта и общим контуром. От этого зависит, сколько стоит подключить нового клиента и что именно видно при разборе сбоя.
| Схема | Когда подходит | Ограничения |
|---|---|---|
| Общий контур | Десятки тенантов, ровные требования к разделению данных, нужен один экран по всем | Метка тенанта в запросе: ошибка в ней смешивает чужие данные, а срок хранения подстраивается под самый требовательный тенант |
| Полная изоляция | Жёсткие требования к разделению данных, разный темп релизов у тенантов | Свой агент сбора и своё хранилище на каждого: растёт число точек отказа и объём сопровождения |
| Гибрид | Общие метрики инфраструктуры плюс изолированные логи и чувствительные показатели | Две модели доступа и два места поиска — нужна дисциплина в правилах маршрутизации |
Гибридная схема берёт верх там, где инфраструктурные метрики одинаковы у всех, а данные о нагрузке и содержимое логов обязаны лежать отдельно. Ограничение — правила маршрутизации приходится поддерживать вручную: стоит отнести новую метрику не в тот контур, и она либо утечёт в общее хранилище, либо потеряется.
Схему фиксируют до первого клиента. Переезд с общего контура на полную изоляцию — это пересборка агентов сбора и заново собранная история метрик, а не смена настройки.
Порядок внедрения: аудит, схема, разметка, проверка
Внедрение per-tenant мониторинга — это последовательность шагов, где каждый заканчивается проверяемым артефактом: реестром источников, схемой меток, правилом маршрутизации, отчётом о тестах. Порядок такой, что следующий этап опирается на результат предыдущего — поэтому разметка не расходится с реальностью через месяц после запуска.
-
Инвентаризация источников. Собираем все места, где рождаются метрики и логи: сервисы, очереди, базы, фоновые задачи, пограничные узлы. На выходе — реестр с владельцем источника, частотой и способом сбора; он же становится перечнем для приёмки.
-
Разметка потока метрик. Вводим обязательные метки — тенант, среда, сервис — и проверяем их на уровне сбора, а не в коде приложения. Забыть метку становится технически невозможно, иначе часть графиков окажется «общей» и бесполезной при разборе инцидента.
-
Маршрутизация логов. Записи переводим в структурный вид с атрибутом тенанта, дальше правила раскладывают их по хранилищам и срокам хранения. Крупный заказчик не видит чужих записей в поиске и не оплачивает их хранение.
-
Доступы и оповещения. Для каждого тенанта описываем, кто и что видит, отдельно — пороги оповещений и маршрут дежурного. Проверяем, что сигнал уходит только по своему контуру.
-
Проверка изоляции. Прогоняем попытки достать чужие данные через запросы, панели мониторинга, выгрузки и оповещения. Фиксируем отчёт: сколько путей проверено, какие закрыты, что осталось в исключениях и на какой срок.
-
Передача контура. Отдаём документацию, шаблоны панелей и правил, регламент подключения нового тенанта и разбор типовых сбоев. Дальше расширение идёт без нас: арендатор подключается по инструкции за один проход.
Комплект поставки: конфигурации, схемы, регламенты
Всё, что мы настраиваем, остаётся в вашем контуре и вашем репозитории: конфигурации, панели, правила — не в закрытых кабинетах и не в переписке. Комплект поставки рассчитан на дежурного инженера, который не участвовал во внедрении: он должен разобраться в системе по документации, а не по чужой памяти. Разметка по тенантам сквозная — от источника метрики до канала уведомления, поэтому разбор инцидента не превращается в поиск владельца данных.
- Конфигурации наблюдения как код: сборщики метрик, агенты логов, правила хранения, лимиты на кардинальность и разметка тенантов — в репозитории, с историей изменений и обязательным ревью.
- Схемы маршрутизации: карта «источник → метка тенанта → правило → канал уведомления», включая маршруты сводных сигналов и режим подавления дублей при массовом сбое.
- Разграничение доступа: роли и области видимости — команда заказчика видит только свой тенант, дежурный получает сводку; плюс связка с корпоративной аутентификацией и журнал доступа к данным.
- Регламент дежурства: уровни критичности, окна эскалации, шаблоны уведомлений, порядок действий при ложном срабатывании и при пропаже данных от тенанта.
- Панели наблюдения: шаблоны «на тенант» и сводные с автоматической подстановкой арендатора, отдельно — панель здоровья самой системы наблюдения.
- Карта хранения: где лежат метрики и логи, сроки хранения по типам данных, поведение при переполнении и порядок выгрузки по одному тенанту для разбора инцидента.
- Журнал передачи: разбор архитектуры с вашей командой, чек-лист дежурного на первые смены, список известных ограничений и план развития — цели по доступности и синтетические проверки по тенантам.
Кейс: один сервис ронял общий контур наблюдения
Заказчик — платформа с несколькими десятками арендаторов на общей инфраструктуре. Наблюдение было устроено монолитно: один приёмник метрик, один сборщик логов и общий набор правил оповещений на всех арендаторов.
Первый крупный сбой дал арендатор с нетипичным профилем нагрузки — приложение плодило динамические метки, число активных серий росло скачками. Приёмник метрик уходил в перезапуск, и вместе с ним пропадали дашборды и срабатывали алерты у всех остальных арендаторов, включая полностью здоровых. Дежурный получал шквал срабатываний, семь из десяти оказывались ложными, а разбор инцидента растягивался на 4-6 часов: сначала приходилось отделять чужой шум от своей аварии.
Что изменили: разделили потоки метрик и логов по арендаторам, ввели отдельные лимиты на число серий и частоту сбора, разнесли правила оповещений и маршрутизацию по владельцам, сроки хранения задали раздельно для тяжёлых и лёгких источников. Визуализацию оставили общей — Grafana с переключением источника по арендатору, без десятков дублирующих панелей.
Метрики до и после
| Показатель | До | После |
|---|---|---|
| Ложные оповещения | 7 из 10 | 1 из 10 |
| Время разбора инцидента | 4-6 часов | 30-40 минут |
| Дашборды при пике у одного арендатора | отказ у всех | деградация только у него |
| Объём активных серий | неуправляемый рост | снизился вчетверо |
Устранённый класс отказов — каскадный: отказ одного арендатора больше не уносит наблюдаемость всего контура, а его нагрузку можно ограничить точечно, не трогая остальных.
Per-tenant мониторинг против общей панели: в чём разница?
Разграничение доступа и разделение наблюдения решают разные задачи, и на общей панели их легко перепутать. В первом случае все метрики лежат в одном хранилище, а роль пользователя лишь сужает выборку — тенант видит свои серии, но правила оповещения, агрегаты и глубина хранения остаются общими. Во втором случае у каждого тенанта свой контур наблюдения целиком.
Общая панель наблюдения обычно строится на одном инструменте визуализации — Grafana — и различается только наборами прав доступа. Этого мало, когда один клиент даёт всплеск: в общей серии он сглаживается средним, и дежурный узнаёт о проблеме у конкретного тенанта последним. Порог оповещения, выставленный по усреднённой картине, либо молчит, либо срабатывает на чужой шум. Заодно растёт кардинальность метрик, и запрос по одному тенанту начинает стоить как запрос по всем.
Граница изоляции проходит не по правам на метрики, а по возможности влиять на чужое наблюдение. Права на метрики — это фильтр на чтение: они ограничивают, что тенант увидит, но не мешают ему забить хранилище своими сериями или утопить общий канал уведомлений. Реальное разделение означает отдельные представления и правила оповещения на каждого тенанта, квоты на число серий и срок хранения, раздельную маршрутизацию уведомлений и свои пороги срабатывания.
На практике это даёт предсказуемое время обнаружения: инцидент у конкретного клиента виден за минуты, а не после того, как его заметит кто-то из соседей по общей панели. Отчёт по доступности тенанта собирается без ручной фильтрации, а перегрузка одного контура не искажает картину у остальных.
Что уточняют перед разметкой потока метрик
Перед разметкой потока метрик уточняем у заказчика, кто и как читает данные: дежурный инженер, поддержка или сам клиент. От этого зависит схема меток, срок хранения и то, какие оповещения уходят в дежурную смену.
Не вырастет ли объём хранения из-за разбивки по тенантам?
Разбивка добавляет одну размерность к метрике, и сама по себе она почти не влияет на объём. Рост даёт кардинальность меток внутри тенанта — идентификаторы запросов, адреса пользователей, произвольные строки. Поэтому на разметку отправляем только те признаки, по которым реально фильтруют и строят оповещения, а служебные значения уходят в агрегат без метки. Срок хранения задаём отдельно для детальных и агрегированных рядов — детальные живут коротко, сводки долго и занимают немного.
Обязательно ли разделять весь поток целиком?
Нет. Частичное разделение работает лучше тотального: метку тенанта получают два-три десятка метрик, по которым считают доступность и ошибки, остальное остаётся в общем агрегате. Так заказчик видит картину по каждому клиенту там, где это нужно для дежурства, и не платит объёмом хранения за разбивку всего подряд.
Что будет с уже собранными данными?
Миграцию делаем без остановки сбора: новые метки пишутся параллельно со старыми, дашборды переводятся на новую схему, старая доживает свой срок хранения и уходит сама. Откат — возврат дашбордов и правил оповещений на прежние запросы, история при этом сохраняется.
Как это отразится на дежурной смене?
Дежурный получает оповещение с указанием тенанта и ссылку на дашборд с уже подставленным фильтром. Вместо ручного поиска по общему потоку — один переход к проблемному клиенту, поэтому время от срабатывания до начала разбора сокращается, а число ложных эскалаций падает.
Обсудим схему разделения наблюдения
Разбор per-tenant мониторинга начинается не с выбора инструментов, а с вашей текущей картины наблюдения: как собираются метрики и логи, где данные разных тенантов смешиваются и какие вопросы остаются без ответа. Ниже — что подготовить к разбору задачи с инженерами: по этим пунктам строится и оценка работ.
- Постановка задачи — перечень тенантов, чем отличаются их контуры, какие требования к изоляции данных наблюдения и как быстро инцидент должен становиться видимым.
- Текущая схема наблюдения — какие сборщики метрик и логов задействованы, как размечаются записи, где привязка к тенанту теряется, какие панели и оповещения уже работают.
- Разбор архитектуры — как связаны сервисы, хранилище метрик и логи, где проходит граница доступа и как разделяются права на данные тенантов.
- Объём и хранение — скорость роста числа временных рядов, глубина хранения, требования к выборочному опросу, чтобы разделение не удвоило нагрузку на сбор.
- Оценка работ — что меняем в разметке и правилах сбора, какие проверки добавляем, какие узкие места закрываем первыми.
- План внедрения — порядок этапов, что проверяем на каждом и как откатываемся, если новый контур даст расхождения с текущим.
Пришлите текущую схему: настройки сборщиков, список метрик, примеры запросов к логам. Опишите задачу своими словами — вернёмся с оценкой и планом, а разбор проведём вместе с инженерами, которые будут это внедрять.
