Моніторинг БД наосліп: деградацію помічають за скаргами
Типова картина: моніторинг БД налаштований частково — знімається завантаження процесора та вільне місце, а історія за часом виконання запитів, блокуваннями та відставанням реплік не збирається взагалі.
Поки трафік рівний, цього достатньо, але при зростанні навантаження на СУБД деградація бази даних іде не відмовою, а повзучим збільшенням часу відповіді — спочатку на відсотки, потім у рази.
Таке вузьке місце в базі не видно до моменту, коли в чергу стають з'єднання. Першими реагують користувачі: «форма довго зберігається», «звіт не відкривається».
Розбір починається з нуля — немає точки відліку, і невідомо, що саме змінилося: реліз додатка, новий індекс, зрослий обсяг таблиці або деградований план виконання запиту.
Ціна сліпоти — не лише простій. Аварія бази даних, помічена за скаргами, завжди розбирається довше: поки інженер збирає знімки стану, проблема або зникає сама, або погіршується, а причина залишається невідомою до наступного разу.
Далі розбираємо, як це закривається: безперервний збір метрик Percona PMM з історією змін і порогами, за якими відхилення видно раніше, ніж його помітить користувач.
Що змінюється після підключення баз до спостереження
Спостереження за базами змінює не звітність, а момент, у який команда дізнається про проблему. Запит починає гальмувати, репліка відстає, закінчується місце на диску — раніше це з'ясовувалося зі скарг і розбору наслідків. З єдиною панеллю метрик сигнал надходить до того, як деградація стане відмовою.
Раннє виявлення деградації замість розбору наслідків
Спостереження за базами будується на порогах, прив'язаних до поведінки конкретного навантаження: час виконання запитів, черга очікувань, зростання журналів, відставання реплік.
Раннє оповіщення спрацьовує на стійке зростання показника, а не на факт падіння, — час виявлення проблеми скорочується з годин до хвилин.
Другий ефект — історія метрик. Замість знімків «як було в момент аварії» залишається безперервний ряд: видно, коли почалося зростання, що йому передувало і який параметр повернув систему в норму. Розбір інциденту спирається на дані, а не на свідчення очевидців.
Єдина картина за різнорідними базами
Різні СУБД і різне обладнання зводяться в один контур: агенти збирають показники, сервер зберігає їх і віддає через загальний інтерфейс.
Наші інженери працюють на відкритій платформі рівня Percona PMM — вона покриває поширені СУБД, включаючи кластери та репліки, і не прив'язує вас до одного постачальника.
Практичний результат — один екран замість десятка консолей. Черговий бачить, яка база деградувала, наскільки її поведінка відрізняється від сусідніх і коли це почалося, а пороги оповіщень залишаються у вашій інфраструктурі й налаштовуються під ваш режим навантаження.
Способи збору метрик: локальний агент, зовнішнє опитування, гібрид
Від схеми збору залежить, побачите ви деградацію диска чи лише зростання затримки запитів. PMM забирає метрики двома шляхами — опитуванням вузла по мережі або збирачем поруч із базою, — і набір лічильників у кожному випадку різний.
Визначатися варто до підключення першого інстансу: зміна схеми заднім числом означає переробку панелей і правил оповіщення.
Коли достатньо зовнішнього опитування
Сервер сам звертається до вузла по мережі й забирає метрики з відкритого порту. Підходить, коли база віддає стан назовні, вузлів небагато і доступ між сегментами вже відкритий: на хостах нічого не ставиться й не оновлюється.
Платите глибиною — стан буферного пулу, введення-виведення за таблицями та внутрішні черги зовні видно частково, а при обриві зв'язку дані просто зникають.
Коли потрібен локальний агент на вузлі
Агент працює поруч із процесом бази й читає те, що назовні не публікується: планувальник, введення-виведення на рівні таблиць, відставання реплік. Потребує обслуговування на кожному вузлі та прав до службового сокета.
Зате інцидент розбирається за причиною, а не за симптомом, і метрики не губляться при мережевих збоях.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Зовнішнє опитування | Парк до десятка вузлів, стабільна мережа, швидкий старт | Менша глибина, немає даних при недоступності вузла |
| Локальний агент | Навантажені бази, потрібні метрики планувальника та введення-виведення | Агент на кожному вузлі, доступи до сокета |
| Гібрид | Різнорідний парк: критичне — з агентом, периферія — зовні | Складніше налаштування, дві схеми в одній панелі |
Глибину й частоту опитування вибирають окремо від схеми: рідкісний інтервал економить ресурси, але згладжує сплески, а частий дає точну картину й помітно навантажує вузол.
Порядок впровадження: від інвентаризації до передачі
Впровадження моніторингу йде послідовно: спочатку фіксуємо, що саме існує в інфраструктурі, потім підключаємо збір метрик і тільки після цього налаштовуємо пороги. Зворотний порядок дає хибні спрацьовування й шум, у якому губляться реальні відмови.
Схема підключення та розмежування прав
- Інвентаризація баз: збираємо перелік екземплярів, ролей, реплік і кластерів, позначаємо критичні для бізнесу та виведені з експлуатації. Пропущений вузол потім спливає в момент аварії.
- Проєктування схеми: визначаємо, де стоїть сервер спостереження, як він знімає метрики з кожного вузла і що відбувається при обриві каналу.
- Розмежування прав: заводимо окремий обліковий запис з мінімально достатніми правами — читати метрики й стан, без доступу до самих даних.
- Налаштування збору: вмикаємо метрики, журнал повільних запитів і статистику виконання, задаємо терміни зберігання, щоб обсяг не зростав безконтрольно.
Перевірка порогів і каналів оповіщення
- Налаштування порогів: задаємо межі за навантаженням, відставанням реплік, блокуваннями та вільним місцем, розділяючи аварійні значення та попередження.
- Перевірка оповіщень: проганяємо сценарії на реальному навантаженні — навмисно виводимо вузол з ладу й переконуємося, що сигнал дійшов до чергового, а не залишився в панелі.
- Передача рішення: віддаємо регламент чергування, інструкції щодо типових реакцій і доступи, розбираємо з командою замовника останні спрацьовування.
Що залишається у вашої команди після впровадження
Впровадження закрито не тоді, коли відкрилися панелі з графіками, а коли у команди залишився комплект артефактів, за якими систему можна підняти, розширити й передати новому інженеру без її автора.
Усе перелічене нижче ми віддаємо в систему контролю версій і у внутрішню базу знань — не налаштуваннями «на сервері в адміністратора», які живуть до першої відпустки.
Комплект конфігурацій і схем
- Конфігурація спостереження: файли підключення агентів до Percona PMM, змінні середовища та перелік збираних метрик — нова база заводиться копіюванням і правкою двох параметрів.
- Схема підключення: топологія «база — збирач метрик — сховище» з адресами, портами та межами мереж; за нею відразу видно, що доступно ззовні, а що закрито.
- Політики доступу: сервісні облікові записи з мінімальними правами та розмежуванням ролей — черговий бачить графіки, зміна порогів доступна лише власнику сервісу.
- Набір дашбордів під ваші ролі: окремі види для чергового, розробника й керівника, щоб кожен відкривав свою картину, а не загальний список із сотні метрик.
Регламенти чергування та ескалації
- Регламент оповіщень: який поріг що піднімає, кому йде сигнал, що вважається хибним спрацьовуванням і в якому порядку виправляється чутливість.
- Документація за базами: інвентар екземплярів, версії, розташування, власники, схема реплікації та точки відмови.
- Порядок ескалації: хто приймає сигнал першим, коли підключається старший інженер і що фіксується в журналі після розбору.
Кейс: скоротили час пошуку причини деградації
Кейс моніторингу парку з кількох десятків баз: транзакційне ядро, репліки, аналітичні вивантаження з різним профілем навантаження. До впровадження Percona PMM про проблему дізнавалися від користувачів, а розбір починався вже після того, як деградація стала помітна ззовні.
Що було до підключення
Діагностика йшла за непрямими ознаками: повільний журнал, лічильники операційної системи, ручні запити до системних таблиць.
На пошук причини деградації йшло від 40 хвилин до двох годин, і в частині випадків причина залишалася версією — історія метрик не зберігалася, на момент розбору значення вже були перезаписані поточними.
Регулярно повторювався й один і той самий клас відмов: непомічене вичерпання ресурсу — зростання довгих транзакцій і переповнення пулу з'єднань, за яким слідував перевід вузла в режим тільки для читання.
Що змінилося після
Збирач знімає метрики з усіх вузлів за єдиним розкладом, історія зберігається із запасом за глибиною, тому є з чим порівняти поточну поведінку. Причина визначається за графіком: видно, яка метрика почала зростати першою і що виросло слідом, — замість перебору здогадів.
Час відновлення скоротився з годин до хвилин: інженер відкриває панель за потрібний інтервал і відразу бачить вузьке місце.
Метрики до і після: частка інцидентів, виявлених за оповіщенням, а не за скаргою, зросла з поодиноких випадків до більшості; середній пошук причини — з 40–60 хвилин до 5–10 при тому ж розмірі парку.
Клас відмов із непоміченим вичерпанням ресурсів пішов: пороги за вільним місцем, з'єднаннями та тривалістю транзакцій спрацьовують раніше, ніж збій стає виден ззовні.
Чим відрізняється моніторинг БД у кластері від спостереження за вузлом?
Вузол і кластер — різні об'єкти спостереження: метрики одного не відповідають на питання іншого. Агент на хості показує завантаження процесорів, вільне місце й повільні запити конкретної машини.
Але в кластері відмовостійкість визначається не станом сервера, а відносинами між вузлами: хто ведучий, чи наздогнали ведені потік змін, чи пройшло перемикання ролей без втрати транзакцій.
Без кластерного рівня з поля зору випадають відставання реплікації, розсинхронізація та обірвані зв'язки між вузлами. Вузол може бути повністю здоровий, а кластер уже деградував: читання з відсталого веденого віддає застарілі дані, а перемикання ролей відкочує частину записів. Тому моніторинг БД будують на двох рівнях одразу.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Спостереження за вузлом | Одиночний сервер, тестовий контур, розбір інциденту на конкретній машині | Не бачить ролі та топологію; перемикання виглядає як провал метрик |
| Спостереження за кластером | Кластер баз із реплікацією та автоматичним перемиканням ролей | Потрібен доступ до службових представлень і єдина точка збору |
| Обидва рівні разом | Продуктивний кластер: важливі й ресурси, і логіка реплікації | Складніше в налаштуванні, потрібна нормалізація метрик |
На практиці рівні зводять в один збирач: Percona PMM опитує агенти на хостах і службові представлення кожного вузла, тому стан сервера й кластера видно на одному графіку — відставання репліки, зміна ведучого, роз'їхалися лічильники.
Це дозволяє розрізняти причину та наслідок: затримки на веденому — це відстала репліка чи нестача місця.
Часті сумніви перед підключенням баз до спостереження
Сумніви перед підключенням баз до спостереження зазвичай стосуються не самої панелі з метриками, а наслідків: скільки ресурсів забере збирач, де осяде історія, як бути з ізольованими контурами і хто відповідає за оповіщення після передачі. Нижче — відповіді за кожним пунктом.
Збір метрик навантажить продуктивні бази?
Збирач читає внутрішні лічильники СУБД і службові представлення, інтервал опитування налаштовується — від частого до щадного. Перед включенням знімаємо базову лінію на піковому навантаженні й після, при відхиленні збільшуємо інтервал або точково вимикаємо важкі колектори. Помітний внесок дає не сам збір, а трасування запитів із планами виконання — її вводимо дозовано.
Де зберігається історія і як довго?
Метрики пишуться в тимчасове сховище на окремому сервері спостереження, не на продуктових вузлах: детальні дані тримаємо тижні, згорнуті агрегати — місяці. Обсяг зростає передбачувано й залежить від числа баз та інтервалу опитування, політика зберігання задається правилами.
Бази в закритому контурі, без прямого доступу із загальної мережі
Сервер спостереження розгортаємо всередині контуру, назовні йде один вихідний канал з агрегатами та повідомленнями. Прямий доступ до СУБД не потрібен — достатньо облікового запису лише на читання службової статистики.
У нас уже розгорнуті сторонні засоби спостереження
Вони не конфліктують: збирач читає ті самі лічильники. Частину перевірок можна залишити в поточній системі, а в нову винести те, чого там немає, — так дублювання не виникає.
Хто відповідає за оповіщення після передачі?
Пороги, канали повідомлень і правила чергування фіксуємо в документі, конфігурації та доступи передаємо вашій команді разом із навчанням. Далі спостереження ведете ви або ми за узгодженим регламентом — межа відповідальності прописана заздалегідь.
Обговоримо задачу і повернемося з оцінкою та планом
Щоб повернутися з оцінкою та планом робіт, а не із загальними формулюваннями, нам потрібен мінімум ввідних за вашим контуром. Нижче — перелік того, що варто додати до звернення.
- Перелік баз та їхні ролі — які СУБД в контурі, де мастер, де репліки, які бази обслуговують лише звіти й аналітику.
- Схема розміщення — хости, сегменти мережі, наявність проксі та балансувальників, як організовано доступ до серверів.
- Поточні засоби спостереження — що вже збирає метрики, де вони зберігаються, які оповіщення налаштовані й кому йдуть.
- Вимоги до зберігання історії — глибина зберігання метрик і текстів запитів, чи потрібна окрема деталізація за кожною базою.
- Режим чергування — хто і в які години отримує оповіщення, через які канали, що у вашій практиці вважається аварією.
- Вікна обслуговування та допустимі перерви — коли можна ставити збирачі метрик і перезапускати сервіси без наслідків.
- Відповідальні за доступи — хто видає облікові записи та підтверджує зміни в конфігурації спостережуваних систем.
Ми звіримо перелік баз зі схемою розміщення, перевіримо, як Percona PMM ляже на ваші версії СУБД, і повернемося з оцінкою проєкту та планом робіт. Опишіть задачу — обговоримо деталі й запропонуємо порядок впровадження.
