Сценарии использования 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. Данные о пользовательских выборах сохраняются в БД таблицах сервиса.

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

Сценарии опционального использования 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-приложения будет выведено на экран окно об ошибке.