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.
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. 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:
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.
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:
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 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.
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.
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.