В истории активных сеансов виден EXECUTE, а исходный подготовленный оператор скрыт. Администратор знает, что 1С ждёт PostgreSQL, но не видит конкретный SQL-запрос.
PPEM 2.9 закрывает этот разрыв. Релиз от 27 августа 2026 года показывает исходные подготовленные операторы и ведёт из истории сеансов в SQL-статистику по query_id.
Практический вывод такой: обновление стоит проверить на пилотном контуре, если диагностика заканчивается на активном сеансе. Ради обновлённого интерфейса менять рабочую установку не нужно.
От кластера до SQL-запроса — в одном маршруте
Предыдущая схема диагностики могла оборваться на операторе EXECUTE. Он указывал на выполнение подготовленного запроса, но не раскрывал исходный текст этого запроса.
Версия 2.9 показывает исходный подготовленный оператор. Администратор получает текст, который можно сопоставить с ожиданиями, планом выполнения и статистикой.
Следующее изменение связывает два диагностических экрана. Из истории активных сеансов теперь можно перейти в SQL-статистику по query_id — идентификатору запроса в PostgreSQL.
Это полезно при разборе задержек 1С. Вы начинаете с общей нагрузки, находите проблемный сеанс, раскрываете оператор и переходите к накопленной статистике его SQL-запроса.
| Изменение в PPEM 2.9 | Где искать | Что получает администратор 1С | Как использовать |
|---|---|---|---|
| Просмотр кластеров вместе с экземплярами | Центр оперативного контроля | Общую картину по группе узлов | Выбрать кластер с отклонением до разбора отдельных экземпляров |
| Исходные подготовленные операторы | История активных сеансов | Текст запроса вместо одного EXECUTE | Связать ожидание сеанса с конкретным SQL |
Переход по query_id | История активных сеансов и SQL-статистика | Связь текущего сеанса с накопленной статистикой | Проверить, повторяется ли проблема и как часто выполняется запрос |
| Управление параметрами профиля | История активных сеансов | Настройку собираемых данных | Подготовить профиль под проверяемый сценарий |
| Выгрузка профиля без агрегирования | История активных сеансов | Исходные записи для внешней системы | Разбирать данные своими средствами, не ограничиваясь графиком PPEM |
| Изменённые фильтры и графики | Интерфейс истории сеансов | Другой порядок работы с интервалами и единицами | Проверить привычные представления во время пилота |
Релиз сокращает путь от общей нагрузки до конкретного запроса. Документация Postgres Professional не сообщает, сколько минут это экономит, поэтому обещать ускорение диагностики в процентах нельзя.
Новый маршрут не заменяет проверку остальных уровней. Задержку могут создавать диск, память хоста, процесс 1С, блокировка или фоновая работа PostgreSQL.
Если PPEM показывает только часть картины, пригодится отдельный порядок контроля хоста, PostgreSQL и серверных процессов 1С. Он помогает не принять медленный SQL за единственную причину задержки.
Выгрузка профиля нужна не каждой установке
PPEM 2.9 умеет очищать и загружать данные профиля истории активных сеансов. Параметрами профиля теперь можно управлять из того же инструмента.
При выгрузке данные остаются необработанными. PPEM не сворачивает их в готовые интервалы и не оставляет только точки для графика.
Это даёт свободу внешней системе. Она может хранить исходные записи, применять свои правила группировки и сопоставлять их с событиями на других уровнях контура 1С.
Но сама возможность выгрузки ещё не оправдывает обновление. Сначала ответьте, куда пойдут данные и кто будет разбирать их после выгрузки.
Если получателя нет, новая функция останется пунктом меню. Если у вас уже работает внешняя система наблюдения, проверьте формат данных и объём хранения на пилоте.
Отдельно задайте срок хранения. Документация релиза не приводит типового объёма профиля, поэтому размер репозитория нужно измерить на вашей нагрузке.
mTLS меняет правила связи между агентами и менеджером
В обычной схеме PPEM менеджер принимает данные от агентов. Версия 2.9 добавляет взаимную TLS-аутентификацию, или mTLS, к схеме с API-ключами.
При mTLS менеджер проверяет сертификат агента, а агент — сертификат менеджера. Одного API-ключа для подтверждения второй стороны уже недостаточно.
Такой режим нужен, когда служебный трафик проходит через недоверенный сегмент. Он также уместен при внутренних требованиях к взаимной проверке серверных компонентов.
Настройки mTLS находятся в ppem-manager.yml и ppem-agent.yml. Это указано в анонсе Postgres Professional о выпуске PPEM 2.9.
Документация релиза не содержит готовой схемы выпуска сертификатов для вашей инфраструктуры. Не копируйте случайные команды из чужой инструкции: состав цепочки зависит от вашего удостоверяющего центра.
| Что проверить до пилота | Менеджер PPEM | Агент PPEM | Признак готовности |
|---|---|---|---|
| Сертификат узла | Сертификат соответствует имени менеджера | Сертификат соответствует имени агента | Обе стороны принимают имена из сертификатов |
| Цепочка доверия | Доверяет центру, выдавшему сертификат агента | Доверяет центру, выдавшему сертификат менеджера | HTTPS-соединение проходит взаимную проверку |
| Срок действия | Сертификат действует весь срок пилота | Сертификат действует весь срок пилота | Проверка не выдаёт ошибку срока |
| Доступность HTTPS | Порт доступен агентам | Маршрут к менеджеру открыт | Агент устанавливает соединение без обхода проверки |
| Файл конфигурации | Изменения внесены в ppem-manager.yml | Изменения внесены в ppem-agent.yml | Компоненты читают нужные параметры после штатного перезапуска |
| Возврат к прежней схеме | Сохранена копия текущей конфигурации | Сохранена копия текущей конфигурации | Пилот можно откатить без ручного восстановления параметров |
Пилот mTLS закончен только после проверки обеих сторон. Успешное открытие интерфейса менеджера ничего не говорит о проверке сертификата агента.
Не ограничивайтесь первым подключением. Перезапустите менеджер и один агент штатным способом, затем убедитесь, что связь восстановилась.
Проверьте и замену сертификата. Если этот сценарий не описан внутри компании, mTLS добавит контроль при соединении, но создаст новый риск при продлении.
Удаление экземпляра больше не обрывает связанные операции
Обновление затрагивает не только диагностику. В PPEM 2.9 при удалении экземпляра можно переназначить его задачи и перепривязать хранилища резервных копий.
Раньше удаление экземпляра требовало внимательнее разбирать связанные сущности. Теперь интерфейс предлагает сохранить нужные связи через переназначение.
Версия 2.9 также показывает подробности ошибок экземпляра. Администратор получает больше данных до решения о повторном запуске задания или изменении настройки.
Для хранилищ метрик появился ещё один управляемый сценарий. При удалении такого хранилища можно удалить привязанные триггеры.
Эти изменения пригодятся при выводе узла из эксплуатации и перестройке контура. Они не дают самостоятельного основания обновлять установку, где экземпляры годами не меняются.
| Ситуация | Прежний риск | Действие в PPEM 2.9 | Что проверить после действия |
|---|---|---|---|
| Удаление экземпляра СУБД | Связанные задания теряют прежнюю точку выполнения | Переназначить задания на другой экземпляр | Следующий запуск прошёл на выбранном узле |
| Перенос резервного копирования | Хранилище остаётся связано с удаляемым экземпляром | Перепривязать хранилище | Новая резервная копия попала в нужное хранилище |
| Ошибка экземпляра | В интерфейсе не хватает деталей для первичного разбора | Открыть подробную информацию об ошибке | Причина зафиксирована до перезапуска |
| Удаление хранилища метрик | Привязанные триггеры остаются без нужной цели | Удалить связанные триггеры вместе с хранилищем | В правилах нет потерявших цель триггеров |
| Рост репозитория PPEM | Заполненный диск останавливает сервер | Вручную очистить таблицы из правил очистки | Свободное место выросло, штатное правило продолжает работать |
Эти функции оправдывают переход у тех, кто уже сталкивается с удалением экземпляров, переносом заданий или ростом репозитория. Для стабильной установки они остаются запасными операциями.
Ручная очистка репозитория — аварийный инструмент, а не расписание
PPEM хранит служебные данные в собственном репозитории. Если его таблицы растут, заполненный диск может остановить сервер Enterprise Manager.
В версии 2.9 администратор может вручную очистить таблицы, включённые в правила очистки репозитория. Postgres Professional связывает эту функцию с предотвращением остановки из-за нехватки места.
Ручную очистку не стоит превращать в регулярную операцию. Постоянный рост означает, что срок хранения, расписание или объём диска не соответствуют потоку данных.
До очистки проверьте, какие таблицы входят в правило. Затем зафиксируйте свободное место и повторите замер после операции.
Если место быстро заканчивается снова, ищите причину роста. Однократная очистка лишь возвращает сервер в рабочее состояние.
Подробностей о допустимом остатке свободного места в описании релиза нет. Порог тревоги нужно задать по вашей скорости роста и времени реакции администратора.
Расчёт здесь прост. Если репозиторий прибавляет 10 ГБ за сутки, а дежурный реагирует за два дня, запас ниже 20 ГБ уже не покрывает этот интервал. Добавьте резерв на сбой очистки и рост нагрузки.
При другой скорости подставьте свой суточный прирост. Минимальный запас равен приросту за сутки, умноженному на время реакции.
BiHA требует отдельной проверки после обновления
PPEM 2.9 добавляет настройку минимального числа исправных узлов BiHA-кластера. Она доступна при создании, редактировании и изменении топологии.
Владельцу BiHA нужно записать текущее значение до пилота. После обновления проверьте, какое значение показывает интерфейс и как оно связано с вашей топологией.
Одной смены лидера для такой проверки мало. 1С должна подключиться через рабочий маршрут и выполнить запись после переключения.
Готовая последовательность есть в протоколе проверки BiHA с прикладной записью из 1С. Он отделяет работоспособность кластера СУБД от доступности самой информационной базы.
Рабочий контур обновляют после отдельного пилота
Официальная документация PPEM 2.9 отсылает к главе 73 с инструкцией по обновлению. Используйте её вместо команд, собранных для прежней версии или другого дистрибутива.
Пилот должен повторять вашу схему связи. Зафиксируйте версии менеджера и агентов, список экземпляров, способ аутентификации и связанные задания.
Не нужно копировать весь рабочий контур. Достаточно воспроизвести те связи, которые затрагивает обновление: менеджер, агент, тестовый экземпляр и нужное хранилище.
Сначала проверьте вход в интерфейс и связь с агентом. Затем пройдите тот сценарий, ради которого начали обновление.
Для диагностики это путь от кластера до SQL-статистики. Для mTLS — взаимная проверка сертификатов после перезапуска компонентов.
После этого запустите штатное задание и резервное копирование. Если пилот затрагивает удаление экземпляра, проверьте переназначение на тестовых сущностях.
Перед рабочим переходом пригодится порядок проверки версии и подготовки остановки PostgreSQL. Он написан для другого обновления Postgres Pro, но контроль редакции и подготовка окна остаются уместными.
Не переносите из него команды автоматически. Для PPEM используйте главу обновления именно из документации версии 2.9.
| Этап пилота | Что зафиксировать | Что выполнить | Когда переходить дальше |
|---|---|---|---|
| Исходное состояние | Версии менеджера и агентов, список связей | Сохранить конфигурации и параметры аутентификации | Исходную схему можно восстановить |
| Обновление | Пакеты и сообщения установщика | Пройти официальную инструкцию PPEM 2.9 | Менеджер и агент запускаются без новых ошибок |
| Диагностика | Тестовый запрос и нужный интервал | Пройти от активного сеанса к query_id | Исходный оператор и SQL-статистика доступны |
| mTLS | Сертификаты и цепочки доверия | Проверить соединение в обе стороны | Обе стороны подтверждают сертификаты |
| Штатные задания | Расписания и точки назначения | Запустить задание и резервное копирование | Результат появился в ожидаемом месте |
| Возврат | Копии конфигураций и порядок отката | Восстановить прежнюю схему на пилоте | Откат проходит без ручного поиска параметров |
Если пилот не воспроизводит нужную операцию, он проверяет лишь запуск интерфейса. Рабочего основания для обновления такой результат не даёт.
Решение об обновлении PPEM 2.9
Обновляйте PPEM после пилота, если нужен хотя бы один из пяти сценариев:
- просмотр кластеров в центре оперативного контроля;
- переход от активного сеанса к SQL-статистике по
query_id; - просмотр исходных подготовленных операторов;
- выгрузка данных профиля без агрегирования;
- взаимная TLS-аутентификация менеджера и агентов.
Отложите переход, если вас интересуют только новые формы, фильтры и графики. Изменённый интерфейс не оправдывает риск обновления рабочего контура.
Владельцам BiHA добавьте шестое условие: проверьте минимальное число исправных узлов и прикладную запись из 1С. Тем, у кого растёт репозиторий, нужен отдельный тест ручной очистки и повторного роста.
Правило короткое: сначала выберите операцию, которой вам не хватает, затем воспроизведите её на пилоте. Нет проверяемой операции — нет причины трогать рабочую установку.