Сценарии использования Kintsugi (DBCM)#

Kintsugi (DBCM) поддерживает два вида сценариев использования: целевой и опциональный.

Целевое использование предусматривает полнофункциональное взаимодействие с Platform V Pangolin DB (PSQ), объединяющее в себе решение задач сопровождения и обслуживания СУБД.

Опциональное использование предусматривает ограниченное взаимодействие с СУБД без хранения учетных данных и настроек подключений. Данный вариант реализован в виде клиентского приложения для Microsoft Windows.

Примечание

Опциональное использование Kintsugi (DBCM) не доступно для продукта Platform V Kintsugi (DBM) редакция Standard.

Сценарии целевого использования Kintsugi (DBCM)#

1. Вход в систему#

Примечание

Вход в систему выполняют все пользователи независимо от используемой ролевой модели.

Сценарий выполняется по шагам:

  1. Оператор получает у Администратора URL-адрес и учетную запись.

  2. Оператор открывает в браузере URL-адрес Kintsugi (DBCM).

  3. Оператор перенаправляется на адрес OpenID provider и проходит процедуру авторизации предложенным способом.

    В случае успеха оператор перенаправляется обратно на URL-адрес Kintsugi (DBCM).

  4. В случае успешной авторизации Kintsugi (DBCM) откроет стартовую страницу, и начнется новый сеанс работы.

Исключительные сценарии#

Оператор не прошел аутентификацию OpenID provider. Он не будет перенаправлен на URL-адрес Kintsugi (DBCM). Если оператор самостоятельно перейдет на URL-адрес Kintsugi (DBCM), то он не получит доступ в систему и будет перенаправлен на адрес OpenID provider.

2. Создание конфигурации кластера#

Сценарий выполняется по шагам:

  1. Пользователь SQL-редактора добавляет конфигурацию кластера в пользовательском интерфейсе Kintsugi (DBCM).

  2. Пользователь SQL-редактора заполняет недостающие параметры для создания конфигурации кластера (символом * обозначены обязательные для указания параметры):

    • название кластера *;

    • комментарий;

    • параметры, описывающие соединение:

      • название СУБД *;

      • хост или IP-адрес сервера *;

      • порт СУБД *;

      • имя базы данных *;

      • логин пользователя *;

      • пароль пользователя;

      • информацию о роли, используемую при подключении:

        • имя роли;

        • тайм-аут;

        • комментарий;

      • SSL-параметры подключения:

        • SSL-режим (выбрать из предложенных);

        • СА-файл (загрузить файл);

        • сертификат клиента (загрузить файл);

        • ключ клиента (загрузить файл).

  3. Пользователь SQL-редактора сохраняет конфигурации кластера.

  4. Kintsugi (DBCM) добавляет конфигурацию кластера в зоне видимости аккаунта пользователя.

Исключительные сценарии#

Ниже приведены исключительные сценарии для добавления конфигурации кластера:

  1. Пользователь SQL-редактора может выбрать один из доступных для него шаблонов и заполнить пустые поля, создав таким образом экземпляр подключения.

  2. При невозможности сохранить кластер пользователю SQL-редактора выводится сообщение об ошибке.

3. Изменение конфигурации кластера#

Сценарий выполняется по шагам:

  1. Пользователь SQL-редактора инициирует изменение параметров конфигурации кластера.

  2. Пользователь SQL-редактора меняет один или несколько параметров конфигурации кластера. Перечень параметров приведен в сценарии «Создание конфигурации кластера».

  3. Пользователь SQL-редактора сохраняет информацию.

  4. Kintsugi (DBCM) обновляет информацию о кластере для этого пользователя SQL-редактора.

Исключительные сценарии#

При невозможности сохранить измененную конфигурацию кластера пользователю SQL-редактора выводится сообщение об ошибке.

4. Удаление конфигурации кластера#

Сценарий выполняется по шагам:

  1. Пользователь SQL-редактора инициирует удаление конфигурации кластера из Kintsugi (DBCM).

  2. Kintsugi (DBCM) удаляет метаинформацию об экземпляре СУБД.

Исключительные сценарии#

При отсутствии возможности удалить кластер пользователю SQL-редактора выводится сообщение об ошибке.

5. Создание конфигурации кластера по шаблону#

Сценарий выполняется по шагам:

  1. Пользователь SQL-редактора выбирает один из шаблонов кластеров, доступных для его аккаунта.

  2. Пользователь SQL-редактора заполняет необходимые параметры для создания конфигурации кластера по шаблону. Перечень параметров приведен в сценарии «Создание конфигурации кластера».

  3. Пользователь SQL-редактора сохраняет шаблон.

  4. Kintsugi (DBCM) создает конфигурацию кластера в зоне видимости аккаунта пользователя SQL-редактора.

Исключительные сценарии#

При невозможности сохранить конфигурацию кластера пользователю SQL-редактора выводится сообщение об ошибке.

6. Получение списка кластеров и шаблонов#

Сценарий выполняется по шагам:

  1. Пользователь SQL-редактора открывает страницу Кластеры.

  2. Kintsugi (DBCM) отображает пользователю список кластеров и шаблонов.

Исключительные сценарии#

При невозможности получить список кластеров и шаблонов пользователю SQL-редактора выводится сообщение об ошибке.

7. Открытие подключения к БД#

Сценарий выполняется по шагам:

  1. Пользователь SQL-редактора выбирает одно из ранее сконфигурированных соединений.

  2. Пользователь SQL-редактора запрашивает установку подключения к выбранному экземпляру СУБД.

  3. Kintsugi (DBCM) выводит на экран в открывшемся SQL-редакторе статус текущего подключения к СУБД.

Исключительные сценарии#

При невозможности открытия подключения к БД пользователю SQL-редактора выводится сообщение об ошибке.

8. Выполнение SQL-запросов к БД#

Сценарий выполняется по шагам:

  1. Пользователь SQL-редактора выбирает одно из ранее сконфигурированных соединений.

  2. Пользователь SQL-редактора запрашивает установку подключения к выбранному экземпляру СУБД.

  3. Kintsugi (DBCM) устанавливает соединение с экземпляром СУБД и предоставляет пользователю SQL-редактора интерфейс для выполнения SQL-запросов.

  4. Пользователь исполняет одиночный или последовательность SQL-запросов.

  5. Kintsugi (DBCM) выводит на экран результат выполнения запроса.

Исключительные сценарии#

При невозможности выполнения SQL-запроса к БД пользователю SQL-редактора выводится сообщение об ошибке.

9. Просмотр структуры БД#

Сценарий выполняется по шагам:

  1. Пользователь SQL-редактора выбирает одно из ранее сконфигурированных соединений.

  2. Пользователь SQL-редактора запрашивает установку подключения к экземпляру СУБД.

  3. Kintsugi (DBCM) устанавливает соединение с экземпляром СУБД и предоставляет пользователю интерфейс для выполнения SQL-запросов.

  4. Пользователь SQL-редактора открывает вкладку Структура.

  5. Kintsugi (DBCM) выводит на экран дерево объектов выбранной базы данных.

Исключительные сценарии#

При невозможности просмотра структуры БД пользователю SQL-редактора выводится сообщение об ошибке.

10. Добавление объекта мониторинга#

Сценарий выполняется по шагам:

  1. Администратор мониторинга создает объект мониторинга в графическом интерфейсе Kintsugi (DBCM).

  2. Администратор мониторинга заполняет необходимые параметры для создания объекта мониторинга (обязательные параметры обозначены символом *):

    • название экземпляра мониторинга *;

    • хост или IP-адрес сервера *;

    • порт СУБД *;

    • логин пользователя *;

    • пароль пользователя;

    • комментарий;

    • информацию о базе данных:

      • имена наблюдаемых баз данных;

      • имя базы данных для подключения;

    • SSL-параметры подключения:

      • SSL-режим (выбрать из предложенных);

      • CA-файл (загрузить файл);

      • сертификат клиента (загрузить файл);

      • ключ клиента (загрузить файл).

Исключительные сценарии#

Если при создании объекта не были указаны данные для аутентификации, при подключении будет использоваться учетная запись мониторинга по умолчанию (указывается при развертывании Kintsugi (DBCM)).

11. Изменение объекта мониторинга#

Сценарий выполняется по шагам:

  1. Администратор мониторинга запрашивает список объектов мониторинга.

  2. Kintsugi (DBCM) возвращает администратору мониторинга список объектов мониторинга.

  3. Администратор мониторинга инициирует изменение информации о подключении к объекту мониторинга.

  4. Администратор мониторинга меняет один или несколько параметров подключения к экземпляру. К изменению доступны параметры, указанные в сценарии «Добавление объекта мониторинга».

  5. Администратор мониторинга инициирует сохранение настроек объекта мониторинга.

  6. Kintsugi (DBCM) сохраняет обновленные настройки объекта мониторинга в репозитории метаданных.

  7. Сервис сбора данных мониторинга в ходе периодической сверки конфигурации определяет факт обновления параметров и применяет новую конфигурацию.

Исключительные сценарии#

Если в обновленных настройках объекта не указаны данные для аутентификации, при подключении будет использоваться учетная запись мониторинга по умолчанию (указывается при развертывании Kintsugi (DBCM)).

12. Удаление объекта мониторинга#

Сценарий выполняется по шагам:

  1. Администратор мониторинга удаляет объект мониторинга из Kintsugi (DBCM).

  2. Kintsugi (DBCM) удаляет конфигурацию объекта мониторинга из репозитория метаданных.

  3. Сервис сбора данных мониторинга в ходе периодической сверки конфигурации определяет факт удаления конфигурации и прекращает сбор данных для соответствующего объекта мониторинга.

Исключительные сценарии для удаления объекта мониторинга отсутствуют.

13. Получение списка объектов мониторинга#

Сценарий выполняется по шагам:

  1. Администратор мониторинга переходит на страницу Метрики и выбирает вкладку Управление метриками.

  2. Kintsugi (DBCM) отображает администратору мониторинга список объектов мониторинга.

Исключительные сценарии#

При невозможности получить список объектов мониторинга администратору мониторинга выводится сообщение об ошибке.

14. Добавление множества объектов мониторинга#

Примечание

Для выполнения сценария требуется список множества объектов мониторинга в формате JSON-документа.

Сценарий выполняется по шагам:

  1. Администратор мониторинга копирует в Kintsugi (DBCM) ранее сформированный список множества объектов мониторинга.

  2. Администратор мониторинга отправляет запрос на добавление объектов мониторинга (в одном запросе можно создать множество объектов).

  3. Kintsugi (DBCM) создает список объектов мониторинга, ассоциированных с указанными пользователями.

  4. Kintsugi (DBCM) массово добавляет конфигурации объектов мониторинга.

Исключительные сценарии для добавления множества объектов мониторинга отсутствуют.

15. Получение списка доступных объектов мониторинга#

  1. Пользователь переходит на страницу Метрики и выбирает пункт Управление метриками.

  2. Kintsugi (DBCM) отображает пользователю список объектов мониторинга.

Исключительные сценарии#

При невозможности получить список объектов мониторинга пользователю выводится сообщение об ошибке.

16. Просмотр метрик выбранного объекта мониторинга#

Сценарий выполняется по шагам:

  1. Пользователь выбирает один из доступных объектов мониторинга.

  2. Пользователь выбирает группу метрик или определенную метрику для просмотра, а также диапазон отображения.

  3. Kintsugi (DBCM) возвращает выбранные значения метрик.

Исключительные сценарии#

В случае ошибки Kintsugi (DBCM) при просмотре данных объекта мониторинга пользователю будет выведено на экран окно ошибки с ее текстовым описанием.

17. Добавление множества шаблонов конфигураций кластеров#

Примечание

Для выполнения сценария требуется список множества шаблонов конфигураций кластеров в формате JSON-документа.

Сценарий выполняется по шагам:

  1. Bulk (пользователь с ролью Bulk) копирует в Kintsugi (DBCM) ранее сформированный список множества шаблонов кластеров.

  2. Bulk (пользователь с ролью Bulk) отправляет запрос на добавление шаблонов кластеров (в одном запросе можно создать множество шаблонов кластеров).

  3. Kintsugi (DBCM) создает список шаблонов кластеров, ассоциированных с указанными пользователями.

  4. Kintsugi (DBCM) массово добавляет конфигурации шаблонов кластеров.

Исключительные сценарии для добавления множества шаблонов кластеров отсутствуют.

18. Создание быстрого отчета#

Сценарий выполняется по шагам:

  1. Пользователь выбирает один из доступных объектов мониторинга.

  2. Пользователь открывает панель мониторинга Информация о производительности и нажимает кнопку Создать отчет.

  3. Пользователь выбирает подключение, БД, сервер и нажимает кнопку Быстрый отчет.

  4. Kintsugi (DBCM) формирует быстрый отчет (по двум последним выборкам сервера) в новой вкладке браузера.

Исключительные сценарии#

В случае ошибки Kintsugi (DBCM) при создании быстрого отчета пользователю будет выведено на экран окно об ошибке.

19. Создание отчета по параметрам#

Сценарий выполняется по шагам:

  1. Пользователь выбирает один из доступных объектов мониторинга.

  2. Пользователь открывает панель мониторинга Информация о производительности и нажимает кнопку Создать отчет.

  3. Пользователь выбирает подключение, БД, сервер и нажимает кнопку Отчет по параметрам.

  4. Пользователь задает параметры отчета и нажимает кнопку Создать.

  5. Kintsugi (DBCM) формирует отчет по заданным параметрам в новой вкладке браузера.

Исключительные сценарии#

В случае ошибки Kintsugi (DBCM) при создании отчета по параметрам пользователю будет выведено на экран окно об ошибке.

20. Настройка метрик объекта мониторинга#

Сценарий выполняется по шагам:

  1. Пользователь (или администратор мониторинга) запрашивает список объектов мониторинга.

  2. Kintsugi (DBCM) возвращает список объектов мониторинга.

  3. Пользователь (или администратор мониторинга) открывает окно редактирования метрик.

  4. Пользователь (или администратор мониторинга) включает (или отключает) необходимые метрики из предложенного списка, при необходимости задает их пороговые значения.

  5. Пользователь (или администратор мониторинга) инициирует сохранение настроек объекта мониторинга.

  6. Kintsugi (DBCM) сохраняет обновленные настройки метрик объекта мониторинга в репозитории метаданных, а настройки пороговых значений в БД порогов.

  7. Сервис сбора данных мониторинга в ходе периодической сверки конфигурации определяет факт обновления параметров и применяет новую конфигурацию.

Исключительные сценарии для настройки метрик объекта мониторинга отсутствуют.

21. Получение сводной информации о состоянии объектов мониторинга#

Сценарий выполняется по шагам:

  1. Пользователь (Пользователь SQL-редактора или Администратор мониторинга) открывает страницу Оперативный центр.

  2. Kintsugi (DBCM) отображает сводные данные объектов мониторинга.

Исключительные сценарии для получения данных объекта оперативного центра отсутствуют.

22. Настройка оповещений#

Сценарий выполняется по шагам:

  1. Пользователь указывает почтовый адрес, на который будут приходить уведомления (отчет) и настраивает группы узлов для получения нотификации.

  2. Пользователь вводит данные в специальную форму, которую обрабатывает Kintsugi.

  3. Kintsugi выполняет API-вызов создания подписок сервиса alerting.

  4. Kintsugi извлекает username пользователя.

  5. Данные о пользовательских выборах сохраняются в БД таблицах сервиса.

Исключительные сценарии для настройки оповещений отсутствуют.

Сценарии использования DB Advisor#

DB Advisor — опциональный компонент Platform V Kintsugi (DBM) редакции Enterprise для интеллектуальной диагностики экземпляров PostgreSQL / Platform V Pangolin DB с помощью LLM.

23. Запуск AI-диагностики#

Сценарий выполняется по шагам:

  1. Пользователь с привилегией asset_pg_ai_run открывает раздел DB Advisor в пользовательском интерфейсе Kintsugi (DBCM).

  2. Пользователь выбирает экземпляр СУБД из списка доступных объектов мониторинга.

  3. Пользователь на вкладке Здоровье нажимает кнопку Запустить снова.

  4. DB Advisor проверяет отсутствие активного прогона для выбранного экземпляра и создает новый прогон диагностики.

  5. DB Advisor выполняет пре-скрининг (PreScreener) — набор быстрых читающих проверок без LLM (блокировки, мертвые кортежи, неиспользуемые индексы и т. п.).

  6. DB Advisor параллельно запускает пять специализированных агентов (Workload, Index, Vacuum, Configuration, Connection), каждый из которых выполняет цикл ReAct: рассуждение → выполнение предопределенного читающего запроса → анализ результата → формирование находок.

  7. DB Advisor соотносит находки разных агентов по общим сущностям и формирует перекрестные ссылки.

  8. Планировщик формирует приоритизированную сводку рекомендаций с фазами и уровнями риска.

  9. DB Advisor рассчитывает индекс здоровья (0–100) на основе совокупной оценки всех находок.

  10. DB Advisor выводит на экран результаты диагностики: индекс здоровья, активные проблемы, тренд, список находок с уровнями серьезности и таблицу последних прогонов.

Исключительные сценарии#

  1. При наличии активного прогона для выбранного экземпляра пользователю выводится сообщение о том, что диагностика уже выполняется, и предложение подождать завершения.

  2. При отсутствии привилегии asset_pg_ai_run пользователю выводится сообщение об ошибке доступа.

  3. При ошибке подключения к экземпляру СУБД пользователю выводится сообщение об ошибке с описанием причины.

  4. При недоступности LLM-провайдера прогон завершается со статусом «Ошибка» с указанием недоступного провайдера.

24. Просмотр результатов AI-диагностики#

Сценарий выполняется по шагам:

  1. Пользователь с привилегией asset_pg_ai_view открывает раздел DB Advisor и выбирает экземпляр СУБД.

  2. На вкладке Здоровье в раскрывающемся списке Дата диагностики пользователь выбирает нужный прогон из списка доступных.

  3. DB Advisor отображает результаты выбранного прогона: индекс здоровья, активные проблемы, тренд изменения индекса за последние 5 прогонов, AI-сводку.

  4. Пользователь просматривает список находок, при необходимости применяя фильтры по уровню серьезности, агенту или статусу.

  5. Пользователь открывает детальную информацию по находке: описание проблемы, доказательную базу (метрики, значения параметров, результаты запросов к системным каталогам), рекомендуемые действия с возможностью копирования SQL-команд, связанные находки по общим сущностям.

  6. Пользователь просматривает таблицу последних прогонов и при необходимости переходит к детальному отчету.

Исключительные сценарии#

  1. При отсутствии привилегии asset_pg_ai_view пользователю выводится сообщение об ошибке доступа.

  2. При отсутствии завершенных прогонов для выбранного экземпляра пользователю выводится сообщение о том, что диагностика еще не выполнялась.

25. Управление находками AI-диагностики#

Сценарий выполняется по шагам:

  1. Пользователь с привилегией asset_pg_ai_run открывает раздел DB Advisor и выбирает экземпляр СУБД.

  2. На вкладке Здоровье в раскрывающемся списке Дата диагностики пользователь выбирает нужный прогон.

  3. В области Находки пользователь выбирает нужную находку в списке.

  4. В области Детальная информация о находке пользователь изучает описание проблемы, доказательную базу и рекомендуемые действия.

  5. Пользователь принимает решение по находке, нажав одну из кнопок:

    • В работу — находка взята в работу для координации между несколькими пользователями;

    • Отметить исправленным — проблема устранена;

    • Пропустить — находка отклонена, пользователь не хочет видеть ее повторно.

  6. DB Advisor сохраняет решение в журнале смен статуса (аудит решений) и пересчитывает индекс здоровья.

  7. DB Advisor выводит на экран обновленный индекс здоровья и статус находки.

Исключительные сценарии#

  1. При отсутствии привилегии asset_pg_ai_run пользователю выводится сообщение об ошибке доступа.

  2. При отсутствии завершенных прогонов для выбранного экземпляра пользователю выводится сообщение о том, что диагностика еще не выполнялась.

Сценарии опционального использования Kintsugi (DBCM)#

Сценарии опционального использования выполняются оператором с ролью Доступ к функциональности desktop-приложения (далее – оператор desktop-приложения).

1. Запуск desktop-приложения#

Сценарий выполняется по шагам:

  1. Оператор desktop-приложения обращается к Администратору для получения данных УЗ Kintsugi (DBCM) и конфигурационных параметров отдельной СУБД или кластера.

  2. Оператор desktop-приложения открывает консоль Microsoft Windows.

  3. Оператор desktop-приложения выполняет команду запуска клиентского приложения.

  4. Клиентское приложение запускается и выводит на экран стартовую страницу.

Исключительные сценарии#

Клиентское приложение не прошло аутентификацию под УЗ Kintsugi (DBCM).

2. Открытие подключения к БД#

Сценарий выполняется по шагам:

  1. Оператор desktop-приложения выбирает из списка доступную БД.

  2. Оператор desktop-приложения нажимает кнопку + SQL-редактор.

  3. Клиентское приложение выводит на экран в открывшемся SQL-редакторе статус текущего подключения к СУБД.

Исключительные сценарии#

При невозможности открытия подключения к БД оператору desktop-приложения выводится сообщение об ошибке.

3. Выполнение SQL-запросов к подключенной БД#

Сценарий выполняется по шагам:

  1. Оператор desktop-приложения открывает SQL-редактор и подключается к БД.

  2. Оператор desktop-приложения исполняет одиночный или последовательность SQL-запросов.

  3. Клиентское приложение выводит на экран результат выполнения запроса.

Исключительные сценарии#

При невозможности выполнения SQL-запроса к подключенной БД оператору desktop-приложения выводится сообщение об ошибке.

4. Просмотр структуры подключенной БД#

Сценарий выполняется по шагам:

  1. Оператор desktop-приложения открывает SQL-редактор и подключается к БД.

  2. Оператор desktop-приложения открывает вкладку Структура в SQL-редакторе.

  3. Клиентское приложение выводит на экран дерево объектов выбранной БД.

Исключительные сценарии#

При невозможности просмотра структуры БД оператору desktop-приложения выводится сообщение об ошибке.

5. Создание быстрого отчета#

Сценарий выполняется по шагам:

  1. Оператор desktop-приложения нажимает кнопку Создать отчет на стартовой странице.

  2. Оператор desktop-приложения выбирает сервер и нажимает кнопку Быстрый отчет.

  3. Kintsugi (DBCM) формирует быстрый отчет (по двум последним выборкам сервера) и выводит на экран.

Исключительные сценарии#

В случае ошибки Kintsugi (DBCM) при создании быстрого отчета оператору desktop-приложения будет выведено на экран окно об ошибке.

6. Создание отчета по параметрам#

Сценарий выполняется по шагам:

  1. Оператор desktop-приложения нажимает кнопку Создать отчет на стартовой странице.

  2. Оператор desktop-приложения выбирает сервер и нажимает кнопку Отчет по параметрам.

  3. Оператор desktop-приложения задает параметры отчета и нажимает кнопку Создать.

  4. Kintsugi (DBCM) формирует отчет по заданным параметрам и выводит на экран.

Исключительные сценарии#

В случае ошибки Kintsugi (DBCM) при создании быстрого отчета оператору desktop-приложения будет выведено на экран окно об ошибке.