Colocando em produção

Colocando o ClickStack em produção

Ao implantar o ClickStack em produção, há várias considerações adicionais para garantir segurança, estabilidade e a configuração correta. Elas variam conforme a distribuição — Open Source ou Managed — utilizada.

ClickStack gerenciado

Para implantações em produção, recomenda-se o Managed ClickStack. Ele aplica, por padrão, práticas de segurança alinhadas aos padrões do setor, incluindo criptografia aprimorada, autenticação e conectividade reforçadas e controles de acesso gerenciados, além de oferecer os seguintes benefícios:

• Escalonamento automático da capacidade de computação independentemente do armazenamento
• Retenção de baixo custo e praticamente ilimitada com base em armazenamento de objetos
• Capacidade de isolar de forma independente as cargas de trabalho de leitura e gravação com Warehouses.
• Autenticação integrada
• Backups automatizados
• Atualizações sem interrupções

Siga estas melhores práticas do ClickHouse Cloud ao usar o Managed ClickStack.

​

Proteja a ingestão

Por padrão, o ClickStack OpenTelemetry Collector não vem protegido quando implantado fora das distribuições open source e não exige autenticação em suas portas OTLP.

Para proteger a ingestão, especifique um token de autenticação ao implantar o collector usando a variável de ambiente OTLP_AUTH_TOKEN. Consulte “Protegendo o collector” para mais detalhes.

​

Crie um usuário de ingestão

Recomenda-se criar um usuário dedicado para o OTel collector fazer a ingestão no Managed ClickHouse e garantir que a ingestão seja enviada para um banco de dados específico, por exemplo otel. Consulte “Criando um usuário de ingestão” para mais detalhes.

​

Configure o Time To Live (TTL)

Garanta que o Time To Live (TTL) esteja configurado adequadamente para sua implantação do Managed ClickStack. Isso controla por quanto tempo os dados são retidos — o padrão de 3 dias geralmente precisa ser ajustado.

​

Estimativa de recursos

O conteúdo a seguir apresenta um modelo para estimar os recursos de computação e armazenamento necessários para uma implantação do ClickStack com base no volume de ingestão esperado. Os valores obtidos são apenas estimativas e devem ser usados como uma linha de base inicial — não são uma resposta prescritiva. Os requisitos reais dependem da complexidade das consultas, da concorrência, das políticas de retenção e da variação na vazão de ingestão. Sempre monitore o uso de recursos e escale conforme necessário.

Todos os valores são baseados em ingestão bruta não comprimida

Todos os números nesta página — throughput (MB/s, TB/mês), dimensionamento de CPU e armazenamento — são expressos em termos de volume bruto de ingestão não comprimido, ou seja, o tamanho dos dados conforme são produzidos pelas suas aplicações e enviados ao OpenTelemetry Collector antes da aplicação de qualquer compressão.

Esse é o valor que você deve estimar com base nos pipelines existentes de logs, traces e métricas. Os valores de armazenamento na tabela abaixo já consideram uma taxa de compressão de 10x aplicada a esse volume bruto.

Ao implantar o ClickStack, provisione capacidade computacional para cobrir duas cargas de trabalho independentes: ingestão e consulta.

Carga de trabalho	Recursos estimados
Ingestão	1 vCPU por 10 MB/s de throughput de ingestão sustentado
Consulta	1 vCPU por 1 QPS e por 10 MB/s de throughput de ingestão sustentado

Isolamento de Consultas vs. Ingestão

Na maioria das implantações autogerenciadas, a ingestão e a consulta compartilham os mesmos nós. Nesse caso, use o Total de CPUs como linha de base. O escalonamento isolado — em que a computação de ingestão e a de consulta são provisionadas de forma independente — é compatível com o ClickHouse Cloud por meio de pools de computação separados, também conhecidos como Warehouses.

Premissas

• Uma taxa de compressão de 10x para armazenamento — normalmente conservadora para logs e traces.
• SLAs de consulta com P50 de 1,5 segundo e P99 de 5 segundos.
• Assumimos que a maioria das consultas ocorre sobre dados recentes, seguindo uma distribuição log-normal que atinge o pico em cerca de uma hora e se estende até cerca de seis horas. Os usuários podem querer provisionar computação dedicada para consultar dados mais antigos. No ClickHouse Cloud, ela pode ficar ociosa (e, portanto, sem gerar custos) quando não estiver em uso.
• Embora a computação de consulta possa ser escalada de forma independente da computação de ingestão, ela continua intrinsicamente vinculada ao volume de ingestão. Assumimos que, à medida que a ingestão aumenta, a densidade dos dados cresce, resultando em volumes de varredura maiores no momento da consulta e, consequentemente, em maiores requisitos de computação para consulta.

A tabela a seguir apresenta exemplos de dimensionamento com base no aumento do throughput de ingestão em megabytes por segundo, juntamente com os volumes de dados correspondentes em terabytes por mês. Isso pressupõe uma média sustentada de 1 QPS do ClickStack em todos os tipos de consulta (pesquisa, dashboards, alertas).

MB/s	TB/mês	CPUs de ingestão	CPUs de consulta	CPUs totais	Armazenamento total (por mês) (GB)
10	25.92	1	3	4	2,592
20	51.84	2	6	8	5,184
50	129.6	5	15	20	12,960
100	259.2	10	30	40	25,920
200	518.4	20	60	80	51,840
500	1,296	50	150	200	129,600
1000	2,592	100	300	400	259,200

Para mais detalhes sobre como refinar as premissas de dimensionamento para seu ambiente, consulte “Refinando as premissas de dimensionamento para seu ambiente”.

​

Isolando cargas de trabalho de observabilidade

Se você estiver adicionando o ClickStack a um serviço existente do ClickHouse Cloud que já oferece suporte a outras cargas de trabalho, como análises de aplicações em tempo real, isolar o tráfego de observabilidade é altamente recomendado.

Use Managed Warehouses para criar um serviço filho dedicado ao ClickStack. Isso permite:

• Isolar a carga de ingestão e de consultas das aplicações existentes
• Escalonar as cargas de trabalho de observabilidade de forma independente
• Impedir que consultas de observabilidade impactem as análises em produção
• Compartilhar os mesmos dados subjacentes entre serviços quando necessário

Essa abordagem garante que suas cargas de trabalho existentes permaneçam inalteradas, ao mesmo tempo que permite que o ClickStack escale de forma independente à medida que os dados de observabilidade crescem.

Para implantações maiores ou orientações personalizadas de dimensionamento, entre em contato com o suporte para obter uma estimativa mais precisa.

ClickStack Open Source

​

Segurança de rede e portas

Por padrão, o Docker Compose expõe portas no host, tornando-as acessíveis de fora do container — mesmo que ferramentas como ufw (Uncomplicated Firewall) estejam habilitadas. Esse comportamento se deve à pilha de rede do Docker, que pode contornar as regras de firewall no nível do host, a menos que seja explicitamente configurada.

Recomendação:

Exponha apenas as portas necessárias para uso em produção. Normalmente os endpoints OTLP, o servidor de API e o frontend.

Por exemplo, remova ou comente os mapeamentos de porta desnecessários no seu arquivo docker-compose.yml:

ports:
  - "4317:4317"  # OTLP gRPC
  - "4318:4318"  # OTLP HTTP
  - "8080:8080"  # Somente se necessário para a API
# Evite expor portas internas como ClickHouse 8123 ou MongoDB 27017.

Consulte a documentação de rede do Docker para obter detalhes sobre isolamento de contêineres e reforço de acesso.

​

Configuração de Secret de sessão

Em produção, é obrigatório definir um valor forte e aleatório para a variável de ambiente EXPRESS_SESSION_SECRET do ClickStack UI (HyperDX) — para proteger os dados de sessão e evitar adulterações.

Veja como adicioná-lo ao seu arquivo docker-compose.yml para o serviço de app:

app:
    image: ${IMAGE_NAME_HDX}:${IMAGE_VERSION}
    ports:
      - ${HYPERDX_API_PORT}:${HYPERDX_API_PORT}
      - ${HYPERDX_APP_PORT}:${HYPERDX_APP_PORT}
    environment:
      FRONTEND_URL: ${HYPERDX_APP_URL}:${HYPERDX_APP_PORT}
      HYPERDX_API_KEY: ${HYPERDX_API_KEY}
      HYPERDX_API_PORT: ${HYPERDX_API_PORT}
      HYPERDX_APP_PORT: ${HYPERDX_APP_PORT}
      HYPERDX_APP_URL: ${HYPERDX_APP_URL}
      HYPERDX_LOG_LEVEL: ${HYPERDX_LOG_LEVEL}
      MINER_API_URL: 'http://miner:5123'
      MONGO_URI: 'mongodb://db:27017/hyperdx'
      NEXT_PUBLIC_SERVER_URL: http://127.0.0.1:${HYPERDX_API_PORT}
      OTEL_SERVICE_NAME: 'hdx-oss-api'
      USAGE_STATS_ENABLED: ${USAGE_STATS_ENABLED:-true}
      EXPRESS_SESSION_SECRET: "super-secure-random-string"
    networks:
      - internal
    depends_on:
      - ch-server
      - db1

Você pode gerar um segredo forte usando openssl:

openssl rand -hex 32

Evite fazer commit de Secrets no controle de versão. Em produção, considere usar ferramentas de gerenciamento de variáveis de ambiente (por exemplo, Docker Secrets, HashiCorp Vault ou configs de CI/CD específicas do ambiente).

​

Ingestão segura

Toda a ingestão deve ocorrer por meio das portas OTLP expostas pela distribuição ClickStack do coletor OpenTelemetry (OTel). Por padrão, isso requer uma API key de ingestão segura gerada na inicialização. Essa chave é obrigatória ao enviar dados para as portas OTel e pode ser encontrada na UI do HyperDX em Team Settings → API Keys.

Além disso, é recomendável habilitar TLS para os endpoints OTLP.

​

Criar um usuário de ingestão

Recomenda-se criar um usuário dedicado para o OTel collector para ingestão no ClickHouse e garantir que a ingestão seja direcionada a um banco de dados específico, por exemplo, otel. Consulte “Criando um usuário de ingestão” para mais detalhes.

​

ClickHouse

Usuários que gerenciam sua própria instância do ClickHouse devem seguir as boas práticas a seguir.

​

Melhores práticas de segurança

Se você gerencia sua própria instância do ClickHouse, é essencial habilitar TLS, exigir autenticação e seguir as melhores práticas para fortalecer o controle de acesso. Consulte esta publicação do blog para entender configurações incorretas em ambientes reais e como evitá-las.

O ClickHouse OSS oferece recursos de segurança robustos prontos para uso. No entanto, eles precisam ser configurados:

• Use TLS por meio de tcp_port_secure e <openSSL> em config.xml. Consulte guides/sre/configuring-tls.
• Defina uma senha forte para o usuário default ou desabilite-o.
• Evite expor o ClickHouse externamente a menos que isso seja explicitamente intencional. Por padrão, o ClickHouse escuta apenas em localhost, a menos que listen_host seja modificado.
• Use métodos de autenticação, como senhas, certificados, chaves SSH ou autenticadores externos.
• Restrinja o acesso usando filtragem por IP e a cláusula HOST. Consulte sql-reference/statements/create/user#user-host.
• Ative o Controle de Acesso Baseado em Funções (RBAC) para conceder privilégios granulares. Consulte operations/access-rights.
• Imponha quotas e limites usando quotas, perfis de configuração e modos de somente leitura.
• Criptografe os dados em repouso e use um armazenamento externo seguro. Consulte operations/storing-data e cloud/security/CMEK.
• Evite inserir credenciais diretamente no código. Use coleções nomeadas ou roles do IAM no ClickHouse Cloud.
• Audite os acessos e as consultas usando logs do sistema e logs de sessão.

Consulte também autenticadores externos e configurações de complexidade de consulta para gerenciar usuários e garantir limites de consulta/recurso.

​

Permissões de usuário para a ClickStack UI

O usuário do ClickHouse para a ClickStack UI precisa ser apenas um usuário readonly com permissão para alterar as seguintes configurações:

• max_rows_to_read (pelo menos 1 milhão)
• read_overflow_mode
• cancel_http_readonly_queries_on_client_close
• wait_end_of_query

Por padrão, o usuário default tanto no OSS quanto no ClickHouse Cloud terá essas permissões disponíveis; no entanto, recomenda-se criar um novo usuário com essas permissões.

​

Configurar Time To Live (TTL)

Certifique-se de que o Time To Live (TTL) foi configurado adequadamente para a sua implantação do ClickStack. Isso controla por quanto tempo os dados são retidos — o padrão de 3 dias frequentemente precisa ser alterado.

​

Diretrizes do MongoDB

Siga a lista de verificação de segurança oficial do MongoDB.