Skip to main content
Используйте ClickHouse OpenAPI для программного управления сервисами ClickHouse Managed Postgres так же, как и сервисами ClickHouse. Этот же API также предоставляет [конечную точку Prometheus] для сбора метрик сервиса. Уже знакомы с OpenAPI? Получите свои [ключи API] и сразу переходите к справочнику API ClickHouse 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. Сохраните ответ: только он содержит учётные данные сервиса (ответ password reset также возвращает их, если в запросе не указан пароль):
При успешном выполнении будет создан новый экземпляр и возвращена информация о нём, включая данные подключения:

Чтение

Используйте 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, подключений и транзакций для сервисов ClickHouse 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 возвращает полный набор счётчиков, описанный в разделе счётчики по каждому выполнению.

Серверные журналы

Серверные журналы PostgreSQL, доступные в средстве просмотра журналов в облачной консоли, также доступны программно. API журналов возвращает отдельные записи журнала для сервиса за временной интервал. Как и в Query Insights, указание интервала обязательно, поэтому передайте from_date и to_date в виде временных меток RFC 3339. Интервал не должен превышать 30 дней, а to_date должен быть позже from_date:
Записи возвращаются от новых к старым; измените порядок с помощью sort_order (asc или desc). Чтобы отфильтровать записи по одному уровню серьёзности, используйте severity (например, ERROR, WARNING или LOG); для поиска подстроки в теле журнала с учётом регистра — body_contains; для постраничного просмотра результатов — limit и offset. Каждая запись содержит timestamp, severity и необработанное body. Тело всегда представляет собой строку: структурированные строки журнала возвращаются в кодировке JSON, обычные строки — без изменений:
Конечная точка возвращает результаты постранично с помощью limit и offset, а не общее количество; увеличивайте offset, пока страница не вернёт меньше limit записей.
Последнее изменение 14 августа 2026 г.