O ClickHouse Connector está em Private Preview. Para solicitar acesso, entre em contato com a equipe responsável pela sua conta ClickHouse.
O que o conector faz
clicklink, que contém os daemons do conector e as ferramentas de linha de comando clicklink clctl usadas para instalá-los e operá-los.
O conector tem dois componentes:
- O scraper coleta métricas de uma allowlist de tabelas de sistema do ClickHouse, além de metadados da infraestrutura e do status de saúde, e os envia ao ClickHouse Cloud.
- O troubleshooter permite que os engenheiros do suporte do ClickHouse executem diagnósticos somente leitura, mas apenas durante uma sessão de suporte que você habilita e pode encerrar a qualquer momento.
Quando usá-lo
- Todos os caminhos de acesso se originem dentro da sua fronteira, sem conectividade de entrada.
- O acesso do suporte seja limitado no tempo, habilitado por você e revogável a qualquer momento.
- Tudo o que o ClickHouse lê seja somente leitura: acesso permanente às tabelas do ClickHouse, além de metadados de cargas de trabalho e logs no escopo do espaço de nomes durante uma sessão habilitada por você. Todos os comandos da sessão de suporte são registrados em um log de auditoria sob seu controle.
Como funciona
clicklink clctl init --enroll uma única vez, em uma estação de trabalho com acesso ao kubeconfig para uma instalação no Kubernetes ou diretamente no host para uma instalação em uma VM Linux. Essa única execução resgata o token, cria usuários dedicados do ClickHouse com acesso somente leitura para cada componente, obtém um certificado de cliente mTLS, implanta e inicia os daemons e verifica a saúde deles.
A partir daí, o scraper lê periodicamente as tabelas de sistema permitidas e envia métricas, metadados e informações de saúde ao endpoint do seu connector por TLS com autenticação mútua. O troubleshooter permanece inativo: ele mantém um canal de comandos de saída, mas esse canal não transmite nada até que você habilite uma sessão de suporte. O certificado mTLS é renovado automaticamente, sem nenhuma ação da sua parte.
Requisitos em resumo
- Um destino de implantação. Qualquer cluster do Kubernetes compatível (com o chart do Helm instalado) ou qualquer host Linux amd64 ou arm64 com systemd.
- Acesso de rede de saída pela porta 443 ao endpoint do seu conector e ao respectivo endpoint de inscrição, além de
releases.clicklink.clickhouse.come do ECR Public durante a instalação. Esse é o caminho padrão; há alternativas isoladas da internet e espelhadas para cada etapa. Consulte o onboarding. - Um listener nativo do ClickHouse acessível. O conector se comunica com cada cluster pelo protocolo nativo; no Kubernetes, ele detecta automaticamente conexões seguras (9440) ou em texto simples (9000).
- Um token de inscrição. O ClickHouse fornece o endpoint do seu conector e um token de inscrição de uso único durante o onboarding.
- Acesso de administrador ao ClickHouse durante a configuração. O provisionamento inicial cria os usuários somente leitura do conector. Uma senha de administrador, quando definida, é solicitada uma única vez e nunca é armazenada.
- Acesso de administrador a um servidor da API do Kubernetes durante o provisionamento, em ambos os destinos de instalação: os pacotes de acesso são vinculados a ServiceAccounts do Kubernetes. Consulte o onboarding.
Próximos passos
- Onboarding: instale e registre o conector no Kubernetes ou em uma VM Linux.
- arquitetura: componentes, cada conexão, ciclo de vida dos certificados e quais dados saem do seu ambiente.
- sessões de suporte: como habilitar, definir o escopo, auditar e revogar o acesso ao suporte.
- Configuration e operations: ajustes, upgrades e tarefas operacionais contínuas.
- FAQ: perguntas frequentes, incluindo saída de dados e revogação.