Claves de API
Para usar la OpenAPI de ClickHouse se requiere autenticación; consulta [API keys] para ver cómo crearlas. Luego úsalas como credenciales de autenticación Basic, así:Organization ID
A continuación, necesitarás tu Organization ID.- Selecciona el nombre de tu organización en la esquina inferior izquierda de la Console.
- Selecciona Detalles de la organización.
- Haz clic en el icono de copiar situado a la derecha de Organization ID para copiarlo directamente al portapapeles.
CRUD
Veamos el ciclo de vida de un servicio de Postgres.Crear
Primero, cree uno nuevo usando la API de creación. Requiere las siguientes propiedades en el cuerpo JSON de la solicitud:name: Nombre del nuevo servicio de Postgresprovider: Nombre del proveedor de la nube:aws(ogcpen Private Preview)region: Región dentro de la red del proveedor en la que se desplegará el serviciosize: Tamaño de la VM
Leer
Usa elid de la respuesta para volver a obtener el servicio:
state; cuando cambie a running, el servidor estará listo:
connectionString guardada de la respuesta de creación
para conectarse, por ejemplo, con psql:
\q para salir de psql.
Actualización
La [API de parches] permite actualizar un subconjunto de las propiedades de un servicio de Managed Postgres mediante JSON Merge Patch de RFC 7396. Las etiquetas pueden ser de especial interés en despliegues complejos; simplemente envíelas solas en la solicitud:Eliminar
Usa la [API de eliminación] para eliminar un servicio de Postgres.Monitorización
Dos endpoints compatibles con Prometheus exponen métricas de CPU, memoria, E/S, conexión y transacción para los servicios de ClickHouse Managed Postgres: uno devuelve métricas de todos los servicios de la organización y el otro de un solo servicio. Consulta la página de endpoint de Prometheus para la configuración y la [referencia de métricas] para ver la lista completa de métricas.Query insights
La telemetría por sentencia en la que se basa la pestaña Query Insights de la consola de la nube también está disponible programáticamente. Dos endpoints exponen los patrones de consulta más lentos de un servicio: uno enumera cada patrón ordenado por impacto; el otro devuelve un único patrón con sus ejecuciones recientes.Listar patrones de consultas lentas
La API de patrones lentos devuelve métricas agregadas de los patrones de consulta más lentos observados dentro de una ventana de tiempo. La ventana es obligatoria: indicafrom_date y to_date como marcas de tiempo RFC 3339:
total_duration
de forma descendente. Ordene por un contador diferente con sort_by (por ejemplo,
p99_duration, call_count o total_wal_bytes) y cambie la dirección
con sort_order. Restrinja el conjunto con los filtros db_name, db_user,
db_operation y app, y pagínelo con limit y
offset.
Cada resultado es un patrón normalizado, con los literales eliminados y
las duraciones expresadas en microsegundos:
queryId es un hash con signo de 64 bits de la sentencia normalizada, por lo que
a menudo es negativo. Devuélvalo tal cual — con el - inicial y todo — para obtener
un único patrón.
Obtener un patrón de consulta lenta
Pase unqueryId de la respuesta de la lista a la API de patrones lentos para obtener las
métricas agregadas de ese patrón junto con sus ejecuciones individuales más recientes.
Se requieren db_name, db_user y db_operation, que identifican el patrón:
aggregate, además de un array recentExecutions. Cada ejecución incluye los
contadores completos por ejecución — E/S de bloques compartidos y temporales,
tiempo de CPU en modo usuario y de sistema, workers paralelos, JIT y WAL —, los mismos contadores que el
panel lateral de detalles desglosa en la consola:
Logs del servidor
Los logs del servidor PostgreSQL disponibles en el visor de logs de la consola de la nube también están disponibles mediante programación. La API de logs devuelve entradas de log individuales de un servicio durante una ventana de tiempo. Al igual que con Query Insights, la ventana es obligatoria, por lo que pasefrom_date y to_date como marcas de tiempo RFC 3339. El intervalo no debe superar
los 30 días y to_date debe ser posterior a from_date:
sort_order (asc o
desc). Filtre por un único nivel de gravedad con severity (por ejemplo, ERROR,
WARNING o LOG), busque una subcadena del cuerpo del log que distinga entre mayúsculas y minúsculas con
body_contains y pagine los resultados con limit y offset.
Cada entrada contiene su timestamp, severity y body sin procesar. El cuerpo es
siempre una cadena: las líneas de log estructuradas se devuelven codificadas en JSON y las líneas sin formato,
literalmente:
limit y offset en lugar de devolver un recuento
total; avance offset hasta que una página devuelva menos entradas que limit.