В мире, где простои баз данных измеряются в упущенной выгоде, проактивный мониторинг из роскоши превращается в необходимость. В статье описывается как pg_expecto позволяет не ждать проблем, а предсказывать и предотвращать их.
Новый инструмент с открытым исходным кодом для статистического анализа, нагрузочного тестирования и построения отчетов доступен в репозиториях GitFlic и GitHub
kznalp/PG_EXPECTO: Комплекс статистического анализа производительности СУБД PostgreSQL
Формулировка задачи:
Разработка специализированных конфигурационных файлов метрик для оценки производительности систем управления базами данных (СУБД) с использованием инструментария pg_expecto. Результаты работы предназначены для интеграции в системы мониторинга и обеспечения основ для реализации механизмов проактивного анализа производительности СУБД.
Предисловие
Реактивный и проактивный мониторинг: rinace — ЖЖ
Графики изменения операционной скорости и ожиданий СУБД в период, предшествующий инциденту.
Условие начала инцидента :
Если угол наклона линии регрессии операционной скорости < 0 ,
И
угол наклона линии регрессии ожиданий > 0
ТО
Создать оповещение мониторинга "Инцидент деградации производительности".
В качестве значения для приоритета инцидента, используется модуль коэффициента корреляции :
< 0.7 : низкий уровень (Приоритет 4). Значение индикатора = -50
>= 0.7 : высокий уровень (Приоритет 3). Значение индикатора = -100
Расчет индикатора снижения производительности СУБД
Угол наклона линии графика
ATAN(REGR_SLOPE(Y, X)) * 180 / PI()
Y - выборка значений(операционная скорость, ожидания СУБД) за заданный период
X - точки наблюдения (номер минуты)Коэффициент корреляции между операционной скоростью и ожиданиями СУБД
COALESCE( corr( speed , waitings ) , 0 ) AS correlation_value
speed - выборка значений операционной скорости за заданный период
waitings - выборка значений ожиданий СУБД за заданный периодДополнительная информация:
Операционная скорость, ожидания , корреляция, линия регрессии
Статистический анализ производительности СУБД PostgreSQL | Postgres DBA | Дзен
Индикатор снижения производительности СУБД
Реализация системы мониторинга производительности СУБД на основе расширения pg_expecto
Определен перечень метрик для оценки производительности СУБД, включающий показатели операционной скорости обработки запросов и ожиданий СУБД(wait_event_type).
Получаемые метрики агрегируются и экспортируются в текстовые файлы в формате, обеспечивающем их последующий сбор системой мониторинга Zabbix.
Для проактивного выявления аномалий производительности реализован алгоритм регрессионного анализа. На основе исторических данных производится расчет углового коэффициента линейного тренда для метрик операционной скорости и ожиданий СУБД. Результирующее значение, характеризующее динамику изменения производительности, сохраняется в качестве интегрального индикатора деградации.
Критерием для инициации процедуры обработки инцидента, связанного с деградацией производительности СУБД, является регистрация ненулевого значения указанного индикатора.
Файлы для формирования метрик мониторинга:
/tmp/pg_expecto_speed.txt : Текущее значение операционной скорости.
/tmp/pg_expecto_waitings.txt : Текущее значение ожиданий СУБД.
/tmp/pg_expecto_indicator.txt : Текущее значение индикатора деградации производительности СУБД.
Результат: мониторинг производительности СУБД в Zabbix
Пример использования индикатора снижения производительности
PG_HAZEL : Анализ инцидента производительности СУБД PostgreSQL. | Postgres DBA | Дзен
Комментарии (9)
NetFantomIO
30.10.2025 10:18Тема анализа производительности и алармов очень интересна. Но статья как-будто написана chatgpt с плохим промптом - сухо, дергано, и не понятна ее цель, что именно вы хотели донести.
У меня не сложилось понимания как мне взять и попробовать, очень бы хотелось увидеть пошаговый рецепт внедрения и получения первых результатов. И уже после можно погружаться глубже - в то как оно устроено и в теорию.
Sleuthhound
>> Новый инструмент с открытым исходным кодом...
>> https://gitflic.ru/project/kznalp/pg_expecto
А в репе архивы... 21 век, а месье знает толк... как выкладывать исходники на git
Уж простите, но не удержался.
Какой смысл их выкладывать на git в архивах? как я могу понять что Вы там между версией 2 и 3 поменяли? Выкладывайте тогда уж на yandex disk
pg_expecto Автор
Вы первый на Хабре, кто зашел посмотреть репозиторий .
Ок. Принято , возможно, сегодня выложу в папках.
Просто zip архивами проще инсталлировать .
Спасибо за обратную связь . Неужели кому то кроме меня, тема статистического анализа производительности СУБД стала интересна ?
Есть файл HISTORY.md
Sleuthhound
>Неужели кому то кроме меня, тема статистического анализа
Она интересна, но у Вас статья/и написаны суховато, голые формуры и 2 скриншота. Формулы я и в книжке могу почитать, причем с детализацией.
Интересно знать детали метода и прочие технические аспекты.
>Просто zip архивами проще инсталлировать .
Проще это когда есть готовые deb/rpm пакеты под нужную ОС, все остальное - компромис и какое-то количество ручной работы по установке.
Посмотрите для примера как оформлены модули для пг, например pg_wait_sampling (да там нет пакетов, но zip архив формируется в релизе через пайплайн, а не лежит в репе, есть инструкция по установке, сборке и использованию в README, ну и конечно видно все исходники и можно посмотреть что и когда там менялось)
>Есть файл HISTORY.md
Он не нужен если у Вас будут формироваться релизы с архивами, там обычно и пишут историю изменения в версии (см опять же pg_wait_sampling). Ну и в HISTORY.md не пишут, обычно файл называется CHANGELOG.md.
pg_expecto Автор
Большая статья по теме по основам и теоретической части с практическими примерами
https://dzen.ru/a/aGYjGIt_KDOjmf35
Завтра будет год как создан Дзен-канал
https://dzen.ru/kznalp
Материалов много, за год и теория и технические аспекты. Только судя по отсутствию вопросов в комментариях - опять таки не интересно никому.
После подготовки и начала тестирования расширения pg_expecto будут и на Хабре статьи и новости, но в третью очередь после Дзена и Пикабу. Потому, что читатели Хабра слили карму , теперь 1 статья в неделю. Пока еще комментировать могу раз в 5 минут, но возможно скоро и эта возможность будет ограничена до часу(т.е. без комментариев на самом деле, через час я и забуду о чем и про что была мысль)
вряд ли я найду время и главное желание настолько углубляться в DevOps.
Спасибо за информацию , принято . Будет время , буду полировать. Так, то я не DevOps , для DBA использования Git и CI/CD задача очень редкая.
Странно, я как раз чаще встречал history. Но в принципе , пусть будет changelog . Может быть сегодня поменяю. Мне в общем то без разницы.
pg_expecto Автор
FYI
Создан репозиторий на GitHub
pg-expecto/pg_expecto: Расширение pg_expecto для статистического анализа производительности СУБД PostgreSQL
Пайплайны пока не настроены, в процессе.
Sleuthhound
Чем же gitflic не угодил? Кстате на github в любом проекте можно включить Wiki и писать всю документацию там. Это и удобней и не нужно держать в репе папку doc. Wiki по сути тот же git у которого можно смотреть историю изменений.
Вообще если это расширение пг, то кроме него ничего не должно быть в репе. Для тестирования расширения и если Вы пишите статьи делают отдельные репы с набором скриптов и скриншотов и ссылками на оригинальную статью. Это просто бесплатный совет.
Развивайте расширение, в README.md к нему пишите ссылки на статьи и тп. Не сгребайте все в одну кучу - это неудобно.
Ну и ИМХО источник правды (репо) должен быть один, а не 100500, я это к тому что если переехали на github, то на gitflic сделайте пометку или удалите его или сделайте gitflic зеркалом github (если есть такой функционал у gitflic)
pg_expecto Автор
Я так и не разобрался как делать папки в проекте
Не все сразу
IMHO расширение само по себе не имеет никакого практического смысла. Ну например - вот поставил расширение pg_stat_statements и что , ну запросы, цифры какие то какой в них практический смысл ? Искать нужно фильтровать мегатонны статей из которых половина не имеет практического смыслы а част давно устарела.
Моя мысль была такая - вот репозиторий, кому интересно - берет zip-ы , запускает инсталлятор по инструкции, запускает нагрузочное тестирование , отчеты и смотрит , что получилось, если дальше интересно - ну ставьте на продуктив и интегрируйте с мониторингом. Все в одном флаконе.
Контакты есть, если что непонятно - можно спросить. Пока судя по отсутствию комментариев и вопросов - никому не интересно, никто не ставил, не запускал, не проверял, не исследовал и не пытался проверить результаты экспериментов.
Ну нет так нет.
Вы первый из более 11000 просмотревших, кому стали интересны исходные коды.
Спасибо за обратную связь. Сейчас перенесу ссылки в readme из howto
Посмотрим, что получится дальше. Это мой первый проект в open source. Спасибо за наводки.
pg_expecto Автор
FYI отказался от идеи использовать расширение, в результате очень сильно все упростилось, особенно инсталляция.
Просто создается БД репозиторий для сервисных таблиц и функций.
Еще раз, спасибо за начальный комментарий. Плюсов поставить не могу , карма не позволяет. Ну чисто виртуально.