Перейти к основному содержанию
Используйте ClickHouse OpenAPI для программного управления сервисами Managed Postgres так же, как и сервисами ClickHouse. Этот же API также предоставляет [конечную точку Prometheus] для сбора метрик сервиса. Уже знакомы с OpenAPI? Получите свои [ключи API] и сразу переходите к справочнику API Managed Postgres. Если нет, ниже — краткий обзор.

​
Ключи API

Для использования ClickHouse OpenAPI требуется аутентификация; о том, как создать [ключи API], см. в соответствующем разделе. Затем используйте их, передав учетные данные Basic Auth следующим образом:

​
Идентификатор организации

Далее вам понадобится идентификатор вашей организации.
  1. Выберите название своей организации в левом нижнем углу консоли.
  2. Выберите Сведения об организации.
  3. Нажмите значок копирования справа от идентификатора организации, чтобы сразу скопировать его в буфер обмена.
Теперь его можно использовать в запросах, например:
Теперь вы выполнили свой первый запрос к Postgres API: list API выше возвращает список всех серверов Postgres в вашей организации. Вывод должен выглядеть примерно так:

​
CRUD

Рассмотрим жизненный цикл сервиса Postgres.

​
Создание

Сначала создайте новый сервис с помощью create API. Для этого в JSON body запроса должны быть указаны следующие свойства:
  • name: имя нового сервиса Postgres
  • provider: имя облачного провайдера
  • region: регион в сети провайдера, в котором будет развернут сервис
  • size: размер VM
См. документацию create API, чтобы узнать возможные значения этих свойств. Кроме того, укажем Postgres 18 вместо версии по умолчанию — 17:
Теперь используйте эти данные, чтобы создать новый экземпляр; обратите внимание, что для этого требуется заголовок Content- Type:
При успешном выполнении будет создан новый экземпляр и возвращена информация о нём, включая данные подключения:

​
Чтение

Используйте id из ответа, чтобы снова запросить сервис:
Результат будет похож на JSON, возвращаемый при создании, но следите за state: когда его значение изменится на running, сервер будет готов к работе:
Теперь для подключения можно использовать свойство connectionString, например через psql:
Введите \q для выхода из psql.

​
Обновление

Patch API поддерживает обновление части свойств управляемого сервиса Postgres с помощью JSON Merge Patch согласно RFC 7396. Для сложных развертываний особенно полезны могут быть теги; просто отправьте в запросе только их:
В возвращённых данных должны быть новые теги:
OpenAPI предоставляет дополнительные конечные точки для обновления свойств, которые не поддерживаются в patch API. Например, чтобы обновить Postgres configuration, используйте config API:
В выводе будет показана обновлённая конфигурация, а также сообщение о последствиях изменения:

​
Удаление

Используйте [API удаления], чтобы удалить сервис Postgres.
При удалении сервиса Postgres сервис и все его данные удаляются безвозвратно. Перед удалением сервиса убедитесь, что у вас есть резервная копия или что вы повысили реплику до основной.
При успешном выполнении в ответе будет указан код состояния 200, например:

​
Мониторинг

Две совместимые с Prometheus конечные точки предоставляют метрики ЦП, памяти, I/O, подключений и транзакций для сервисов Managed Postgres: одна возвращает метрики для всех сервисов в организации, другая — для одного сервиса. См. страницу [конечная точка Prometheus] с инструкциями по настройке и [справочник по метрикам] для полного списка метрик.

​
Query insights

Телеметрия по отдельным операторам SQL, лежащая в основе вкладки Query Insights в облачной консоли, также доступна программно. Две конечные точки позволяют получить доступ к самым медленным шаблонам запросов в сервисе: одна возвращает список всех шаблонов, ранжированных по влиянию, другая — один шаблон вместе с его недавними выполнениями.

​
Получить список шаблонов медленных запросов

[API slow patterns] возвращает агрегированные метрики по самым медленным шаблонам запросов, наблюдавшимся в заданном временном интервале. Интервал обязателен — передайте 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. Каждый результат представляет собой один нормализованный шаблон, из которого удалены литералы, а длительности указаны в микросекундах:
queryId — это знаковый 64-битный хеш нормализованного оператора, поэтому он часто бывает отрицательным. Передайте его обратно дословно — включая начальный - и всё остальное, — чтобы получить один шаблон запроса.

​
Получить шаблон медленного запроса

Передайте queryId из ответа со списком в [API шаблонов медленных запросов], чтобы получить агрегированные метрики этого шаблона, а также сведения о его последних отдельных выполнениях. Параметры db_name, db_user и db_operation, которые идентифицируют шаблон, обязательны:
Ответ содержит те же агрегированные данные, что и конечная точка списка, в aggregate, а также массив recentExecutions. Каждое выполнение включает полный набор счётчиков по каждому выполнению — ввод-вывод общих и временных блоков, время CPU в пользовательском и системном режимах, параллельные воркеры, JIT и WAL — те же счётчики, которые [выдвижная панель сведений] показывает в консоли:
В примере оба объекта сокращены для краткости; API возвращает полный набор счётчиков, описанный в разделе счётчики по каждому выполнению.
Последнее изменение 2 июля 2026 г.