Обзор

Продукт реализован как набор модулей, с разной периодичностью собирающих данные таблиц системной статистики и публично доступных расширений, сохраняющих их в таблицах продукта, проводящих обработку сохранённых данных и реализующих их отображение в табличном и графическом виде. Большая часть кода написана - в БД на PL/PGSQL и SQL, WEB форм - на HTML+CSS, Perl, JS. Отдельные модули реализованы на bash

В продукте использованы наработки других моих продуктов - КоСиКУЛС БЕССТ [(C), 2006], СтатОС БЕССТ [(C), 2010], ОрСиМОН БЕССТ [(C), 2010], КрАгрАн БЕССТ [(C), 2023]

Дополнительные данные получаются из ряда свободно распространяемых расширений СУБД PostgreSQL - pg_wait_sampling, pg_store_plans, pg_stat_statement, DDLX и других

Компонента "Общие представления". Конфигурация, роли, привелегии и т.п.

В текущей реализации модули WEB форм производят опрос системного каталога выбранных БД или кластера и отображают данные конфигурации, перечня БД, ролей, системных, табличных и колоночных привелегий

Компонента "Объекты БД. Списки, DDL"

В текущей реализации модули WEB форм производят опрос системного каталога выбранных БД и отображают данные объектов БД - таблиц, представлений, индексов, процедур и функций, последовательностей, триггеров. Для большинства объектов реализовано отображение DDL для создания обьекта, в т.ч. с дочерними объектами. Для чего вызываеются методы свободно доступного расширения DDLX

Компонента "TOP Activity". Разрезы по запросам, сессиям,
классам событий, событиям и т.п.

Для понимания - с момента появления DB Console компонента TOP Activity в СУБД Oracle является одним из тех незаменимых инструментов, которые постоянно используют в своей работе администраторы БД. В PostgreSQL такого инструмента из коробки нет, поэтому пришлось делать его самостоятельно, опираясь на мои наработки в системе КоСиКУЛС БЕССТ (С), 2006 и ПТК ОрСиМОН БЕССТ (С), 2010. Получившаяся компонента реализует похожий, а в чём то больший функционал, чем оракловая. Хотя она ограничена несколько меньшим объёмом данных, предоставляемых системой статистики СУБД PostgreSQL и общедоступных расширений для неё, по сравнению с СУБД Oracle

Во-первых - в качестве источников основных данных по активности используется два незавимимых источника - свободно доступное расширение pg_wait_sampling, и самописная процедура посекундного сохранения состояния активностей из таблицы pg_stat_activity. Первым был реализован концентратор данных из pg_wait_sampling, обеспечивающего сэмплирование со скоростью 100 выборок в секунду, в отличие от нетеряющей кумулятивной статистики в Oracle. Однако, как и в Oracle, события ожидания не отражают полную картину активности, т.к. не показывают ту активность процессов, при которой событий ожидания нет. Поэтому пришлось создавать и второй агрегатор - на основе секундных выборок из pg_stat_activity. Тут скорость сэмплирования в 100 раз меньше, чем в pg_wait_sampling, всего 1 раз в секунду, но она при этом равна скорости сэмплирования в Oracle, и там ее вполне хватает для получения картины по наиболее ресурсоёмким сессиям и запросам. Современные многопроцессорные системы, вместе с архитектурой самой СУБД, позволяют просто запустить функцию сохранения таких данных, не заморачиваясь разработкой легковесного аргегатора

Во-вторых - здесь родилась идея добавить в инструмент наглядное сравнение данных из двух разных источников. Для понимания работы системы полезно сравнить данные двух источников с разной частотой сэмплирования, и заодно наглядно определить, насколько частота сэмплирования важна для типовых задач администратора БД. Да, данные этих источников не полностью перекрывают друг друга, но в некотором подмножестве они охватывают одну и ту же картину. Поэтому компонента позволяет наглядно посмотреть и сравнить выборки по данным pg_stat_avtivity, которая всё таки основная в силу большего количества полей активности, и pg_wait_sampling

В-третьих - в качестве источников дополнительной информации используются расширения pg_stat_statement - для получения статистик по каждому запросу суммарно, и pg_store_plans - для сохранения планой звпросов и статистик уже по каждому сохранённому плану отдельно. Данные обоих расширений сохраняются в периодических выборках, аналогично оракловому AWR, например, раз в 15 минут, причём первое расширение настроено в режиме кумулятивного сбора статистик, и для него расчитываются приращения статистик между срезами. Это решение спорное, но сейчас сделано так - для того, стобы не терять суммарные статистики. А вот для pg_store_plans после выгрузки данных каждого среза вызывается обнуление счёткиков, потому что иначе объём информации растёт неадекватными темпами, и хранилище статистики может разрастаться очень сильнои

В-четвёртых - в качестве костяка модулей построения графиков активности и экранных форм мной использовались личные наработки из других своих продуктов - КоСиКУЛСб ОрСиМОН и СтатОС. Именно это позволило задать правильные вопросы, поставить задачи, и модернизировать готовые решения для работы уже не с операционной системой и СУБД Oracle, что успешно делает ОрСиМОН, а в PostgreSQL

Компонента "История снапшотов"

Компонента реализована похоже на механизм снапшотов в Oracle AWR. Каждые 15 минут (настраиваемо) запускается процедура снятия снапшота, выгружающая состояние статистических таблиц, и обеспечивающая рассчёт приращений по накопительным статистикам. В настоящее время таким образом обрабатываются статистики БД, ряда фоновых процессов - bgwriter, wal и другие, а статистики таблиц и индексов, и статистики ввода - вывода таблиц и индексов. Фактически реализован такой же механизм, как и в первых версиях моего ОрСиМОН для Oracle v.9, когди никакого AWR в помине не было. Но если в ОрСиМОН источником являлся безоплатный модуль Oracle StatsPack, самостоятельно собирающий снапшоты, то в КАМАктСоСт источником являются таблицы статистик PostgreSQL, предоставляющие данные в моменте и расширения, по которым мы самостоятельно собираем снапшоты и делаем обработки

Таким образом компонента периодически снимает статистические снапшоты, расчитывает приращения статистик, формирует ряды данных и отображает их в табличной и графической формах. Приращения рассчитываются для кумулятивных статистик. Для счётчиков "в моменте" сохраняется именно это значение в моменте снятия снапшота. Общее количество статистик переваливает за сотню, но графики динамики в текущей версии КАМАктСоСт v.1.1 строятся по 74 показателям. Так же, как и в ОрСиМОН версии от 2008 года, есть возможность посмотреть текущие значения статистик, значения для произвольно выбранного снапшота и как раз получить ряды данных для непрерывного диапазона снапшотов

Говорить о том, что PostgreSQL категорически беднее Оракла по функционалу становится всё сложнее. Здесь на передний план выходят как раз возможности открытого продукта, отдельные компоненты которого можно расширять, модифицировать и надстраивать. В частности в PostgreSQL есть потабличная и поиндексная статистика попадания в буферный кеш, можно настраивать методы сэмплирования событий ожидания и т.п. вещи. Архитектурное решение версионности строки вообще является гораздо более легковесной в моменте операцией, чем оракловые пространства отмены. Хотя и приходилось слышать, что для сверхнагруженных систем UNDO производительнее. Думаю себе, что эта СУБД вполне способна обеспечить работу со сложными задачами. Да, ей не хватает инструментария, но вот этот аспект в какой то части и призван обеспечить функционал КАМАктСоСт, и продукты других авторов

Компонента "Прогресс операций"

В текущей реализации модули WEB форм производят опрос системного каталога выбранных БД или кластера и отображают данные по прогрессу шести видов операций - base backup, vacuum, analyze, cluster, indexes, copy. Делать по состояниям операций срезы не имеет большого смысла, это операции, производимые в моменте, и за промежуток между снапшотами, например, в 15 минут, и даже 5 минут, может пройти масса некумулятивных операций. Поэтому реализовано только отображение текущего состояния этих административных представлений, а также возможность включения автообновления страниц в периодичностью в 10, 30 и 60 секунд для более удобного визуального контроля

Компонента "Аналитика и отчёты"

В настоящий момент - не публично