Set up docs MCPEste guia é para usuários atuais do ClickHouse Cloud. Se você está começando no ClickHouse Cloud, recomendamos nosso guia de Primeiros passos para o Managed ClickStack.
Nesse padrão de implantação, tanto o ClickHouse quanto a UI do ClickStack (HyperDX) são hospedados no ClickHouse Cloud, minimizando a quantidade de componentes que o usuário precisa hospedar por conta própria.
Além de reduzir o gerenciamento da infraestrutura, esse padrão de implantação garante que a authentication esteja integrada ao SSO/SAML do ClickHouse Cloud. Ao contrário das implantações self-hosted, também não é necessário provisionar uma instância do MongoDB para armazenar o estado da aplicação — como dashboards, pesquisas salvas, configurações do usuário e alertas. Os usuários também se beneficiam de:
- Escalonamento automático da capacidade computacional, independentemente do armazenamento
- Retenção de baixo custo e praticamente ilimitada com base em armazenamento de objetos
- A capacidade de isolar de forma independente workloads de leitura e gravação com Warehouses.
- Authentication integrada
- Backups automatizados
- Recursos de segurança e compliance
- Upgrades sem interrupções
Nesse modo, a ingestão de dados fica inteiramente a cargo do usuário. Você pode ingerir dados no Managed ClickStack usando seu próprio collector do OpenTelemetry hospedado, ingestão direta por bibliotecas cliente, motores de tabela nativos do ClickHouse (como Kafka ou S3), pipelines de ETL ou ClickPipes — o serviço gerenciado de ingestão do ClickHouse Cloud. Essa abordagem oferece a maneira mais simples e com melhor desempenho de operar o ClickStack.
Indicado para
Esse padrão de implantação é ideal nos seguintes cenários:
- Você já tem dados de observabilidade no ClickHouse Cloud e deseja visualizá-los com o ClickStack.
- Você opera uma implantação de observabilidade em grande escala e precisa do desempenho dedicado e da escalabilidade do ClickStack em execução no ClickHouse Cloud.
- Você já usa o ClickHouse Cloud para analytics e quer instrumentar sua aplicação usando as bibliotecas de instrumentação do ClickStack — enviando dados para o mesmo cluster. Nesse caso, recomendamos usar warehouses para isolar a capacidade computacional das cargas de trabalho de observabilidade.
Etapas de configuração
O guia a seguir pressupõe que você já criou um serviço do ClickHouse Cloud. Se ainda não criou um serviço, siga o guia Primeiros passos para Managed ClickStack. Ao final, você terá um serviço no mesmo estado descrito neste guia, ou seja, pronto para dados de observabilidade com o ClickStack ativado.
Crie um novo serviço
Na página inicial do ClickHouse Cloud, selecione New service para criar um novo serviço.
Especifique seu provedor, a região e o recurso
Selecione o provedor Cloud e a região.
Ao definir a CPU e a memória, faça uma estimativa com base na taxa de ingestão esperada do ClickStack. A tabela abaixo fornece orientações para dimensionar esses recursos.
| Volume mensal de ingestão | Capacidade computacional recomendada |
|---|---|
| < 10 TB / mês | 2 vCPU × 3 réplicas |
| 10–50 TB / mês | 4 vCPU × 3 réplicas |
| 50–100 TB / mês | 8 vCPU × 3 réplicas |
| 100–500 TB / mês | 30 vCPU × 3 réplicas |
| 1 PB+ / mês | 59 vCPU × 3 réplicas |
Essas recomendações se baseiam nas seguintes premissas:
- O volume de dados se refere ao volume mensal de ingestão não compactado e se aplica tanto a logs quanto a traces.
- Os padrões de consulta são típicos de casos de uso de observabilidade, com a maioria das consultas direcionadas a dados recentes, normalmente das últimas 24 horas.
- A ingestão é relativamente uniforme ao longo do mês. Se você espera tráfego irregular ou picos, deve provisionar capacidade adicional.
- O armazenamento é tratado separadamente por meio do armazenamento de objetos do ClickHouse Cloud e não é um fator limitante para retenção. Presumimos que dados retidos por períodos mais longos sejam acessados com pouca frequência.
Pode ser necessária mais capacidade computacional para padrões de acesso que consultam regularmente intervalos de tempo mais longos, realizam agregações pesadas ou atendem a um grande número de usuários simultâneos.
Embora duas réplicas possam atender aos requisitos de CPU e memória para uma determinada taxa de ingestão, recomendamos usar três réplicas sempre que possível para alcançar a mesma capacidade total e melhorar a redundância do serviço.
Depois de especificar os requisitos, seu serviço Managed ClickStack levará vários minutos para ser provisionado. Sinta-se à vontade para explorar o restante do console do ClickHouse Cloud enquanto aguarda o provisionamento.
Quando o provisionamento estiver concluído, a opção 'ClickStack' no menu à esquerda será habilitada.
Configure a ingestão
Depois que seu serviço for provisionado, verifique se ele está selecionado e clique em "ClickStack" no menu à esquerda.
Selecione "Start Ingestion" e será solicitado que você escolha uma fonte de ingestão. O Managed ClickStack oferece suporte a OpenTelemetry e Vector como suas principais fontes de ingestão. No entanto, os usuários também podem enviar dados diretamente para o ClickHouse em um schema próprio usando qualquer uma das integrações compatíveis com o ClickHouse Cloud.
Para enviar dados do OpenTelemetry para o Managed ClickStack, recomenda-se usar um OpenTelemetry Collector. O collector atua como um gateway que recebe dados do OpenTelemetry das suas aplicações (e de outros collectors) e os encaminha para o ClickHouse Cloud.
Se você ainda não tiver um em execução, inicie um collector usando as etapas abaixo. Se você já tiver collectors em execução, também disponibilizamos um exemplo de configuração.
Inicie um collector
O conteúdo a seguir presume o caminho recomendado: usar a distribuição ClickStack do OpenTelemetry Collector, que inclui processamento adicional e é otimizada especificamente para o ClickHouse Cloud. Se você quiser usar seu próprio OpenTelemetry Collector, consulte "Configurar collectors existentes."
Para começar rapidamente, copie e execute o comando Docker mostrado.
Esse comando já deve incluir suas credenciais de conexão preenchidas.
Executar esse único comando inicia o ClickStack collector com endpoints OTLP expostos nas portas 4317 (gRPC) e 4318 (HTTP). Se você já tiver instrumentação e agentes do OpenTelemetry, poderá começar imediatamente a enviar dados de telemetria para esses endpoints.
Configurar collectors existentes
Também é possível configurar seus próprios OpenTelemetry Collectors existentes ou usar sua própria distribuição do collector.
Para isso, fornecemos um exemplo de configuração do OpenTelemetry Collector que usa o exportador ClickHouse com as definições apropriadas e expõe receivers OTLP. Essa configuração corresponde às interfaces e ao comportamento esperados pela distribuição ClickStack.
Substitua os placeholders de endpoint e senha pelas credenciais geradas pelo ClickStack:
receivers:
otlp/hyperdx:
protocols:
grpc:
include_metadata: true
endpoint: "0.0.0.0:4317"
http:
cors:
allowed_origins: ["*"]
allowed_headers: ["*"]
include_metadata: true
endpoint: "0.0.0.0:4318"
processors:
batch:
memory_limiter:
# 80% of maximum memory up to 2G, adjust for low memory environments
limit_mib: 1500
# 25% of limit up to 2G, adjust for low memory environments
spike_limit_mib: 512
check_interval: 5s
connectors:
routing/logs:
default_pipelines: [logs/out-default]
error_mode: ignore
table:
- context: log
statement: route() where IsMatch(attributes["rr-web.event"], ".*")
pipelines: [logs/out-rrweb]
exporters:
clickhouse/rrweb:
database: default
endpoint: <clickhouse_cloud_endpoint>
password: <your_password_here>
username: default
ttl: 720h
logs_table_name: hyperdx_sessions
timeout: 5s
retry_on_failure:
enabled: true
initial_interval: 5s
max_interval: 30s
max_elapsed_time: 300s
clickhouse:
database: default
endpoint: <clickhouse_cloud_endpoint>
password: <your_password_here>
username: default
ttl: 720h
timeout: 5s
retry_on_failure:
enabled: true
initial_interval: 5s
max_interval: 30s
max_elapsed_time: 300s
service:
pipelines:
traces:
receivers: [otlp/hyperdx]
processors: [memory_limiter, batch]
exporters: [clickhouse]
metrics:
receivers: [otlp/hyperdx]
processors: [memory_limiter, batch]
exporters: [clickhouse]
logs/in:
receivers: [otlp/hyperdx]
exporters: [routing/logs]
logs/out-default:
receivers: [routing/logs]
processors: [memory_limiter, batch]
exporters: [clickhouse]
logs/out-rrweb:
receivers: [routing/logs]
processors: [memory_limiter, batch]
exporters: [clickhouse/rrweb]Para mais detalhes sobre como configurar collectors do OpenTelemetry, consulte "Ingestão com OpenTelemetry."
Iniciar ingestão (opcional)
Se você tiver aplicações ou infraestrutura existentes para instrumentar com OpenTelemetry, acesse os guias relevantes vinculados na UI.
Para instrumentar suas aplicações e coletar traces e logs, use os SDKs compatíveis para a sua linguagem, que enviam dados ao seu OpenTelemetry Collector, atuando como gateway para ingestão no Managed ClickStack.
Os logs podem ser coletados usando OpenTelemetry Collectors executados no modo agent, encaminhando dados para o mesmo collector. Para monitoramento de Kubernetes, siga o guia dedicado. Para outras integrações, consulte nossos guias de início rápido.
Dados de demonstração
Como alternativa, se você não tiver dados existentes, experimente um dos nossos conjuntos de dados de exemplo.
- Conjunto de dados de exemplo - Carregue um conjunto de dados de exemplo da nossa demonstração pública. Diagnostique um problema simples.
- Arquivos locais e métricas - Carregue arquivos locais e monitore o sistema no OSX ou Linux usando um OTel collector local.
Vector é um pipeline de dados de observabilidade de alto desempenho e independente de fornecedor, especialmente popular para ingestão de logs devido à sua flexibilidade e ao baixo consumo de recursos.
Ao usar o Vector com o ClickStack, os usuários são responsáveis por definir seus próprios esquemas. Esses esquemas podem seguir as convenções do OpenTelemetry, mas também podem ser totalmente personalizados, representando estruturas de eventos definidas pelo usuário.
O conteúdo a seguir pressupõe que você tenha uma instância do Vector em execução, pré-configurada com pipelines de ingestão e enviando dados.
Criar um banco de dados e uma tabela
O Vector exige que uma tabela e um esquema sejam definidos antes da ingestão de dados.
Primeiro, crie um banco de dados. Isso pode ser feito por meio do console do ClickHouse Cloud.
Por exemplo, crie um banco de dados para logs:
CREATE DATABASE IF NOT EXISTS logsEm seguida, crie uma tabela cujo esquema corresponda à estrutura dos seus dados de log. O exemplo abaixo considera um formato clássico de log de acesso do Nginx:
CREATE TABLE logs.nginx_logs
(
`time_local` DateTime,
`remote_addr` IPv4,
`remote_user` LowCardinality(String),
`request` String,
`status` UInt16,
`body_bytes_sent` UInt64,
`http_referer` String,
`http_user_agent` String,
`http_x_forwarded_for` LowCardinality(String),
`request_time` Float32,
`upstream_response_time` Float32,
`http_host` String
)
ENGINE = MergeTree
ORDER BY (toStartOfMinute(time_local), status, remote_addr);Sua tabela deve corresponder ao schema de saída produzido pelo Vector. Ajuste o schema conforme necessário para seus dados, seguindo as práticas recomendadas de schema.
Recomendamos fortemente que você entenda como as chaves primárias funcionam no ClickHouse e escolha uma chave de ordenação com base nos seus padrões de acesso. Consulte as orientações específicas do ClickStack sobre como escolher uma chave primária.
Depois que a tabela existir, copie o snippet de configuração exibido. Ajuste a entrada para consumir seus pipelines existentes, bem como a tabela de destino e o banco de dados, se necessário. As credenciais devem vir pré-preenchidas.
Para ver mais exemplos de ingestão de dados com o Vector, consulte "Ingestão com o Vector" ou a documentação do sink ClickHouse do Vector para opções avançadas.
Acesse a UI do ClickStack
Selecione 'Launch ClickStack' para acessar a UI do ClickStack (HyperDX). Você será autenticado automaticamente e redirecionado.
As fontes de dados serão criadas automaticamente para quaisquer dados do OpenTelemetry.
Se você estiver usando o Vector, precisará criar suas próprias fontes de dados. Na primeira vez que fizer login, será solicitado que você crie uma. Abaixo, mostramos uma configuração de exemplo para uma fonte de dados de logs.
Essa configuração pressupõe um esquema no estilo Nginx, com uma coluna time_local usada como timestamp. Sempre que possível, esta deve ser a coluna de timestamp declarada na chave primária. Essa coluna é obrigatória.
Também recomendamos atualizar o Default SELECT para definir explicitamente quais colunas são retornadas na visualização de logs. Se houver campos adicionais disponíveis, como nome do serviço, nível de log ou uma coluna Body, eles também poderão ser configurados. A coluna exibida como timestamp também pode ser substituída caso seja diferente da coluna usada na chave primária da tabela e configurada acima.
No exemplo acima, não existe uma coluna Body nos dados. Em vez disso, ela é definida usando uma expressão SQL que reconstrói uma linha de log do Nginx a partir dos campos disponíveis.
Para ver outras opções, consulte a referência de configuração.
Depois de criada, você deverá ser direcionado para a Search view, onde poderá começar imediatamente a explorar seus dados.
E é isso — está tudo pronto. 🎉
Agora, explore o ClickStack: comece pesquisando logs e traces, veja como logs, traces e métricas se correlacionam em tempo real, crie dashboards, explore mapas de serviço, descubra event deltas e patterns e configure alertas para se antecipar aos problemas.
Selecione um serviço
Na página inicial do ClickHouse Cloud, selecione o serviço no qual você deseja habilitar o Managed ClickStack.
Acesse a UI do ClickStack
Selecione 'ClickStack' no menu de navegação à esquerda. Você será redirecionado para a UI do ClickStack e autenticado automaticamente com base nas suas permissões do ClickHouse Cloud.
Se já houver tabelas do OpenTelemetry no seu serviço, elas serão detectadas automaticamente, e as fontes de dados correspondentes serão criadas.
Se a detecção automática for bem-sucedida, você deverá ser direcionado para a Search view, onde poderá começar imediatamente a explorar seus dados.
Se esta etapa for bem-sucedida, pronto — está tudo certo 🎉. Caso contrário, prossiga para a configuração da ingestão.
Configurar ingestão
Se a detecção automática falhar ou você não tiver tabelas existentes, será solicitado que configure a ingestão.
Selecione "Start Ingestion" e você será solicitado a escolher uma fonte de ingestão. O Managed ClickStack oferece suporte a OpenTelemetry e Vector como principais fontes de ingestão. No entanto, os usuários também têm a liberdade de enviar dados diretamente para o ClickHouse em seu próprio schema usando qualquer uma das integrações compatíveis com o ClickHouse Cloud.
Para enviar dados do OpenTelemetry para o Managed ClickStack, é recomendável usar um OpenTelemetry Collector. O collector atua como um gateway que recebe dados do OpenTelemetry das suas aplicações (e de outros collectors) e os encaminha para o ClickHouse Cloud.
Se você ainda não tiver um em execução, inicie um collector usando as etapas abaixo. Se você já tiver collectors, também há um exemplo de configuração.
Iniciar um collector
O texto a seguir parte do uso recomendado da distribuição ClickStack do OpenTelemetry Collector, que inclui processamento adicional e é otimizada especificamente para o ClickHouse Cloud. Se você quiser usar seu próprio OpenTelemetry Collector, consulte "Configurar collectors existentes."
Para começar rapidamente, copie e execute o comando Docker mostrado.
Modifique este comando com as credenciais do seu serviço, anotadas quando você criou o serviço.
Executar esse único comando inicia o ClickStack collector com endpoints OTLP expostos nas portas 4317 (gRPC) e 4318 (HTTP). Se você já tiver instrumentação OpenTelemetry e agents, poderá começar imediatamente a enviar dados de telemetria para esses endpoints.
Configurar collectors existentes
Também é possível configurar seus OpenTelemetry Collectors existentes ou usar sua própria distribuição do collector.
Para isso, é fornecido um exemplo de configuração do OpenTelemetry Collector que usa o exportador ClickHouse com as configurações adequadas e expõe receivers OTLP. Essa configuração corresponde às interfaces e ao comportamento esperados pela distribuição ClickStack.
Substitua os placeholders de endpoint e senha pelas credenciais geradas pelo ClickStack:
receivers:
otlp/hyperdx:
protocols:
grpc:
include_metadata: true
endpoint: "0.0.0.0:4317"
http:
cors:
allowed_origins: ["*"]
allowed_headers: ["*"]
include_metadata: true
endpoint: "0.0.0.0:4318"
processors:
batch:
memory_limiter:
# 80% of maximum memory up to 2G, adjust for low memory environments
limit_mib: 1500
# 25% of limit up to 2G, adjust for low memory environments
spike_limit_mib: 512
check_interval: 5s
connectors:
routing/logs:
default_pipelines: [logs/out-default]
error_mode: ignore
table:
- context: log
statement: route() where IsMatch(attributes["rr-web.event"], ".*")
pipelines: [logs/out-rrweb]
exporters:
clickhouse/rrweb:
database: default
endpoint: <clickhouse_cloud_endpoint>
password: <your_password_here>
username: default
ttl: 720h
logs_table_name: hyperdx_sessions
timeout: 5s
retry_on_failure:
enabled: true
initial_interval: 5s
max_interval: 30s
max_elapsed_time: 300s
clickhouse:
database: default
endpoint: <clickhouse_cloud_endpoint>
password: <your_password_here>
username: default
ttl: 720h
timeout: 5s
retry_on_failure:
enabled: true
initial_interval: 5s
max_interval: 30s
max_elapsed_time: 300s
service:
pipelines:
traces:
receivers: [otlp/hyperdx]
processors: [memory_limiter, batch]
exporters: [clickhouse]
metrics:
receivers: [otlp/hyperdx]
processors: [memory_limiter, batch]
exporters: [clickhouse]
logs/in:
receivers: [otlp/hyperdx]
exporters: [routing/logs]
logs/out-default:
receivers: [routing/logs]
processors: [memory_limiter, batch]
exporters: [clickhouse]
logs/out-rrweb:
receivers: [routing/logs]
processors: [memory_limiter, batch]
exporters: [clickhouse/rrweb]
Para mais detalhes sobre como configurar collectors OpenTelemetry, consulte "Ingestão com OpenTelemetry."
Iniciar a ingestão (opcional)
Se você tiver aplicações ou infraestrutura existentes para instrumentar com OpenTelemetry, acesse os guias relevantes vinculados em "Conectar uma aplicação".
Para instrumentar suas aplicações para coletar traces e logs, use os SDKs de linguagem compatíveis, que enviam dados para seu OpenTelemetry Collector, atuando como gateway para ingestão no Managed ClickStack.
Os logs podem ser coletados usando OpenTelemetry Collectors em execução no modo agent, encaminhando dados para o mesmo collector. Para monitoramento de Kubernetes, siga o guia dedicado. Para outras integrações, consulte nossos guias de início rápido.
Vector é um pipeline de dados de observabilidade de alto desempenho e independente de fornecedor, especialmente popular para ingestão de logs devido à sua flexibilidade e ao baixo consumo de recursos.
Ao usar o Vector com o ClickStack, os usuários são responsáveis por definir seus próprios esquemas. Esses esquemas podem seguir as convenções do OpenTelemetry, mas também podem ser totalmente personalizados, representando estruturas de eventos definidas pelo usuário.
O conteúdo a seguir pressupõe que você já tenha uma instância do Vector em execução, pré-configurada com pipelines de ingestão e enviando dados.
Crie um banco de dados e uma tabela
O Vector exige que uma tabela e um esquema sejam definidos antes da ingestão de dados.
Primeiro, crie um banco de dados. Isso pode ser feito por meio do console do ClickHouse Cloud.
Por exemplo, crie um banco de dados para logs:
CREATE DATABASE IF NOT EXISTS logsEm seguida, crie uma tabela cujo esquema corresponda à estrutura dos seus dados de log. O exemplo abaixo pressupõe um formato clássico de log de acesso do Nginx:
CREATE TABLE logs.nginx_logs
(
`time_local` DateTime,
`remote_addr` IPv4,
`remote_user` LowCardinality(String),
`request` String,
`status` UInt16,
`body_bytes_sent` UInt64,
`http_referer` String,
`http_user_agent` String,
`http_x_forwarded_for` LowCardinality(String),
`request_time` Float32,
`upstream_response_time` Float32,
`http_host` String
)
ENGINE = MergeTree
ORDER BY (toStartOfMinute(time_local), status, remote_addr);Sua tabela deve corresponder ao esquema de saída gerado pelo Vector. Ajuste o esquema conforme necessário para os seus dados, seguindo as boas práticas recomendadas para schema.
Recomendamos fortemente que você entenda como as chaves primárias funcionam no ClickHouse e escolha uma chave de ordenação com base nos seus padrões de acesso. Consulte as orientações específicas do ClickStack sobre como escolher uma chave primária.
Depois que a tabela existir, copie o trecho de configuração exibido. Ajuste a entrada para consumir seus pipelines existentes, bem como a tabela de destino e o banco de dados, se necessário. As credenciais devem vir pré-preenchidas.
Para mais exemplos de ingestão de dados com o Vector, consulte "Ingestão com o Vector" ou a documentação do sink ClickHouse do Vector para opções avançadas.
Acesse a UI do ClickStack
Depois de concluir a configuração da ingestão e começar a enviar dados, selecione "Next".
Se você tiver feito a ingestão de dados do OpenTelemetry usando este guia, as fontes de dados serão criadas automaticamente e nenhuma configuração adicional será necessária. Você pode começar a explorar o ClickStack imediatamente. Você será direcionado para a Search view, com uma fonte selecionada automaticamente, para que possa começar a executar consultas na hora.
É isso — está tudo pronto 🎉.
Se você tiver feito a ingestão de dados via Vector ou outra fonte, será solicitado que configure a fonte de dados.
A configuração acima pressupõe um schema no estilo Nginx, com uma coluna time_local usada como timestamp. Sempre que possível, essa deve ser a coluna de timestamp declarada na chave primária. Essa coluna é obrigatória.
Também recomendamos atualizar o Default SELECT para definir explicitamente quais colunas são retornadas na visualização de logs. Se houver campos adicionais disponíveis, como nome do serviço, nível de log ou uma coluna body, eles também poderão ser configurados. A coluna exibida como timestamp também pode ser substituída se for diferente da coluna usada na chave primária da tabela e configurada acima.
No exemplo acima, não existe uma coluna Body nos dados. Em vez disso, ela é definida usando uma expressão SQL que reconstrói uma linha de log do Nginx a partir dos campos disponíveis.
Para outras opções possíveis, consulte a referência de configuração.
Depois que a fonte estiver configurada, clique em "Save" e comece a explorar seus dados.
Tarefas adicionais
Concedendo acesso ao Managed ClickStack
- Acesse seu serviço no console do ClickHouse Cloud
- Vá para Configurações → Acesso ao SQL Console
- Defina o nível de permissão apropriado para cada usuário:
- Service Admin → Full Access - Necessário para habilitar alertas
- Service Read Only → Read Only - Pode visualizar dados de observabilidade e criar dashboards
- No access - Não pode acessar o HyperDX
Usando o ClickStack com capacidade computacional somente leitura
A interface do ClickStack pode ser executada inteiramente em um serviço somente leitura do ClickHouse Cloud. Essa é a configuração recomendada quando você quiser isolar as cargas de trabalho de ingestão e de consulta.
Como o ClickStack seleciona a capacidade computacional
A UI do ClickStack sempre se conecta ao serviço do ClickHouse a partir do qual ela é iniciada no console do ClickHouse Cloud.
Isso significa:
- Se você abrir o ClickStack a partir de um serviço somente leitura, todas as consultas emitidas pela UI do ClickStack serão executadas nessa capacidade computacional somente leitura.
- Se você abrir o ClickStack a partir de um serviço de leitura e gravação, o ClickStack usará essa capacidade computacional.
Nenhuma configuração adicional no ClickStack é necessária para garantir o comportamento somente leitura.
Configuração recomendada
Para executar o ClickStack em capacidade computacional somente leitura:
- Crie ou identifique um serviço do ClickHouse Cloud no warehouse configurado como somente leitura.
- No console do ClickHouse Cloud, selecione o serviço somente leitura.
- Inicie o ClickStack no menu de navegação à esquerda.
Depois de iniciado, a UI do ClickStack será vinculada automaticamente a esse serviço somente leitura.
Adicionando mais fontes de dados
O ClickStack é nativo do OpenTelemetry, mas não se limita ao OpenTelemetry — você pode usar seus próprios esquemas de tabela, se desejar.
A seguir, descrevemos como adicionar outras fontes de dados além das que são configuradas automaticamente.
Usando esquemas do OpenTelemetry
Se você estiver usando um OTel collector para criar o banco de dados e as tabelas no ClickHouse, mantenha todos os valores padrão no modelo de criação da fonte de dados, preenchendo o campo Table com o valor otel_logs para criar uma fonte de logs. Todas as outras configurações devem ser detectadas automaticamente, permitindo que você clique em Salvar Nova Fonte de Dados.
Para criar fontes para traces e métricas do OTel, você pode selecionar Criar Nova Fonte de Dados no menu superior.
A partir daí, selecione o tipo de fonte necessário e, em seguida, a tabela apropriada. Por exemplo, para traces, selecione a tabela otel_traces. Todas as configurações devem ser detectadas automaticamente.
Usando esquemas personalizados
Usuários que desejam conectar o ClickStack a um serviço existente que já contém dados podem configurar o banco de dados e a tabela conforme necessário. As configurações serão detectadas automaticamente se as tabelas estiverem em conformidade com os esquemas do OpenTelemetry para ClickHouse.
Se você estiver usando seu próprio esquema, recomendamos criar uma fonte de logs e garantir que os campos obrigatórios estejam especificados — consulte "Configurações da fonte de logs" para mais detalhes.
Escolha de esquema: Map vs JSON
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.