Percona PMM: почему узкие места MySQL остаются незамеченными
Стандартный набор метрик — загрузка процессора, свободная память, проверка доступности — почти всегда выглядит спокойно, даже когда приложение уже тормозит. Деградация базы данных начинается не с падения сервера, а с отдельных медленных запросов: план выполнения меняется после роста таблицы, индекс перестаёт использоваться, и время отклика растёт постепенно, без единого явного сбоя.
Вторая слепая зона — блокировки таблиц. Транзакция, которая держит строку дольше обычного, собирает за собой очередь, и в пик это выливается в секундные задержки у всех, кто обращается к той же таблице. По нагрузке на сервер такое событие почти незаметно: процессор свободен, а пользователи уже пишут в поддержку.
Просадка репликации — третий тип проблемы. Отставание реплики от мастера сначала измеряется долями секунды и не попадает ни в одно правило оповещения, но отчёт, собранный с реплики, начинает отдавать устаревшие данные. Обнаруживается это обычно по жалобе: «цифры не те, что вчера».
Percona PMM закрывает все три сценария сразу. Query Analytics раскладывает нагрузку по конкретным запросам и показывает, какой из них потяжелел за последние сутки, а правила оповещений ловят блокировки и отставание реплики раньше, чем это заметит бизнес. Ниже — как такой мониторинг MySQL устроен на практике.
Что даёт непрерывный мониторинг базы данных
Непрерывный мониторинг делает базу наблюдаемой: Percona PMM собирает метрики сервера и запросов, хранит историю и сравнивает текущее поведение с базовой линией. Инженер видит не «сайт тормозит», а конкретный запрос, план его выполнения и момент деградации. Ниже — эффекты, которые заказчик замечает в первые недели.
Время обнаружения инцидента
Алерты по числу подключений, времени отклика и отставанию реплик приходят раньше, чем жалобы пользователей. Дежурный получает сигнал за минуты, и окно, в котором падение ещё предотвратимо, растёт с часов до минут.
Разбор медленных запросов до причины
История запросов позволяет сравнить поведение до и после изменения схемы и найти источник роста нагрузки без перебора. Растёт доля обращений, закрытых устранением первопричины, а не перезапуском, — повторные инциденты по тому же запросу исчезают.
Доступность сервиса и классы отказов
Проверки репликации, свободного места и роста таблиц ловят переполнение диска и рассинхрон до аварии. Целые классы отказов — исчерпание соединений, отставание реплики, неиндексированные выборки — перестают доходить до пользователей.
Нагрузка на базу
Видно, какие отчёты и фоновые задачи дают пик, и их переносят в окно низкой активности. Нагрузка становится предсказуемой, а расширение узла планируется по факту, а не на глаз.
Режимы сбора метрик и подходы к развёртыванию
В Percona PMM подход к развёртыванию определяет, откуда приходят показатели и где они хранятся. На стенде из трёх баз разница незаметна, но когда баз десятки и часть — в закрытых контурах, выбор становится архитектурным.
Локальный агент мониторинга ставится на тот же хост, что и база, снимает показатели с процесса и отправляет их в общее хранилище метрик. Он видит внутренние счётчики, недоступные снаружи, но делит с базой ресурсы, требует прав на хосте и обновляется вместе с парком серверов.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Локальный агент | Базы в одном контуре, нужны счётчики самого процесса | Делит ресурсы с базой, обновляется вместе с парком, нужен доступ на хост |
| Удалённый сбор метрик | Базы в изолированных контурах, доступ на хосты закрыт | Видны только внешние показатели, часть причин деградации остаётся за кадром |
| Гибридная схема | Смешанный парк: часть баз открыта, часть — за закрытым периметром | Два набора правил, нужна единая нормализация имён и меток |
Частота опроса — компромисс между скоростью реакции и объёмом хранилища метрик: частый шаг ловит всплески, но быстро раздувает историю. Обычно берут редкий сбор в разрезе запросов и более частый — по доступности и репликации. Изоляция серверов определяет, где ставить промежуточный узел: если контуры не видят друг друга, метрики передаются через один узел в одну сторону, без входящего доступа к базам.
Этапы внедрения мониторинга: от аудита до передачи
Мониторинг MySQL внедряют не установкой агента, а построением схемы наблюдаемости: сначала договариваемся, какие отклонения считаем инцидентом, и только потом разворачиваем сбор данных. Порядок шагов важен — если пропустить проверку на учебной деградации, оповещения впервые сработают уже на реальной аварии.
- Обследование. Собираем список инстансов, топологию репликации, владельцев сервисов и критические запросы — фиксируем, что считаем нормой.
- Схема наблюдаемости. Определяем, какие метрики и тексты запросов собираем, где и сколько храним историю, какие права выдаём агенту.
- Развёртывание. Сервер Percona PMM ставим отдельным узлом, агенты — на каждом инстансе и реплике; проверяем, что данные идут со всех узлов, а не только с основного.
- Настройка Query Analytics. Группируем запросы по образцу, задаём порог длительности и собираем планы выполнения, чтобы в отчёт попадали тяжёлые запросы, а не служебный шум.
- Настройка оповещений. Пороги по отставанию репликации, блокировкам, числу соединений и свободному месту; каждое правило маршрутизируем в дежурный канал с понятным текстом.
- Проверка алертов на учебной деградации. Искусственно создаём отставание реплики и длительную блокировку — смотрим, сработало ли правило, за какое время пришло уведомление и не сработало ли лишнее.
- Передача в эксплуатацию. Отдаём панели графиков, регламент дежурства и инструкцию: что проверять при срабатывании и когда эскалировать.
После передачи схема работает без нас: правила и пороги у команды в репозитории, история запросов накапливается, разбор регрессии занимает минуты вместо часов.
Конфигурации, панели мониторинга и регламенты на выходе
Работу по Percona PMM закрываем не в момент, когда панели открылись, а когда у команды остался комплект, по которому дежурный действует без автора внедрения. Всё перечисленное хранится в системе контроля версий рядом с остальной инфраструктурой, а не в переписке и не в голове одного инженера.
- Конфигурация мониторинга: файлы агентов и сервера с комментариями — что отвечает за сбор метрик, глубину хранения, сроки хранения и доступы.
- Правила оповещений: пороги по задержке репликации, длительным блокировкам, числу соединений и свободному месту, с пометкой, что означает срабатывание и куда смотреть первым.
- Шаблоны панелей: раздельно по экземпляру, по кластеру и по потоку запросов, с подписанным источником метрики на каждом графике.
- Регламент реагирования: кто принимает сигнал ночью, какие действия допустимы без согласования, в какой момент подключается ответственный за базы.
- Документация по базе: инвентарь экземпляров, роли и доступы, перечень критичных запросов, известные узкие места с историей изменений.
- Инструкция по обслуживанию самого мониторинга: обновление, резервная копия хранилища метрик, порядок восстановления после сбоя.
Через месяц после передачи разбираем вместе с вашей командой, какие оповещения оказались шумными, и правим пороги. Так система остаётся рабочей, а не превращается в набор графиков, на которые перестали смотреть.
Кейс: устранили класс отказов на репликации
Что было
Реплика под отчётной нагрузкой уходила в отставание на десятки секунд, в пиках — на минуты. Аналитика и часть пользовательских сценариев читались с неё, поэтому люди видели устаревшие данные и сообщали об этом раньше, чем дежурный узнавал о проблеме. Формально оповещение по отставанию было, но порог стоял по абсолютному значению, и правило молчало именно на том участке, где отставание начинало расти.
Что изменили
Развернули Percona Monitoring and Management, включили разбор запросов и переписали правила. Порог привязали к скорости разбора журнала реплики и к времени тяжёлых запросов — срабатывание идёт по тренду, а не по факту, когда данные уже разошлись. Дежурный сразу видит, какой запрос держит реплику и на сколько он отстаёт, и уходит в разбор с готовым ответом, а не с гипотезой.
Что стало
Пиковое отставание сократилось с минут до секунд, и в штатном режиме реплика держится в пределах единиц секунд. Время от начала роста отставания до реакции дежурного упало с часов до пары минут — за счёт этого случаи, дошедшие до пользователей, прекратились. Ложные срабатывания ушли с трети оповещений до единиц в месяц: правила стали точечными, и дежурный снова им доверяет.
Дальше перенесли этот же подход на остальные сервисы: одинаковый набор метрик, одинаковые пороги, разбор каждого ложного срабатывания как небольшой правки правила. Отставание реплики перестало быть классом отказов — теперь это управляемый параметр с понятным владельцем и регламентом реакции.
Percona PMM или самописный мониторинг: что выбрать
Короткий ответ: для типовой эксплуатации MySQL и MariaDB готовое решение закрывает задачу за часы. Агент ставится на хост, поднимает сбор метрик, журнала медленных запросов и планов выполнения, а разбор запросов сразу показывает, какие обращения съедают время сервера. Самописный мониторинг оправдан, когда метрики нужны из нестандартных источников или поверх существующего стека требуется своя логика алертов.
Разница проявляется не на старте, а на сопровождении. У готового решения обновления, совместимость с новыми ветками и типовые панели идут от сообщества — команда разбирает аномалии, а не поддерживает сам инструмент. Самописный контур даёт полный контроль, но обновления, надёжность хранилища метрик, ротацию и права доступа вы тянете сами.
| Вариант | Когда подходит | Что ограничивает |
|---|---|---|
| Готовое решение (Percona PMM) | Нужен быстрый охват: метрики, журнал медленных запросов и разбор запросов по всем узлам | Нестандартные источники и своя логика алертов требуют доработки |
| Самописный мониторинг на экспортёрах и своих панелях | Есть инженерная команда и требования, которых нет в готовых шаблонах | Сопровождение целиком на вас: обновления, хранилище метрик, правила алертов |
| Гибрид | База из готового решения плюс свои метрики приложений и бизнес-логики | Две системы нужно синхронизировать по именам метрик и порогам |
Практический критерий: нужна наблюдаемость всей базы и быстро — берите готовое; метрики уникальны и есть кому их сопровождать — собирайте своё. Стоимость поддержки считайте на горизонте года: у готового решения она почти линейна по числу узлов, у самописного растёт с каждым изменением инфраструктуры.
Технические сомнения перед внедрением
Перед стартом внедрения всплывают одни и те же вопросы: не просядет ли боевая база, как быть с серверами за периметром, не утонет ли дежурный в уведомлениях. Работаем с Percona PMM, поэтому отвечаем по этой схеме.
Агент не просадит боевую базу?
Базовый сбор показателей идёт с минимальной нагрузкой. Полный разбор запросов включаем выборочно — только на базах, которые уже вызывают вопросы, и с настраиваемым интервалом.
Какие права нужны агенту?
Отдельная учётная запись только на чтение показателей и статистики производительности. Права на изменение данных и схемы не нужны, секреты храним в защищённом хранилище, а не в открытых файлах конфигурации.
Что делать с базами за периметром?
Агент сам открывает исходящее соединение с сервером мониторинга, входящие порты на боевых хостах остаются закрытыми. Хосты без внешнего канала подключаем через промежуточный узел-ретранслятор.
Не утонем в ложных срабатываниях?
Пороги выводим из накопленной нормы конкретной базы, а не из общих шаблонов. У правил есть окно ожидания и подавление повторов — дежурный видит только события, требующие действия.
Что с метриками, которые уже собираем?
Существующие панели и оповещения не ломаем: данные отдаём в текущую систему визуализации, дублирующий сбор отключаем. Дежурные остаются в привычных панелях.
Кто сопровождает систему после передачи?
Конфигурации, правила оповещений, схема потоков и регламент реакции остаются у вас. Дежурных обучаем читать панели и разбирать срабатывания — дальше по договорённости.
Обсудим вашу задачу мониторинга
Чтобы вернуться с оценкой работ и планом внедрения, а не с общими вопросами, нам нужен минимальный срез по инфраструктуре. Обычно хватает описания состава парка серверов и текущей схемы мониторинга — дальше мы сами задаём точечные уточнения по спорным местам.
- Состав парка серверов: сколько инстансов MySQL и совместимых сборок, их роли (источник, реплики, промежуточные узлы), где они размещены — облако, собственные стойки, контейнеры, управляемые сервисы провайдера.
- Текущая схема: что уже собирается, какими агентами, куда пишутся метрики и как долго хранятся, есть ли готовые дашборды дежурной смены.
- Что болит сейчас: где узнаёте о проблеме — из жалоб, из журнала медленных запросов или из алерта, и сколько времени проходит от деградации до реакции.
- Перечень запросов и метрик, по которым нужны оповещения: критичные бизнес-операции, пороги по задержкам репликации, блокировкам, исчерпанию соединений, росту таблиц.
- Доступы: сервисные учётные записи с правами только на чтение диагностики, сетевые правила между узлом сбора метрик и базами, ограничения службы безопасности.
- Куда должны приходить уведомления и кто дежурит: чат, почта, система заявок, разграничение ночных и дневных смен.
- Ограничения среды: запрет исходящих подключений, требования к локальному хранению данных телеметрии, регламент изменений в промышленном контуре.
Пришлите это в свободной форме — нам не нужен идеальный документ. Мы вернёмся с оценкой работ, поэтапным планом внедрения с контрольными точками и перечнем рисков, которые видим на вашей схеме. Если чего-то не хватает, зададим уточняющие вопросы до старта, чтобы не переделывать конфигурацию на живом контуре.
