Substituindo OTel e ampliando a plataforma de observabilidade com wide events

• O LogHouse interno da ClickHouse cresceu, em 1 ano, de 19 PiB e cerca de 40 trilhões de linhas para mais de 100 PB de logs não comprimidos e quase 500 trilhões de linhas armazenadas
• O caminho de coleta centrado em OpenTelemetry fazia a conversão entre JSON, formato OTel e formato nativo do ClickHouse, aumentando o custo de CPU e o risco de perda de logs
• A ClickHouse passou a usar o SysEx (System Tables Exporter) para copiar em nível de bytes as tabelas de sistema para o LogHouse, processando 37M logs/s com 70 núcleos de CPU
• O OTel continua útil para logs de falha baseados em stdout e stderr e como formato padrão neutro em relação a fornecedores, mas a telemetria principal do ClickHouse está migrando para SysEx e wide events
• Após a adoção do HyperDX, a empresa vem substituindo parte do papel da UI customizada baseada em Grafana ao combinar UI nativa do ClickHouse, busca com sintaxe Lucene, análise em SQL e exploração independente de esquema

---

O LogHouse cresceu para 100 PB e 500 trilhões de linhas

• O LogHouse é a plataforma interna de logging criada para monitorar o ClickHouse Cloud e também serviu para substituir os custos crescentes do Datadog
• Há 1 ano, ele processava 19 PiB de dados não comprimidos e 37 trilhões de linhas; hoje, armazena mais de 100 PB de dados não comprimidos e quase 500 trilhões de linhas
• A composição principal dos dados armazenados hoje é a seguinte
  • SysEx: 93,6 PB, 431 trilhões de linhas
  • OTel: 14,5 PB, 16,7 trilhões de linhas
• Antes, toda a telemetria passava pelo OpenTelemetry, mas agora a maior parte dos dados entra via SysEx, um exporter especializado criado pela própria ClickHouse

Limites do pipeline OpenTelemetry

• O OpenTelemetry era adequado como pipeline padrão inicial para enviar ao ClickHouse os logs de todos os Pods em ambiente Kubernetes
• Apenas os logs de texto em stdout do ClickHouse não bastavam para análise operacional; na prática, eram necessários logs estruturados das tabelas system, métricas, detalhes de execução, I/O de disco e estado de jobs em background
• O caminho antigo dos logs via OTel passava por várias etapas de transformação
  • A instância ClickHouse do cliente gravava logs em JSON no stdout
  • O kubelet salvava os logs em /var/log/…
  • O collector do OTel lia os logs do disco, fazia parse do JSON e convertia para uma representação em memória
  • O collector convertia isso novamente para o formato de logs do OTel
  • O cliente Go do ClickHouse reconvertia para o formato nativo do ClickHouse antes de inserir no LogHouse
• O pipeline real de OTel também incluía edge collector, transporte OTLP, gateway collector e processamento adicional, e cada etapa aumentava o overhead, a latência e a complexidade
• Com o crescimento da escala, dois problemas ficaram mais evidentes
  • Os tipos nativos do ClickHouse passavam por JSON e formato OTel, desperdiçando CPU e reduzindo a fidelidade dos dados
  • O agent de OTel nos nós Kubernetes batia em limites de CPU e memória e descartava linhas de log quando havia picos de tráfego
• Estima-se que, para processar 20M rows/s sem perdas com base em OTel, seriam necessários cerca de 8.000 núcleos de CPU somando agents e collectors

SysEx: coletor especializado em transferência ClickHouse-para-ClickHouse

• A ClickHouse criou o System Tables Exporter (SysEx) para transferir diretamente dados das tabelas de sistema do ClickHouse nos Pods dos clientes para tabelas do LogHouse
• O SysEx faz cópia em nível de bytes entre origem e destino, preservando os tipos nativos do ClickHouse e eliminando conversões intermediárias
• Graças a essa estrutura, fica fácil transformar as consultas usadas por engenheiros para depurar instâncias em tempo real em consultas sobre o histórico de toda a frota no LogHouse
  • O esquema das tabelas é o mesmo, com apenas colunas adicionais de enriquecimento como nome do Pod e versão do ClickHouse
• A arquitetura é composta por um pool de scrapers do SysEx e um hash ring
  • O hash ring atribui os Pods dos clientes a réplicas específicas de scraper para distribuir a carga
  • O scraper executa SELECT na system table do Pod de origem e faz streaming dos dados para o LogHouse
  • O scraper coordena a transferência de bytes entre origem e destino sem desserialização
• Para evitar perder flushes de buffer das tabelas de sistema, o SysEx usa uma janela de tempo deslizante e normalmente consulta com 5 minutos de atraso em relação ao tempo real
• Como o comportamento padrão do cliente Go do ClickHouse converte dados para tipos nativos de Go, a ClickHouse contribuiu com um recurso para contornar o marshalling interno no clickhouse-go
• Como o SysEx usa um modelo pull, ele não precisa de buffering pesado como o OTel e, se o LogHouse ficar temporariamente indisponível ou a telemetria de origem disparar, pode reexecutar a coleta de janelas passadas para fazer backfill

Esquema dinâmico e snapshots de estado

• O SysEx exige que os esquemas de origem e destino coincidam, mas o esquema das system tables do ClickHouse muda com frequência com a adição de novas métricas e colunas
• Para lidar com isso, ao encontrar uma system table, o SysEx inspeciona e faz hash do esquema e verifica se já existe no LogHouse uma tabela com esse mesmo esquema
  • Se existir, insere na tabela existente
  • Se não existir, cria uma nova versão de esquema, como text_log_6
• No momento da consulta, usa-se o Merge table engine do ClickHouse para unir várias iterações de esquema em uma única visão lógica
• O Merge table engine permite selecionar apenas colunas compatíveis ou limitar a consulta às tabelas que possuem as colunas pedidas, possibilitando consultas mesmo com mudanças de esquema sem gestão manual
• A ClickHouse também captura periodicamente como snapshots system tables em memória como system.processes e as salva no LogHouse
• Esses snapshots são usados para analisar, com base histórica, o estado do cluster em determinado momento, o esquema das tabelas e a configuração do cluster

Análise de toda a frota e números de eficiência

• Com o SysEx, é possível executar ao mesmo tempo em toda a frota de instâncias dos clientes as consultas dos Advanced Dashboards usadas para monitorar instâncias individuais do ClickHouse
• Na análise de releases, consultas de diagnóstico são executadas antes e depois do deploy para verificar em tempo real, na escala de toda a frota, padrões de desempenho de consultas, tendências de uso de recursos e mudanças na taxa de erro
• Os dashboards de suporte correlacionam, na mesma interface, consultas dos Advanced Dashboards, logs de rede, eventos do Kubernetes e eventos do data plane e do control plane
• A comparação de eficiência no LogHouse é a seguinte
  • OTel Collectors: mais de 800 núcleos de CPU para enviar 2M logs/s
  • LogHouse Scrapers (SysEx): 70 núcleos de CPU para enviar 37M logs/s
• O SysEx aumentou em 20x o volume de eventos na fonte de dados mais importante, ao mesmo tempo em que reduziu o footprint de CPU para menos de 10% do anterior e eliminou a perda de eventos na edge

Onde o OpenTelemetry ainda é necessário

• O OpenTelemetry continua sendo a opção padrão do ClickStack por oferecer um formato padronizado e neutro em relação a fornecedores e uma boa experiência inicial para novos usuários
• O SysEx é fortemente acoplado ao interior do ClickHouse e, por ser baseado em pull sobre consultas em system tables ativas, não consegue coletar dados se o serviço estiver em crash loop ou fora do ar
• O OpenTelemetry captura passivamente logs emitidos em stdout e stderr, então consegue coletar logs durante falhas mesmo quando o serviço não está totalmente saudável
• A ClickHouse continua executando OpenTelemetry em todos os serviços ClickHouse, mas mudou o escopo da coleta
  • Antes, fazia ingest até de logs em nível trace
  • Agora, coleta apenas info-level ou acima
• Após essa mudança, os collectors e gateways de OTel passaram a operar com bem menos recursos, mantendo o pipeline menor mencionado anteriormente, na escala de 2M linhas de log/s

HyperDX e a experiência nativa de exploração no ClickHouse

• A primeira UI do LogHouse era uma experiência customizada de observabilidade construída sobre o Grafana, mas o aumento do SysEx e da telemetria wide-column exigiu uma UI mais profundamente integrada ao ClickHouse
• O HyperDX funciona como UI nativa do ClickHouse para exploração de logs e traces, correlação e análises em larga escala
• A possibilidade de consultar com sintaxe Lucene simplifica a exploração dos dados, enquanto o SQL continua disponível para análises de eventos mais complexas
• A abordagem independente de esquema do HyperDX v2.0 não exige uma estrutura única e fixa de tabela de logs
  • Ela lida com os formatos de dados padronizados, mas mutáveis, do pipeline OpenTelemetry
  • Também lida com tabelas specialized wide-column do SysEx e de outros exporters customizados sem exigir conhecimento prévio de esquema nem padrões grok complexos
• O Grafana ainda continua tendo papel no LogHouse
  • Um app interno baseado em Grafana exige a especificação do namespace, entende onde os dados de cada serviço estão e encaminha a consulta para a instância adequada do ClickHouse
  • Dashboards e alertas legados baseados em métricas do Prometheus continuam no Grafana
  • Métricas de alto nível como kube_state_metrics podem não ser ideais para investigação profunda, mas continuam adequadas para alerting

Wide events e observabilidade de alta cardinalidade

• A adoção do SysEx levou a uma mudança do modelo centrado em logs de stdout para um modelo centrado em wide events baseados em system tables e dados de alta cardinalidade
• A ClickHouse chama isso, não de Observability 2.0, mas da combinação entre LogHouse e ClickStack
• Em vez do modelo tradicional dos três pilares, esse modelo armazena telemetria de alta cardinalidade de várias fontes em um warehouse central
• Cada linha contém contexto rico, como identificador de consulta, nome do Pod, metadados de versão e detalhes de rede, sem pré-agregar ou descartar dimensões para caber nas limitações de um metric store
• Em vez de resumir na ingestão, os dados brutos são preservados e a agregação fica para o momento da consulta
• A diferença em relação ao Prometheus é que todos os data points são armazenados
  • Campos como insertDuration não são pré-agregados; cada valor é preservado com as dimensões relevantes
  • No Prometheus, armazenar timeseries para todas as combinações de labels causaria explosão de cardinalidade
  • A pré-agregação em histogramas ajuda a controlar o uso de recursos, mas dificulta responder a perguntas como qual instância, tabela ou janela de tempo gerou determinado spike de insert
• O Elasticsearch também incentivava wide events e estruturas flexíveis de documentos, mas o design colunar do ClickHouse permite armazenar e consultar com eficiência dados de eventos de alta cardinalidade e alto volume em grande escala

Ferramentas de ciência de dados e análise em SQL

• Um único wide event pode ser visualizado sob várias características, e de um ponto específico do gráfico é possível voltar ao log bruto
• A ClickHouse oferece integrações de visualização de dados e clientes de linguagem, permitindo usar ferramentas baseadas em SQL como Plotly, Jupyter notebook, Hex, Bokeh e Evidence
• A busca com sintaxe Lucene do HyperDX é adequada para consultas rápidas e filtros, mas perguntas complexas exigem SQL
• O SQL do ClickHouse consegue expressar joins, operações baseadas em tempo e transformações
  • Um exemplo combina, com ASOF JOIN, eventos Killing e Created do mesmo container em um stream de eventos do Kubernetes para calcular quanto tempo levou entre a finalização e o reinício
  • A consulta de exemplo processou 17,78M linhas e 581,49 MB em 0,099 segundo, com pico de memória de 272,88 MiB
• Em vez de criar e implantar previamente componentes para métricas necessárias, elas podem ser derivadas no momento da consulta a partir do warehouse de wide events

Novas fontes de dados adicionadas ao LogHouse

• O LogHouse adicionou mais sinks de dados baseados em wide events em resposta a pedidos das equipes de engenharia e suporte
• kubenetmon: ferramenta open source para monitoramento de rede no Kubernetes que usa conntrack do Linux para capturar dados de conexão L3/L4 e contagens de bytes e pacotes
  • Oferece forensics, atribuição de workload e Pod e medição de custos como egress entre regiões
  • Projeto: https://github.com/ClickHouse/kubenetmon
• Kubernetes Event Exporter: fork de um exporter popular com um sink nativo para ClickHouse adicionado para analisar em escala os eventos da API do Kubernetes
  • fork: ClickHouse/kubernetes-event-exporter
  • A empresa planeja, no futuro, ingerir no LogHouse não só eventos, mas todo o modelo de objetos do Kubernetes, além de armazenar snapshots de cada momento de mudança
• Control Plane Data: coleta de dados operacionais do departamento de Control Plane que ainda não haviam sido incorporados ao LogHouse
• Real User Monitoring (RUM): projeto em andamento que envia métricas de desempenho de frontend do navegador do usuário, via gateway público, para o pipeline de OTel
• Istio Access Log: ingestão de dados de tráfego HTTP do service mesh Istio para capturar padrões de request e response, latência e decisões de roteamento
  • Em conjunto com system.query_log e os fluxos de rede do kubenetmon, isso permite análise cruzada de consultas SQL, requests HTTP e fluxo de pacotes

Próximos passos: zero-impact scraping e JSON

• As consultas de scrape do SysEx são limitadas por um strict memory limit, mas isso pode gerar preocupação quando os clientes veem esse comportamento em logs e métricas
• A ClickHouse está explorando um zero-impact scraping que não execute consultas no sistema em produção
  • Uma direção promissora é aproveitar o plain rewritable disk em S3 que o ClickHouse já usa para gravar logs de serviço
  • Se o pool de workers do SysEx montar diretamente a tabela de logs baseada em disco, será possível contornar consultas na instância ClickHouse em execução
• Se essa abordagem funcionar, será possível manter as vantagens atuais de formato nativo, alta fidelidade e transformação mínima, reduzindo também a percepção de impacto operacional
• O tipo JSON do ClickHouse alcançou GA na versão 25.3 e cria dinamicamente colunas do tipo apropriado quando surgem novos campos, além de lidar com campos com múltiplos tipos e com schema explosion
• O LogHouse está avaliando o quanto o JSON se encaixa em padrões de acesso de observabilidade em larga escala
  • Buscar strings em todo um blob JSON pode exigir varrer milhares de colunas
  • Existe a alternativa de armazenar, junto com os dados estruturados, a string JSON bruta
  • A maioria dos atributos de log e resource é pequena e estável, então o tipo Map continua sendo adequado em muitos casos
  • O HyperDX converte automaticamente acesso a map para a função JSONExtract