Skip to main content
Use a OpenAPI do ClickHouse para controlar programaticamente seus serviços do ClickHouse Managed Postgres da mesma forma que os serviços do ClickHouse. A mesma API também expõe um endpoint do Prometheus para coleta de métricas do serviço. Já conhece a OpenAPI? Obtenha suas chaves de API e vá direto para a referência da API do ClickHouse Managed Postgres. Caso contrário, acompanhe este guia rápido.

Chaves de API

O uso da OpenAPI do ClickHouse requer autenticação; consulte chaves de API para saber como criá-las. Depois, use-as como credenciais de autenticação básica, assim:

Organization ID

Em seguida, você precisará do Organization ID da sua organização.
  1. Selecione o nome da sua organização no canto inferior esquerdo do Console.
  2. Selecione Organization details.
  3. Clique no ícone de cópia à direita de Organization ID para copiá-lo diretamente para a área de transferência.
Agora você já pode usá-lo nas suas requisições, assim:
Agora você fez sua primeira requisição à API do Postgres: a list API acima lista todos os servidores Postgres da sua organização. A saída deve ser algo como:

CRUD

Vamos analisar o ciclo de vida de um serviço Postgres.

Criar

Primeiro, crie um novo serviço usando a create API. Ela exige as seguintes propriedades no corpo JSON da solicitação:
  • name: Nome do novo serviço Postgres
  • provider: Nome do provedor de Cloud
  • region: Região na rede do provedor onde o serviço será implantado
  • size: Tamanho da VM
Consulte a documentação da create API para ver os valores possíveis dessas propriedades. Além disso, vamos especificar o Postgres 18 em vez da versão padrão, 17:
Agora use esses dados para criar uma nova instância; observe que isso requer o cabeçalho Content-Type. Salve a resposta: ela é a única que inclui as credenciais do serviço (a resposta de [password reset] também as retorna quando a solicitação não fornece uma senha):
Em caso de sucesso, uma nova instância será criada e as informações sobre ela serão retornadas, incluindo os dados de conexão:

Ler

Use o id da resposta para obter o serviço novamente:
A saída será semelhante ao JSON retornado na criação, sem as credenciais, mas fique de olho em state; quando ele mudar para running, o servidor estará pronto:
Agora você pode usar a propriedade connectionString salva da resposta de criação para se conectar, por exemplo, usando psql:
Digite \q para sair do psql.

Atualização

A API de patch oferece suporte à atualização de um subconjunto das propriedades de um serviço Postgres usando RFC 7396 JSON Merge Patch. As tags podem ser especialmente úteis em implantações complexas; basta enviá-las sozinhas na solicitação:
Os dados retornados devem incluir as novas tags:
A OpenAPI fornece endpoints adicionais para atualizar propriedades não suportadas pela API de patch. Por exemplo, para atualizar a configuração do Postgres, use a config API:
A saída mostrará a configuração atualizada, bem como uma mensagem que descreve as consequências da alteração:

Excluir

Use a API de exclusão para excluir um serviço Postgres.
Excluir um serviço Postgres remove completamente o serviço e todos os seus dados. Certifique-se de ter um backup ou de ter promovido uma réplica para primária antes de excluir um serviço.
Em caso de sucesso, a resposta retornará o código de status 200, por exemplo:

Monitoramento

Dois endpoints compatíveis com o Prometheus expõem métricas de CPU, memória, E/S, conexão e transação para serviços do ClickHouse Managed Postgres: um fornece métricas de todos os serviços da organização; o outro, de um único serviço. Consulte a página endpoint do Prometheus para a configuração e a referência de métricas para ver a lista completa de métricas.

Query insights

A telemetria por instrução que alimenta a aba Query Insights no console da Cloud também está disponível programaticamente. Dois endpoints expõem os padrões de consulta mais lentos em um serviço: um lista todos os padrões ordenados por impacto; o outro retorna um único padrão com suas execuções recentes.

Listar padrões de consultas lentas

A slow patterns API retorna métricas agregadas dos padrões de consulta mais lentos observados em uma janela de tempo. A janela é obrigatória — passe from_date e to_date como timestamps no formato RFC 3339:
Por padrão, os resultados mostram primeiro os padrões de maior custo, classificados por total_duration em ordem decrescente. Ordene por um contador diferente com sort_by (por exemplo, p99_duration, call_count ou total_wal_bytes) e inverta a direção com sort_order. Restrinja o conjunto com os filtros db_name, db_user, db_operation e app, e percorra as páginas com limit e offset. Cada resultado é um padrão normalizado, com os literais removidos e as durações informadas em microssegundos:
O queryId é um hash com sinal de 64 bits da instrução normalizada, então geralmente é negativo. Envie-o de volta exatamente como está — com o - inicial e tudo — para obter um único padrão.

Obter um padrão de consulta lenta

Passe um queryId retornado pela resposta da lista para a API de padrão de consulta lenta para obter as métricas agregadas desse padrão, junto com suas execuções individuais mais recentes. db_name, db_user e db_operation, que identificam o padrão, são obrigatórios:
A resposta retorna a mesma agregação do endpoint de listagem em aggregate, além de um array recentExecutions. Cada execução inclui os contadores completos por execução — E/S de blocos compartilhados e temporários, tempo de CPU em modo usuário e do sistema, workers paralelos, JIT e WAL — os mesmos contadores que o painel lateral de detalhes detalha no Console:
O exemplo resume ambos os objetos por brevidade; a API retorna o conjunto completo de contadores documentado em contadores por execução.

Logs do servidor

Os logs do servidor PostgreSQL exibidos no visualizador de logs do console do Cloud também estão disponíveis programaticamente. A API de logs retorna entradas de log individuais de um serviço em uma janela de tempo. Assim como no Query Insights, a janela é obrigatória; portanto, passe from_date e to_date como timestamps RFC 3339. O intervalo não pode exceder 30 dias, e to_date deve ser posterior a from_date:
As entradas são retornadas da mais recente para a mais antiga; inverta a ordem com sort_order (asc ou desc). Filtre por uma única severidade com severity (por exemplo, ERROR, WARNING ou LOG), encontre uma substring do corpo do log que diferencia maiúsculas de minúsculas com body_contains e pagine os resultados com limit e offset. Cada entrada contém timestamp, severity e body bruto. O corpo é sempre uma string: linhas de log estruturadas são retornadas codificadas em JSON, e linhas simples são retornadas literalmente:
O endpoint é paginado com limit e offset, em vez de retornar uma contagem total; avance o offset até que uma página retorne menos entradas que o limit.
Última modificação em 14 de agosto de 2026