Skip to main content

​
Preguntas frecuentes

​
¿Quién puede cambiar mis servicios y cuándo?

En modo gestionado, ClickHouse Cloud solo modifica los servicios que le pediste gestionar. Cualquier persona con acceso al host o al pod de Kubernetes del executor también puede controlarlos con los comandos locales clicklink clctl instances; consulta el ciclo de vida del servicio. ClickHouse Cloud envía los comandos de ciclo de vida por el canal saliente del executor:
  • creación, a partir de la definición que enviaste
  • escalado, a un número fijo de réplicas que fija ClickHouse Cloud (limitado por un ajuste de ClickHouse Cloud, 20 en la configuración predeterminada)
  • detención, inicio y reinicio
  • copia de seguridad y eliminación de copias de seguridad
  • eliminación
Las actualizaciones de versión y los cambios de configuración llegan por la misma vía, como una definición de servicio reaplicada; en esos casos no hay ningún paso de aprobación por parte del cliente. No interviene ninguna sesión de soporte: el canal del executor es independiente del canal del solucionador de problemas y no está condicionado por el estado de la sesión. Dos cosas dependen de ti. Crear un servicio requiere tus comandos clicklink clctl executor prepare y clicklink clctl instances create, porque solo tú puedes crear los buckets y el rol de IAM. Las actualizaciones de los componentes de la plataforma en tu cluster también dependen de ti. El executor deja preparado cada paquete propuesto; tu comando clicklink clctl platform approve lo aprueba y emite un token de 2 horas. Consulta actualizaciones de la plataforma. Todo lo que hace el executor ocurre a través de la Kubernetes API. Una política de admission restringe sus escrituras a los espacios de nombres con el prefijo del servicio (ns- de forma predeterminada). También admite tres escrituras en el propio espacio de nombres del executor: la renovación de su token, el ConfigMap del registry de servicios y, en Kubernetes, el certificado de client renovado en el secreto clicklink-mtls. Sus lecturas de esas mismas familias de recursos abarcan todo el cluster. Las actualizaciones de plataforma aprobadas se ejecutan con una identidad pcm-platform independiente, limitada a los espacios de nombres de la plataforma. Los clusters que operas tú mismo nunca se modifican: el scraper y el solucionador de problemas son de solo lectura. Los ámbitos exactos figuran en la página del modelo de privilegios.

​
¿Qué datos salen de mi entorno?

Hay tres vías por las que salen datos, todas mediante conexiones salientes que el propio connector abre: la ruta de scrape, el executor y las sesiones de soporte que habilites. El scraper envía resultados de un conjunto fijo de system tables: de forma predeterminada, metric_log, asynchronous_metric_log, tables, warnings y server_settings. También envía latidos de salud y estado, el estado del servicio y de las copias de seguridad, y las métricas propias del connector. El conjunto de scrape predeterminado excluye system.query_log. El texto SQL en bruto, con cualquier literal o dato personal que contenga, nunca sale por la ruta de scrape a menos que añadas esa tabla. Durante una sesión, la lista de permitidos de tablas predeterminada incluye system.processes, que muestra el texto de las consultas en curso; elimínala de la lista de permitidos si eso debe permanecer oculto. El executor envía el resultado de cada comando que ejecuta, junto con el state y el número de réplicas de cada servicio administrado. Su latido indica si el canal de comandos está conectado. También transporta las versiones de los componentes de la plataforma, el resumen del último paquete aplicado y el resultado de la última actualización de la plataforma. En una instalación sobre VM, el latido también indica si su paquete de acceso a Kubernetes está ok, expiring, expired o ausente. Cuando creas un servicio, clicklink clctl instances create envía el ID de tu entorno, la nube y la región, el nombre del servicio, los nombres de sus buckets y el ARN del rol de IAM. Envía dos hashes de la contraseña del usuario default; la contraseña en sí nunca sale. Durante una sesión de soporte activa, el solucionador de problemas también devuelve la salida de los comandos. Esa salida se limita a tablas de ClickHouse incluidas en la lista de permitidos y a vistas de Kubernetes de solo lectura, incluidos los logs de pods de Kubernetes. Antes de enviarse, pasa por un proceso de redacción (patrones integrados para IP, credenciales, tokens y claves, además de los tuyos propios). Los datos de tus tablas, las copias de seguridad y el historial de consultas (system.query_log, system.text_log) permanecen en tu entorno. Tres cosas sí salen:
  • las filas de las tablas de historial de métricas incluidas en la lista de permitidos (system.metric_log, system.asynchronous_metric_log) se envían con cada scrape
  • el texto de las consultas en curso es visible en una sesión a través de system.processes, salvo que lo elimines de la lista de permitidos
  • los logs de pods de Kubernetes leídos durante una sesión de soporte de Kubernetes salen tras la redacción
La lista completa de conexiones salientes está en la página del modelo de privilegios.

​
¿Cómo evito que ClickHouse modifique mis clusters?

Ejecútelo sin el modo gestionado. Durante la instalación, pase --no-managed a clicklink clctl init, o responda que no cuando se le pregunte. Solo se despliegan el scraper y el solucionador de problemas, de modo que ClickHouse no puede crear, modificar ni eliminar servicios. El connector sigue aprovisionando usuarios de ClickHouse de solo lectura y ServiceAccounts; consulte el modelo de privilegios. En una instalación existente, detenga el executor y revoque su grant como administrador del cluster. Para detenerlo, establezca executor.enabled: false en sus valores de Helm y ejecute helm upgrade, o bien ejecute systemctl disable --now clicklink-executor en una VM. A continuación, revoque el grant. El último comando elimina la propia ServiceAccount; su espacio de nombres es clicklink-system en una instalación en VM y el espacio de nombres del connector en una instalación en Kubernetes:
Los servicios que ClickHouse creó siguen en ejecución, pero ClickHouse Cloud ya no puede escalarlos, actualizarlos, respaldarlos ni eliminarlos, y los comandos pendientes para ellos fallan. Las actualizaciones de la plataforma también se detienen: la parte del workload la aplica el executor, y este ya no está en ejecución.

​
¿Qué sucede si el connector está fuera de línea?

Sus servicios de ClickHouse no se ven afectados: el connector no forma parte de ninguna ruta de datos y un servicio gestionado sigue funcionando sin el executor. El impacto es la pérdida de visibilidad y control. ClickHouse Cloud deja de recibir telemetría y las sesiones de soporte dejan de estar disponibles hasta que el connector vuelva. En el modo gestionado, ClickHouse Cloud muestra su entorno como fuera de línea cuando no ha recibido ningún latido durante 5 minutos, y vuelve a mostrarlo como listo en cuanto llega el siguiente. Los comandos del ciclo de vida se comportan de dos maneras mientras no hay ningún executor conectado. Una creación, eliminación o sincronización de plataforma que ClickHouse Cloud ya haya aceptado se conserva y se reintenta. Una creación se reintenta hasta 30 minutos desde su último informe de progreso, una eliminación hasta 2 horas y una sincronización de plataforma hasta 10 intentos. Transcurrido ese plazo, el comando se notifica como fallido. Los dos horizontes corresponden a las claves de configuración executor.create_retry_horizon y executor.delete_retry_horizon. Cualquier otro comando (escalado, detención, inicio, reinicio, copia de seguridad, eliminación de copia de seguridad), así como cualquier creación o eliminación enviada mientras no hay ningún executor conectado, se rechaza en el momento del envío y no se pone en cola. Un resultado que el executor no pudo notificar se envía en su siguiente conexión. Consulte cuando el connector está fuera de línea. En una VM, el scraper almacena en búfer los datos recopilados en /var/lib/clicklink/buffer siempre que el endpoint del connector no sea accesible (hasta 168 horas o 1024 MB de forma predeterminada). Al reconectarse entrega ese búfer, de modo que una interrupción del endpoint no supone pérdida de telemetría. Si un demonio se bloquea, systemd lo reinicia en una VM y el agente kubelet lo hace en Kubernetes. El executor mantiene el estado de sus comandos en disco, por lo que tras un reinicio se reanudan los comandos que estaban en curso. Para diagnosticar, compruebe el endpoint /livez de cada componente (la señal es el campo JSON status, no el código HTTP) y ejecute clicklink clctl preflight (con sudo en el host de la VM). Preflight comprueba en una sola pasada la configuración, la conectividad, la accesibilidad de ClickHouse, el acceso y el disco. Consulte operaciones; si el connector sigue sin estar en buen estado, póngase en contacto con el soporte de ClickHouse.

​
¿Qué se elimina cuando se elimina un servicio?

El executor detiene el servicio, elimina sus recursos de Kubernetes y borra su espacio de nombres. Informa de que el servicio ha terminado una vez que el espacio de nombres ya no existe. Todo lo que está fuera de Kubernetes se conserva: el bucket de datos, el bucket de copias de seguridad y el rol de IAM del servicio. El executor no dispone de credenciales para tus buckets ni para IAM, por lo que no puede tocarlos. El resto se elimina con clicklink clctl executor teardown, ejecutado con tus credenciales. De forma predeterminada, elimina el rol de IAM y conserva los datos y las copias de seguridad; para borrarlos hay que usar indicadores explícitos. Consulta eliminar un servicio.

​
¿Dónde está la contraseña de mi usuario default?

clicklink clctl executor prepare la genera localmente y la muestra una única vez. Si realizas el envío con los indicadores individuales en lugar de --from-prepare, clicklink clctl instances create la lee desde --default-user-password-file o bien la genera y la muestra. A ClickHouse Cloud solo se envían sus hash, por lo que ni el connector ni ClickHouse podrán volver a mostrártela. Guárdala en cuanto aparezca en pantalla.

​
¿Cómo revoco el acceso de ClickHouse?

En orden creciente:
  1. Finalice el acceso interactivo. Deshabilite la sesión con sudo clicklink clctl troubleshoot session disable en el host de la VM, o ejecute el mismo comando con --gateway-url a través del reenvío de puertos en Kubernetes (los comandos exactos se encuentran en la página de sesiones de soporte). Sin una sesión activa, el solucionador de problemas rechaza todos los comandos, incluso si está conectado.
  2. Detenga el modo gestionado. Detenga el executor y elimine su grant como se describe en ¿Cómo impido que ClickHouse modifique mis clusters?. Las actualizaciones de la plataforma ya requieren su aprobación, por lo que negarla las detiene.
  3. Impida sesiones futuras. Vacíe la lista de permitidos del operador (una lista vacía cierra el gateway) o deshabilite el gateway; en una VM, la gestión local de sesiones sigue disponible para root en el host. Consulte la guía de configuración.
  4. Interrumpa la conectividad con ClickHouse Cloud. Bloquee la salida hacia el endpoint de su connector en la capa de red o vacíe networkPolicy.allowEgressCIDRs con un CNI que aplique las políticas. El connector es solo saliente, por lo que ClickHouse Cloud no tiene una ruta entrante para restablecerlo. Las lecturas locales en ClickHouse continuarán hasta que detenga o desinstale las cargas de trabajo, lo que constituye la detención definitiva.
  5. Revoque las credenciales. Elimine los usuarios de ClickHouse pcm_scraper y pcm_troubleshooter, y elimine los secretos del connector (Kubernetes) o los archivos en /etc/clicklink (VM).
  6. Elimine el connector por completo. Consulte operaciones.

​
¿Puedo ejecutarlo en un entorno aislado o a través de mis propios mirrors?

Sí. Todos los artifacts necesarios en el momento de la instalación pueden provenir del interior de su boundary:
  • Replique el tarball de la CLI y la imagen de contenedor desde releases.clicklink.clickhouse.com y el registry público, y luego apunte image.repository a su mirror.
  • Pase --chart con una referencia oci://, una URL o un archivo local. --chart-version toma por defecto la propia versión de la CLI.
  • Si su endpoint del connector se sirve dentro de su boundary detrás de una private CA, --api-private-ca (Kubernetes) o api.tls.ca_file (VM) añade la CA chain del paquete de inscripción a las raíces del sistema.
  • Para realizar la inscripción sin conectividad directa, init --handoff consume un paquete obtenido fuera de banda, y --no-auto-sign junto con init --signed-cert completa la firma del certificado fuera de banda.
  • En el modo gestionado, las imágenes de ClickHouse para sus services y componentes de la plataforma pueden provenir de su propio registry una vez que las haya importado allí; ClickHouse registra ese registry para su entorno.
  • Los paquetes de la plataforma pueden entregarse fuera de banda y pasarse a clicklink clctl platform approve --bundle como un archivo.
Consulte private mirrors y la sección sobre entornos aislados de onboarding. El connector sigue necesitando una ruta hacia su endpoint del connector en runtime; sin ella, ClickHouse Cloud no recibe telemetría y ningún comando del ciclo de vida llega al executor.

​
¿Cómo se auditan las sesiones de soporte?

Cada comando ejecutado durante una sesión, tanto si se acepta como si se bloquea, se añade a /var/log/clicklink/troubleshoot-audit.log en formato JSON delimitado por saltos de línea. Cada entrada registra submitted_by (el Organization ID en el canal de comandos), el texto del comando, la instance de destino, el resultado y blocked_by para los comandos rechazados. Las llamadas al gateway, incluidas las denegadas, se registran como líneas clctl.gateway estructuradas en el propio log del solucionador de problemas. Se atribuyen al correo electrónico del operador acreditado por el token, nunca a un nombre declarado por el propio usuario. Los cambios de sesión local en una VM registran el usuario del host que los invoca como enabled_by en /var/lib/clicklink/session.json. Las sesiones tienen una duración limitada (4 horas de forma predeterminada y un máximo de 24 horas). Cada habilitación registra quién la activó, cuándo expira y un motivo opcional, información que muestra clicklink clctl troubleshoot session status. Lea el log de auditoría con clicklink clctl troubleshoot audit tail. En Kubernetes, este comando es el reader compatible (la imagen de runtime no incluye shell). Con el valor predeterminado persistence.enabled: true, el log se almacena en el volume persistente del solucionador de problemas, por lo que el historial se conserva aunque se reprograme el pod de Kubernetes. Al deshabilitar la persistencia, el log de auditoría y el estado de la sesión solo duran lo que el pod de Kubernetes, una opción que el chart indica como adecuada únicamente para el desarrollo local. De forma predeterminada, la rotation conserva 5 archivos de hasta 128 MB durante 168 horas; consulte la referencia de configuración para ajustarla y sesiones de soporte para conocer el modelo de confianza completo.