Используйте ClickHouse OpenAPI для программного
управления сервисами ClickHouse Managed Postgres так же, как и сервисами ClickHouse. Этот
же API также предоставляет [конечную точку Prometheus] для сбора метрик сервиса.
Уже знакомы с OpenAPI? Получите свои [ключи API] и сразу переходите к
справочнику API ClickHouse Managed Postgres. Если нет, ниже — краткий обзор.
Для использования ClickHouse OpenAPI требуется аутентификация; о том, как
создать [ключи API], см. в соответствующем разделе. Затем используйте
их, передав учетные данные Basic Auth следующим образом:
Идентификатор организации
Далее вам понадобится идентификатор вашей организации.
- Выберите название своей организации в левом нижнем углу консоли.
- Выберите Сведения об организации.
- Нажмите значок копирования справа от идентификатора организации, чтобы сразу скопировать его
в буфер обмена.
Теперь его можно использовать в запросах, например:
Теперь вы выполнили свой первый запрос к Postgres API: list API выше возвращает список всех
серверов Postgres в вашей организации. Вывод должен выглядеть
примерно так:
Рассмотрим жизненный цикл сервиса 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 с инструкциями по настройке и
[справочник по метрикам] для полного списка метрик.
Телеметрия по отдельным операторам 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 г.