Моніторинг MySQL з Percona PMM: налаштування Query Analytics та оповіщень

Percona PMM: чому вузькі місця MySQL залишаються непоміченими

Стандартний набір метрик — завантаження процесора, вільна пам'ять, перевірка доступності — майже завжди виглядає спокійно, навіть коли застосунок уже гальмує.

Деградація бази даних починається не з падіння сервера, а з окремих повільних запитів: план виконання змінюється після зростання таблиці, індекс перестає використовуватися, і час відгуку зростає поступово, без єдиного явного збою.

Друга сліпа зона — блокування таблиць. Транзакція, яка тримає рядок довше звичайного, збирає за собою чергу, і в пік це виливається в секундні затримки в усіх, хто звертається до тієї самої таблиці.

За навантаженням на сервер така подія майже непомітна: процесор вільний, а користувачі вже пишуть у підтримку.

Просідання реплікації — третій тип проблеми. Відставання репліки від майстра спочатку вимірюється частками секунди й не потрапляє в жодне правило сповіщення, але звіт, зібраний з репліки, починає віддавати застарілі дані. Виявляється це зазвичай за скаргою: «цифри не ті, що вчора».

Percona PMM закриває всі три сценарії одразу. Query Analytics розкладає навантаження за конкретними запитами й показує, який із них став важчим за останню добу, а правила сповіщень ловлять блокування та відставання репліки раніше, ніж це помітить бізнес. Нижче — як такий моніторинг MySQL влаштований на практиці.

Що дає безперервний моніторинг бази даних

Безперервний моніторинг робить базу спостережуваною: Percona PMM збирає метрики сервера й запитів, зберігає історію та порівнює поточну поведінку з базовою лінією. Інженер бачить не «сайт гальмує», а конкретний запит, план його виконання та момент деградації. Нижче — ефекти, які замовник помічає в перші тижні.

Час виявлення інциденту

Алерти за кількістю підключень, часом відгуку та відставанням реплік надходять раніше, ніж скарги користувачів. Черговий отримує сигнал за хвилини, і вікно, у якому падіння ще можна запобігти, зростає з годин до хвилин.

Розбір повільних запитів до причини

Історія запитів дозволяє порівняти поведінку до та після зміни схеми й знайти джерело зростання навантаження без перебору. Зростає частка звернень, закритих усуненням першопричини, а не перезапуском, — повторні інциденти за тим самим запитом зникають.

Доступність сервісу та класи відмов

Перевірки реплікації, вільного місця та зростання таблиць ловлять переповнення диска й розсинхрон до аварії. Цілі класи відмов — вичерпання з'єднань, відставання репліки, неіндексовані вибірки — перестають доходити до користувачів.

Навантаження на базу

Видно, які звіти та фонові завдання дають пік, і їх переносять у вікно низької активності. Навантаження стає передбачуваним, а розширення вузла планується за фактом, а не на око.

Режими збору метрик і підходи до розгортання

У Percona PMM підхід до розгортання визначає, звідки надходять показники та де вони зберігаються. На стенді з трьох баз різниця непомітна, але коли баз десятки й частина — у закритих контурах, вибір стає архітектурним.

Локальний агент моніторингу встановлюється на той самий хост, що й база, знімає показники з процесу та надсилає їх у спільне сховище метрик.

Він бачить внутрішні лічильники, недоступні ззовні, але ділить із базою ресурси, потребує прав на хості й оновлюється разом із парком серверів.

Частота опитування — компроміс між швидкістю реакції та обсягом сховища метрик: частий крок ловить сплески, але швидко роздуває історію. Зазвичай беруть рідкий збір у розрізі запитів і частіший — за доступністю та реплікацією.

Ізоляція серверів визначає, де ставити проміжний вузол: якщо контури не бачать один одного, метрики передаються через один вузол в один бік, без вхідного доступу до баз.

Етапи впровадження моніторингу: від аудиту до передачі

Моніторинг MySQL впроваджують не встановленням агента, а побудовою схеми спостережуваності: спочатку домовляємося, які відхилення вважаємо інцидентом, і лише потім розгортаємо збір даних.

Порядок кроків важливий — якщо пропустити перевірку на навчальній деградації, сповіщення вперше спрацюють уже на реальній аварії.

1. Обстеження. Збираємо список інстансів, топологію реплікації, власників сервісів і критичні запити — фіксуємо, що вважаємо нормою.
2. Схема спостережуваності. Визначаємо, які метрики та тексти запитів збираємо, де і скільки зберігаємо історію, які права видаємо агенту.
3. Розгортання. Сервер Percona PMM ставимо окремим вузлом, агенти — на кожному інстансі та репліці; перевіряємо, що дані йдуть з усіх вузлів, а не лише з основного.
4. Налаштування Query Analytics. Групуємо запити за зразком, задаємо поріг тривалості та збираємо плани виконання, щоб у звіт потрапляли важкі запити, а не службовий шум.
5. Налаштування сповіщень. Пороги за відставанням реплікації, блокуваннями, кількістю з'єднань і вільним місцем; кожне правило маршрутизуємо в черговий канал із зрозумілим текстом.
6. Перевірка алертів на навчальній деградації. Штучно створюємо відставання репліки та тривале блокування — дивимося, чи спрацювало правило, за який час надійшло повідомлення і чи не спрацювало зайве.
7. Передача в експлуатацію. Віддаємо панелі графіків, регламент чергування та інструкцію: що перевіряти при спрацюванні й коли ескалювати.

Після передачі схема працює без нас: правила й пороги в команди в репозиторії, історія запитів накопичується, розбір регресії займає хвилини замість годин.

Конфігурації, панелі моніторингу та регламенти на виході

Роботу з Percona PMM закриваємо не в момент, коли панелі відкрилися, а коли в команди залишився комплект, за яким черговий діє без автора впровадження.

Усе перелічене зберігається в системі контролю версій поруч з рештою інфраструктури, а не в листуванні й не в голові одного інженера.

• Конфігурація моніторингу: файли агентів і сервера з коментарями — що відповідає за збір метрик, глибину зберігання, строки зберігання та доступи.
• Правила сповіщень: пороги за затримкою реплікації, тривалими блокуваннями, кількістю з'єднань і вільним місцем, з позначкою, що означає спрацювання та куди дивитися першим.
• Шаблони панелей: окремо за екземпляром, за кластером і за потоком запитів, із підписаним джерелом метрики на кожному графіку.
• Регламент реагування: хто приймає сигнал уночі, які дії допустимі без погодження, у який момент підключається відповідальний за бази.
• Документація по базі: інвентар екземплярів, ролі та доступи, перелік критичних запитів, відомі вузькі місця з історією змін.
• Інструкція з обслуговування самого моніторингу: оновлення, резервна копія сховища метрик, порядок відновлення після збою.

Через місяць після передачі розбираємо разом із вашою командою, які сповіщення виявилися шумними, і правимо пороги. Так система залишається робочою, а не перетворюється на набір графіків, на які перестали дивитися.

Кейс: усунули клас відмов на реплікації

Що було

Репліка під звітним навантаженням входила у відставання на десятки секунд, у піках — на хвилини. Аналітика й частина користувацьких сценаріїв читалися з неї, тому люди бачили застарілі дані й повідомляли про це раніше, ніж черговий дізнавався про проблему.

Формально сповіщення про відставання було, але поріг стояв за абсолютним значенням, і правило мовчало саме на тій ділянці, де відставання починало зростати.

Що змінили

Розгорнули Percona Monitoring and Management, увімкнули розбір запитів і переписали правила. Поріг прив'язали до швидкості розбору журналу репліки та до часу важких запитів — спрацювання йде за трендом, а не за фактом, коли дані вже розійшлися.

Черговий одразу бачить, який запит тримає репліку й на скільки вона відстає, і йде в розбір із готовою відповіддю, а не з гіпотезою.

Що стало

Пікове відставання скоротилося з хвилин до секунд, і в штатному режимі репліка тримається в межах одиниць секунд. Час від початку зростання відставання до реакції чергового впав з годин до пари хвилин — завдяки цьому випадки, що дійшли до користувачів, припинилися.

Хибні спрацювання зменшилися з третини сповіщень до одиниць на місяць: правила стали точковими, і черговий знову їм довіряє.

Далі перенесли цей самий підхід на решту сервісів: однаковий набір метрик, однакові пороги, розбір кожного хибного спрацювання як невеликої правки правила.

Відставання репліки перестало бути класом відмов — тепер це керований параметр із зрозумілим власником і регламентом реакції.

Percona PMM чи самописний моніторинг: що вибрати

Коротка відповідь: для типової експлуатації MySQL і MariaDB готове рішення закриває задачу за години. Агент ставиться на хост, піднімає збір метрик, журналу повільних запитів і планів виконання, а розбір запитів одразу показує, які звернення з'їдають час сервера.

Самописний моніторинг виправданий, коли метрики потрібні з нестандартних джерел або поверх наявного стеку потрібна своя логіка алертів.

Різниця проявляється не на старті, а на супроводі. У готового рішення оновлення, сумісність із новими гілками та типові панелі йдуть від спільноти — команда розбирає аномалії, а не підтримує сам інструмент.

Самописний контур дає повний контроль, але оновлення, надійність сховища метрик, ротацію та права доступу ви тягнете самі.

Практичний критерій: потрібна спостережуваність усієї бази й швидко — беріть готове; метрики унікальні й є кому їх супроводжувати — збирайте своє.

Вартість підтримки рахуйте на горизонті року: у готового рішення вона майже лінійна за кількістю вузлів, у самописного зростає з кожною зміною інфраструктури.

Технічні сумніви перед впровадженням

Перед стартом впровадження спливають одні й ті самі питання: чи не просяде бойова база, як бути із серверами за периметром, чи не потоне черговий у повідомленнях. Працюємо з Percona PMM, тому відповідаємо за цією схемою.

Які права потрібні агенту?

Окремий обліковий запис лише на читання показників і статистики продуктивності. Права на зміну даних і схеми не потрібні, секрети зберігаємо в захищеному сховищі, а не у відкритих файлах конфігурації.

Що робити з базами за периметром?

Агент сам відкриває вихідне з'єднання із сервером моніторингу, вхідні порти на бойових хостах залишаються закритими. Хости без зовнішнього каналу підключаємо через проміжний вузол-ретранслятор.

Не потонемо в хибних спрацюваннях?

Пороги виводимо з накопиченої норми конкретної бази, а не із загальних шаблонів. У правил є вікно очікування та придушення повторів — черговий бачить лише події, що потребують дії.

Що з метриками, які вже збираємо?

Наявні панелі та сповіщення не ламаємо: дані віддаємо в поточну систему візуалізації, дублювальний збір вимикаємо. Чергові залишаються у звичних панелях.

Хто супроводжує систему після передачі?

Конфігурації, правила сповіщень, схема потоків і регламент реакції залишаються у вас. Чергових навчаємо читати панелі та розбирати спрацювання — далі за домовленістю.

Обговоримо ваше завдання моніторингу

Щоб повернутися з оцінкою робіт і планом впровадження, а не із загальними питаннями, нам потрібен мінімальний зріз по інфраструктурі. Зазвичай достатньо опису складу парку серверів і поточної схеми моніторингу — далі ми самі задаємо точкові уточнення щодо спірних місць.

• Склад парку серверів: скільки інстансів MySQL і сумісних збірок, їхні ролі (джерело, репліки, проміжні вузли), де вони розміщені — хмара, власні стійки, контейнери, керовані сервіси провайдера.
• Поточна схема: що вже збирається, якими агентами, куди пишуться метрики й як довго зберігаються, чи є готові дашборди чергової зміни.
• Що болить зараз: де дізнаєтеся про проблему — зі скарг, із журналу повільних запитів чи з алерта, і скільки часу минає від деградації до реакції.
• Перелік запитів і метрик, за якими потрібні сповіщення: критичні бізнес-операції, пороги за затримками реплікації, блокуваннями, вичерпанням з'єднань, зростанням таблиць.
• Доступи: сервісні облікові записи з правами лише на читання діагностики, мережеві правила між вузлом збору метрик і базами, обмеження служби безпеки.
• Куди мають надходити повідомлення й хто чергує: чат, пошта, система заявок, розмежування нічних і денних змін.
• Обмеження середовища: заборона вихідних підключень, вимоги до локального зберігання даних телеметрії, регламент змін у промисловому контурі.

Надішліть це у вільній формі — нам не потрібен ідеальний документ. Ми повернемося з оцінкою робіт, поетапним планом впровадження з контрольними точками та переліком ризиків, які бачимо на вашій схемі.

Якщо чогось бракує, поставимо уточнювальні питання до старту, щоб не переробляти конфігурацію на живому контурі.