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.
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:
Em seguida, você precisará do Organization ID da sua organização.
- Selecione o nome da sua organização no canto inferior esquerdo do Console.
- Selecione Organization details.
- 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:
Vamos analisar o ciclo de vida de um serviço Postgres.
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:
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.
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:
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:
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.
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.