Pular para o conteúdo principal
Use a OpenAPI do ClickHouse para controlar programaticamente seus serviços de 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 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:
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, mas fique de olho em state; quando ele mudar para running, o servidor estará pronto:
Agora você pode usar a propriedade connectionString 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 Managed Postgres 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 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.
Última modificação em 2 de julho de 2026