OpenAPI для Managed Postgres
Используйте ClickHouse OpenAPI, чтобы программно управлять сервисами Managed Postgres так же, как сервисами ClickHouse. Тот же API также предоставляет [конечную точку Prometheus] для сбора метрик сервиса. Уже знакомы с OpenAPI? Получите [ключи API] и сразу переходите к справочнику по API Managed Postgres. Если нет, ниже приведён краткий обзор.
Ключи API
Для использования ClickHouse OpenAPI требуется аутентификация; о том, как создать ключи, см. в разделе [Ключи API]. Затем используйте их в учетных данных Basic Auth следующим образом:
Идентификатор организации
Далее вам понадобится идентификатор организации.
- Выберите название организации в левом нижнем углу консоли.
- Выберите Сведения об организации.
- Нажмите значок копирования справа от Идентификатор организации, чтобы сразу скопировать его в буфер обмена.
Теперь его можно использовать в запросах, например так:
Итак, вы выполнили свой первый запрос к Postgres API: list API выше выводит список всех серверов Postgres в вашей организации. Вывод должен выглядеть примерно так:
CRUD
Рассмотрим жизненный цикл сервиса Postgres.
Создание
Сначала создайте новый экземпляр с помощью create API. Для этого в JSON-теле запроса должны быть указаны следующие свойства:
name: Имя нового сервиса Postgresprovider: Имя облачного провайдераregion: Регион в инфраструктуре провайдера, где будет развернут сервисsize: Размер VM
В документации по create API приведены возможные значения этих свойств. Кроме того, укажем Postgres 18 вместо версии по умолчанию — 17:
Теперь используйте эти данные, чтобы создать новый экземпляр; обратите внимание, что для этого требуется заголовок Content-Type:
В случае успеха будет создан новый экземпляр и возвращена информация о нём, включая данные для подключения:
Получение
Используйте id из ответа, чтобы повторно получить сервис:
Вывод будет похож на JSON, возвращаемый при создании, но следите
за state; когда его значение изменится на running, сервер будет готов к работе:
Теперь вы можете использовать свойство connectionString для подключения, например, через
psql:
Введите \q, чтобы выйти из psql.
Обновление
patch API поддерживает обновление части свойств сервиса Managed Postgres с помощью JSON Merge Patch по RFC 7396. Теги могут быть особенно полезны при сложных развертываниях; просто отправьте в запросе только их:
Возвращённые данные должны содержать новые теги:
OpenAPI предоставляет дополнительные конечные точки для обновления свойств, не поддерживаемых в patch API. Например, чтобы обновить [конфигурацию Postgres], используйте config API:
В выводе будет показана обновлённая конфигурация, а также сообщение, описывающее последствия этого изменения:
Удаление
Используйте [API удаления], чтобы удалить сервис Postgres.
Удаление сервиса Postgres полностью удаляет сам сервис и все его данные. Перед удалением сервиса убедитесь, что у вас есть резервная копия или что вы предварительно повысили реплику до основной.
В случае успеха в ответе будет указан код состояния 200, например:
Мониторинг
Две совместимые с Prometheus конечные точки предоставляют метрики CPU, памяти, I/O, подключений и транзакций для сервисов Managed Postgres: одна возвращает метрики для всех сервисов в организации, другая — для одного сервиса. Сведения о настройке см. на странице конечная точка Prometheus, а полный список метрик — в metrics reference.
Query insights
Телеметрия на уровне отдельных операторов, лежащая в основе вкладки Query Insights в облачной консоли, также доступна программно. Две конечные точки предоставляют доступ к самым медленным шаблонам запросов в сервисе: одна перечисляет все шаблоны, ранжированные по влиянию, другая возвращает один шаблон вместе с его недавними выполнениями.
Получить список шаблонов медленного запроса
[API шаблонов медленного запроса] возвращает агрегированные метрики для самых медленных
шаблонов медленного запроса, обнаруженных в заданном временном окне. Указать окно
обязательно — передайте from_date и to_date как временные метки RFC 3339:
По умолчанию результаты выводятся с наиболее ресурсоёмкими шаблонами первыми, отсортированными по total_duration
по убыванию. Чтобы сортировать по другому показателю, используйте sort_by (например,
p99_duration, call_count или total_wal_bytes), а направление меняйте
с помощью sort_order. Сузьте выборку фильтрами db_name, db_user,
db_operation и app, а для постраничного просмотра используйте limit и
offset.
Каждый результат представляет собой один нормализованный шаблон, из которого удалены литералы, а длительности указаны в микросекундах:
The queryId — это знаковый 64-битный хеш нормализованного оператора, поэтому он
часто бывает отрицательным. Передайте его обратно без изменений — включая
начальный - — чтобы получить конкретный шаблон.
Получить шаблон медленного запроса
Передайте queryId из ответа списка в slow pattern API, чтобы получить
агрегированные метрики этого шаблона вместе с его последними отдельными запусками.
Поля db_name, db_user и db_operation, которые идентифицируют шаблон,
обязательны:
Ответ содержит ту же агрегированную информацию, что и конечная точка списка, в
aggregate, а также массив recentExecutions. Каждое выполнение включает
полные счётчики для каждого выполнения — I/O общих и временных
блоков, пользовательское и системное время CPU, параллельные воркеры,
JIT и WAL — те же счётчики, которые
[выдвижная панель сведений] показывает в консоли:
В примере оба объекта сокращены для краткости; API возвращает полный набор счётчиков, описанный в разделе per-execution counters.