Tudo em um

Esta imagem Docker completa reúne todos os componentes do ClickStack Open Source:

• ClickHouse
• HyperDX
• collector do OpenTelemetry (OTel) (expondo OTLP nas portas 4317 e 4318)
• MongoDB (para o estado persistente da aplicação)

Esta opção inclui autenticação, permitindo a persistência de dashboards, alertas e pesquisas salvas entre sessões e usuários.

• Demos
• Testes locais do stack completo

Implantação com Docker

O comando a seguir executa um OpenTelemetry collector (nas portas 4317 e 4318) e a interface do HyperDX (na porta 8080).

docker run -p 8080:8080 -p 4317:4317 -p 4318:4318 clickhouse/clickstack-all-in-one:latest

Acesse a interface do HyperDX

Acesse http://localhost:8080 para abrir a interface do HyperDX.

Crie um usuário, informando um nome de usuário e uma senha que atendam aos requisitos.

Ao clicar em Create, serão criadas fontes de dados para a instância integrada do ClickHouse.

Para ver um exemplo de uso de outra instância do ClickHouse, consulte "Usando ClickHouse Cloud".

Ingestão de dados

Para ingerir dados, consulte "Ingerindo dados".

Para manter os dados e as configurações entre reinicializações do contêiner, você pode modificar o comando docker acima para montar os caminhos /data/db, /var/lib/clickhouse e /var/log/clickhouse-server. Por exemplo:

# garantir que os diretórios existam
mkdir -p .volumes/db .volumes/ch_data .volumes/ch_logs
# modificar o comando para montar os caminhos
docker run \
  -p 8080:8080 \
  -p 4317:4317 \
  -p 4318:4318 \
  -v "$(pwd)/.volumes/db:/data/db" \
  -v "$(pwd)/.volumes/ch_data:/var/lib/clickhouse" \
  -v "$(pwd)/.volumes/ch_logs:/var/log/clickhouse-server" \
  clickhouse/clickstack-all-in-one:latest

Esta opção não deve ser implantada em produção pelos seguintes motivos:

• Armazenamento não persistente: Todos os dados são armazenados usando o sistema de arquivos overlay nativo do Docker. Essa configuração não oferece bom desempenho em escala, e os dados serão perdidos se o contêiner for removido ou reiniciado, a menos que os usuários montem os caminhos de arquivo necessários.
• Falta de isolamento entre componentes: Todos os componentes são executados em um único contêiner Docker. Isso impede o escalonamento e o monitoramento independentes e aplica globalmente quaisquer limites de cgroup a todos os processos. Como resultado, os componentes podem competir por CPU e memória.

Se você precisar personalizar as portas do aplicativo (8080) ou da API (8000) em que o HyperDX Local é executado, será necessário modificar o comando docker run para encaminhar as portas corretas e definir algumas variáveis de ambiente.

A personalização das portas do OpenTelemetry pode ser feita simplesmente alterando as flags de encaminhamento de porta. Por exemplo, substituindo -p 4318:4318 por -p 4999:4318 para mudar a porta HTTP do OpenTelemetry para 4999.

docker run -p 8080:8080 -p 4317:4317 -p 4999:4318 clickhouse/clickstack-all-in-one:latest

Esta distribuição pode ser usada com o ClickHouse Cloud. Embora a instância local do ClickHouse ainda seja implantada (e ignorada), o OTel collector pode ser configurado para usar uma instância do ClickHouse Cloud definindo as variáveis de ambiente CLICKHOUSE_ENDPOINT, CLICKHOUSE_USER e CLICKHOUSE_PASSWORD.

Por exemplo:

export CLICKHOUSE_ENDPOINT=<HTTPS ENDPOINT>
export CLICKHOUSE_USER=<CLICKHOUSE_USER>
export CLICKHOUSE_PASSWORD=<CLICKHOUSE_PASSWORD>

docker run -e CLICKHOUSE_ENDPOINT=${CLICKHOUSE_ENDPOINT} -e CLICKHOUSE_USER=default -e CLICKHOUSE_PASSWORD=${CLICKHOUSE_PASSWORD} -p 8080:8080 -p 4317:4317 -p 4318:4318 clickhouse/clickstack-all-in-one:latest

O CLICKHOUSE_ENDPOINT deve ser o endpoint HTTPS do ClickHouse Cloud, incluindo a porta 8443, por exemplo: https://mxl4k3ul6a.us-east-2.aws.clickhouse.com:8443

Após se conectar à interface do HyperDX, navegue até Team Settings e crie uma conexão com seu serviço do ClickHouse Cloud, seguida pelos sources necessários.

A configuração do OTel collector pode ser alterada, se necessário. Consulte "Modificando a configuração".

O ClickStack armazena atributos como colunas Map(LowCardinality(String), String) por padrão. Esse é o esquema recomendado para cargas de trabalho de observabilidade. Em combinação com a serialização de map em buckets e índices de texto nas chaves e nos valores do map, ele permite lookups seletivos sem a sobrecarga de ingestão por chave das subcolunas JSON dinâmicas.

Um esquema do tipo JSON está disponível em beta para avaliação em cargas de trabalho com um conjunto pequeno e estável de chaves de atributo. Ele não é recomendado como padrão. Consulte Map vs tipo JSON para ver a comparação completa e as variáveis de ambiente necessárias para habilitar o suporte a JSON.