Referencia de la CLI

El conector se distribuye como un único binario llamado clicklink; los comandos que se ejecutan se encuentran en clicklink clctl. Esta página abarca los comandos utilizados durante la instalación y el funcionamiento diario. Ejecute cualquier comando con --help para consultar el texto de ayuda completo. Los indicadores de los subárboles troubleshoot y preflight también se pueden proporcionar mediante las variables de entorno CLCTL_* (cuyo nombre se indica en la salida de ayuda de cada indicador) o ~/.clicklink/clctl.yaml.

Inicializa el conector a partir de un token de inscripción, un paquete de inscripción guardado o un certificado firmado fuera de banda. Una sola invocación prepara la configuración, aprovisiona el acceso a ClickHouse, obtiene el certificado mTLS del client, despliega (un gráfico de Helm o unidades systemd) y verifica el estado. Es seguro volver a ejecutarlo: se conservan la configuración y el UUID del clúster, las credenciales se sobrescriben de forma atómica y se reutiliza una clave de client existente, a menos que se indique --force. Consulta onboarding para ver el flujo completo.

Se requiere exactamente uno de los tres puntos de entrada; son mutuamente excluyentes.

Válidos solo con --target helm.

Válidos únicamente con --target systemd.

• --handoff, --enroll y --signed-cert son mutuamente excluyentes; se debe especificar exactamente uno.
• Los indicadores exclusivos de Kubernetes se rechazan salvo que se use --target helm; --server y --ca-data se rechazan con --target helm (el flujo de Helm lee el kubeconfig de la estación de trabajo).
• --no-auto-sign y --sign-endpoint son mutuamente excluyentes, y ambos (junto con --api-private-ca) se rechazan con --signed-cert.
• --operators y --no-gateway son mutuamente excluyentes.
• --skip-provision rechaza --ch-pod, --ch-user-suffix, --server, --ca-data y --ch-admin-password-stdin (no se aprovisiona nada).

Ejecuta el conjunto de comprobaciones del conector, agrupadas por categoría: configuración, archivos, red, clickhouse, systemd, acceso, disco y redacción. Cada comprobación indica si se superó, generó una advertencia, falló o se omitió. El código de salida 0 indica que todas las comprobaciones se superaron (las advertencias no bloquean); el código de salida 2 indica que una o más comprobaciones fallaron.

De forma predeterminada, el comando se ejecuta localmente. Con --k8s-namespace, ejecuta el propio binario del pod de Kubernetes del conector mediante kubectl exec y muestra el informe localmente (las comprobaciones de systemd siempre se omiten en los pods de Kubernetes). Con los indicadores de canal remoto, ejecuta en su lugar el binario instalado en una VM remota.

Los indicadores --k8s-* y los indicadores de canal remoto son mutuamente excluyentes; elija un único destino.

Habilita, deshabilita e inspecciona la sesión de soporte: la ventana de tiempo durante la cual el solucionador de problemas acepta comandos. Cuando no hay ninguna sesión activa, el demonio rechaza todos los comandos, aunque su WebSocket esté conectado. Consulte las sesiones de soporte.

Los comandos funcionan en uno de dos modos:

• Archivo local (predeterminado): lee y escribe el archivo de estado de la sesión en el host donde se ejecuta el solucionador de problemas (de forma predeterminada, /var/lib/clicklink/session.json).
• Gateway: con --gateway-url, obtiene un token de ID de OIDC y, desde su estación de trabajo, llama en su lugar al gateway de sesiones del solucionador de problemas.

La habilitación falla si ya hay una sesión activa; deshabilítela primero o espere a que expire.

Desactiva la sesión de inmediato. No tiene ningún efecto si no hay una sesión activa.

Muestra si la sesión está activa, quién la habilitó y cuándo expira. --output (-o) permite seleccionar table (predeterminado) o json.

En Kubernetes, acceda al gateway mediante un reenvío de puertos:

kubectl -n <connector-namespace> port-forward \
  statefulset/clicklink-connector-troubleshooter 8443:8443
clicklink clctl troubleshoot session enable \
  --gateway-url http://localhost:8443 \
  --duration 1h --reason "support ticket 1234"

En una VM, el gateway de sesión utiliza un certificado TLS autofirmado. Este comando registra la huella SHA-256 del certificado en ~/.clicklink/clctl.yaml para que los comandos de session puedan verificarlo; si una huella fijada deja de coincidir, la operación falla de forma segura. La confianza se establece fuera de banda de una de estas dos formas:

• Con los indicadores del canal remoto, el certificado se lee directamente desde la VM a través del canal ya autenticado y se fija.
• Sin un canal, pase --gateway-fingerprint con el valor SHA-256 que el conector registró al generar el certificado; el certificado obtenido solo se fija si coincide. Si omite el indicador, se muestra la huella presentada sin fijar nada.

clicklink clctl troubleshoot gateway trust \
  --gateway-url https://<vm-host>:8443 \
  --gateway-fingerprint <sha256-from-connector-log>

En Kubernetes, no se usa el pinning: exponga el gateway mediante un Ingreso con un certificado emitido por una CA o utilice un reenvío de puertos.

Imprime las últimas entradas del registro de auditoría del solucionador de problemas: JSON delimitado por saltos de línea, una entrada por cada comando que el daemon aceptó o bloqueó. El comando abre el registro en modo de solo lectura y nunca lo modifica.

La imagen de runtime del conector no incluye una shell, por lo que, en Kubernetes, este comando es el lector compatible:

kubectl -n <connector-namespace> exec <troubleshooter-pod> -- \
  /clicklink clctl troubleshoot audit tail

clicklink clctl scraper access provision y clicklink clctl troubleshoot access provision crean y, con --force, rotan el paquete de acceso por instancia de un componente: el usuario de ClickHouse de solo lectura y sus permisos, además de la ServiceAccount, RBAC y el token de Kubernetes que utiliza el componente. init realiza esta operación integrada durante la instalación; los comandos independientes permiten volver a ejecutarla y rotar las credenciales.

Rote las credenciales de una instancia para un componente:

clicklink clctl scraper access provision --target helm \
  --target-namespace <connector-namespace> \
  --instance <instance-name> --instance-namespace <clickhouse-namespace> \
  --server <kubernetes-api-server-url> \
  --apply-ch-grants --ch-pod <clickhouse-pod-or-label-selector> --ch-pod-namespace <clickhouse-namespace> \
  --force

preflight, gateway trust y access provision aceptan un conjunto común de indicadores que determinan cómo se accede a una VM de destino: