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