Substituindo o OTel e expandindo a plataforma de observabilidade com Wide Events

• LogHouse escalou em um ano de 19 PiB para mais de 100 PB de dados de logs, chegando a cerca de 500 trilhões de linhas
• Devido aos limites e ineficiências no processamento de dados do OpenTelemetry (OTel), houve migração para um pipeline sob medida (SysEx) adequado ao sistema central
• Com essa transição, foi possível alcançar uma eficiência em que a taxa de processamento de eventos aumentou 20 vezes enquanto o uso de CPU permaneceu abaixo de 10%
• Com a adoção de HyperDX e ClickStack do ClickHouse, foram construídos integração entre UI e dados, flexibilidade de esquema e um ambiente robusto de exploração de dados
• Com a adoção de um modelo de wide events e alta cardinalidade, tornou-se possível armazenar e analisar todos os eventos sem pré-agregação

---

Contexto e mudanças

• LogHouse, a plataforma interna de logging do ClickHouse Cloud, cresceu em um ano de um sistema com 19 PiB de dados e 3,7 trilhões de linhas para um sistema de grande porte com mais de 100 PB e quase 500 trilhões de linhas
• No início, toda a telemetria era coletada via OpenTelemetry (OTel), mas em um ambiente de dados em grande escala ficaram evidentes problemas de desempenho, limites de recursos e desperdício de CPU e perda de dados durante o processo de transformação de dados

Limites do OTel e por que adotar um pipeline sob medida

• O pipeline do OTel era extremamente ineficiente, porque os logs eram convertidos para JSON, depois remapeados novamente para o formato OTel, repetindo várias conversões e marshaling
• Na prática, processar 20 milhões de linhas por segundo com base em OTel exigiria cerca de 8.000 núcleos de CPU
• Em picos de tráfego, o Collector ficava sobrecarregado e ocorria queda de logs, gerando dados que não eram coletados

Adoção e arquitetura do SysEx

• SysEx (System Tables Exporter) move dados das system tables do ClickHouse diretamente para o LogHouse, preservando os tipos originais e sem conversões
• Com scraping distribuído por estrutura de hash ring, buffer de atraso temporal e janelas deslizantes, evita perda de dados e atende ao SLA interno
• Usando Go e funcionalidades customizadas do cliente ClickHouse, é possível fazer transferência byte-to-byte sem marshaling de dados
• Para lidar com esquemas variáveis, foram aplicados hash de esquema e gerenciamento dinâmico de schema, e o Merge table engine integra várias versões de schema em uma única visão lógica
• Coleta baseada em snapshots de tabelas em memória e suporte a tarefas avançadas de diagnóstico e análise

Melhorias de desempenho e eficiência

• Com a adoção do SysEx, enquanto o OTel Collector processa 2 milhões de logs por segundo com 800 CPUs, o SysEx consegue processar 37 milhões de logs com 70 CPUs
• Esse ganho de eficiência reduziu drasticamente o uso de recursos, evitou perda de eventos e viabilizou um ambiente com suporte em tempo real

O papel contínuo do OTel

• O OTel continua fornecendo uma plataforma padrão e neutra em relação a fornecedor, e segue sendo essencial em falhas de serviço ou estados anormais
• Ele ainda consegue capturar logs em situações de crash e anomalias que o SysEx não consegue processar
• Atualmente, apenas logs abaixo do nível trace são descartados, e são coletados somente logs de nível info ou superior para otimizar recursos

Integração de UI com HyperDX e ClickStack

• Está em curso uma transição gradual da UI customizada baseada em Grafana para uma UI nativa de ClickHouse baseada em HyperDX
• O HyperDX oferece compatibilidade completa com a ampla variedade de tipos de dados do ClickHouse, com independência de schema, suporte a consultas Lucene e suporte a SQL
• Mesmo dados vindos de diferentes estruturas de tabela e de Exporters customizados podem ser integrados sem mudanças na UI
• O Grafana continua responsável por métricas baseadas em Prometheus e dashboards fixos, de modo que as duas soluções são usadas de forma complementar

Adoção de Wide Events e modelo de alta cardinalidade

• Wide events são uma abordagem inovadora em que cada linha inclui diversos contextos, como ID da consulta, nome do Pod e informações de versão, armazenando todos os dados sem agregação
• Diferentemente de soluções como Prometheus, essa abordagem permite análise profunda e consultas flexíveis sem pré-agregação, limites de labels ou preocupação com explosão de cardinalidade
• Ao realizar as agregações necessárias no momento da análise, é possível equilibrar desempenho e custo mesmo em ambientes com grandes volumes de dados

Visualização de dados e flexibilidade de consulta

• O ClickHouse se integra muito bem com Plotly, Jupyter notebook e outras ferramentas, permitindo usar livremente diversos recursos de visualização
• Além da exploração rápida do HyperDX baseado em Lucene, o ClickHouse também permite diretamente análises avançadas de causa raiz por meio de consultas com relações e condições complexas (SQL, JOIN etc.)

Crescimento de diversas fontes de dados baseadas em Wide Events

• kubenetmon: open source de monitoramento de rede Kubernetes, análise de tráfego L3/L4, conexões e custos
• Kubernetes Event Exporter: uso de um fork com adição de sink para ClickHouse, rastreamento de mudanças de estado em clusters de grande porte, e experimentos com snapshots completos de objetos
• Control Plane Data, RUM (Real User Monitoring) e Istio Access Log: dados de várias camadas que ampliam fortemente o alcance de interpretação e a capacidade de análise de correlação

Considerações operacionais e direções futuras

• O SysEx pode ficar exposto a logs e métricas durante consultas, mas foi projetado com limites de memória e uma estrutura que minimiza o impacto em caso de erro
• Zero-impact scraping: estão sendo estudadas formas totalmente desacopladas (por exemplo, usando plain rewritable disk baseado em S3) para eliminar de forma fundamental até mesmo o impacto sobre o cluster
• O OTel continua importante para garantir logs no início do serviço e em estados anormais, mas, conforme a abordagem zero-impact se estabilizar, a dependência dele deve cair ainda mais

Evolução e uso do tipo JSON do ClickHouse

• O tipo JSON foi lançado oficialmente em GA, permitindo criação dinâmica de colunas por campo, suporte a vários tipos e resposta flexível até mesmo a explosões de schema
• Como a otimização para consultas JSON com grande número de colunas ainda não está perfeita, seguem sendo refinadas abordagens como armazenamento paralelo por formato e a confirmação da praticidade do tipo Map
• Em integração com o HyperDX, é possível extrair e analisar automaticamente campos Map e JSON, com planos de ampliar ainda mais o uso de JSON no futuro

Conclusão e mudança cultural

• O LogHouse agora se consolidou como a plataforma central de observabilidade da operação do ClickHouse Cloud, indo de análise de desempenho até debugging em tempo real
• A redução de custos foi o ponto de partida, mas com ferramentas sob medida como o SysEx, a combinação com OTel e a expansão de uma UI flexível baseada em HyperDX, a equipe vem passando por uma transformação técnica e cultural
• Um modelo de dados baseado em Wide Events, em larga escala e com alta precisão, oferece novo valor e eficiência para engenharia, suporte e análise de dados
• A partir da experiência obtida na escala de 100 PB e 500 trilhões de linhas, o plano é continuar liderando o futuro da observabilidade

[GN⁺]

Comentários do Hacker News

• Sinceramente, não acho que isso seja algo de que se orgulhar. Armazenar 100 PB de logs é sinal de que ainda não descobriram o que realmente vale a pena manter. A maior parte das informações essenciais dá para entender bem só com métricas e eventos estruturados. O resto? Logs de trace detalhados que ninguém lê e que só são vistos quando dá uma pane de verdade. Uma forma melhor? Adotar uma “política de retenção baseada em interesse”, apagando automaticamente logs que nunca foram usados em alertas, ou que não apareceram em nenhuma busca por 3 meses. Sem ir nessa direção, isso é só um monte de lixo digital premium com um pouco de compressão
  • Eu penso o contrário: prefiro coletar todos os dados e filtrar quando não precisar deles. Logs de debug não são necessários no dia a dia, mas, quando são, são absolutamente indispensáveis. Se algum evento for raro demais para ser reproduzido, não dá para sair coletando os dados de novo só naquele momento. Se já está tudo armazenado, basta procurar, então acho muito melhor
  • Já trabalhei em várias empresas usando Datadog e, quando a conta de renovação vinha absurda, sempre aparecia pressão para manter só métricas e eventos limitados e cortar logs. O problema é que, se a gente soubesse antecipadamente o que ia acontecer, já teria corrigido antes. Quando algo estranho acontece, logs detalhados são muito necessários para descobrir o que houve. Mas, na prática, se não for algo recorrente, não tem como saber de antemão quais logs vão ser importantes
  • “Política de retenção baseada em interesse” é uma ideia muito boa mesmo. Só de contar quantas vezes cada padrão de log foi acessado por consultas/alertas já dá para definir uma política de TTL (tempo de retenção). Nosso time adotou isso na prática e reduziu os custos de armazenamento em 70%, mantendo todos os dados importantes
  • O custo de enviar logs também não é grátis. Em especial, em linguagens que escrevem logs em disco o mais rápido possível para descobrir a causa de crashes, isso custa ainda mais. Informação demais também dificulta encontrar as correlações realmente importantes, e logs de bugs já resolvidos perdem valor rapidamente. Eu prefiro dados estatísticos. Dados estatísticos são eficientes de agregar e, especialmente em linguagens baseadas em GIL, o overhead de usar OTEL às vezes pode ser excessivo
  • Se os dados já estiverem armazenados, então filtragem e limpeza depois são problemas administráveis. Acho melhor guardar tudo e usar quando precisar do que sofrer por não ter os dados quando precisar. Claro, isso parte do pressuposto de que você tem recursos para operar uma infraestrutura desse porte
• Isso na verdade se aplica só aos logs do Clickhouse. Não tem muita relação com outros tipos de log. Claro, eu gosto bastante do próprio Clickhouse como solução
  • Você deve ser divertidíssimo em festas
• Vou mencionar um ponto de atenção. Quando o serviço entra em loop de crash ou cai por falha, com SysEx não dá para acessar as tabelas de sistema necessárias e, portanto, não é possível coletar logs. Já o OpenTelemetry (OTel) é passivo, então mesmo que o serviço não tenha se recuperado completamente, ainda dá para capturar logs que saem em stdout e stderr. Assim dá para coletar logs mesmo em estado de falha e analisar até a causa raiz
  • Todos os projetos com OTel em que trabalhei usavam abordagem ativa. Então isso não me parece exatamente uma informação nova; soa mais como uma explicação errada ou incompleta
• Fico na dúvida se “wide events” realmente precisam consumir tanto espaço de armazenamento assim. Observabilidade é, no fundo, um problema de amostragem. O que importa é conseguir reconstruir o melhor possível o estado de um certo momento usando o mínimo de armazenamento. Dá para reduzir a quantidade de amostras ou melhorar a eficiência da compressão. E eu nem acho que a tecnologia de compressão já tenha chegado ao limite. Em dados cheios de redundância, deve existir uma estrutura enorme de baixa dimensão (low rank). Claro, já se usa índice invertido e vários tipos de árvore, mas também acho promissoras abordagens mais experimentais, como decomposição tensorial de baixa dimensão, mais no campo de pesquisa. Também não sou da área, então posso estar deixando algo passar
• Nunca trabalhei numa escala como a do ClickHouse. Logs nesse volume são realmente pesquisáveis? Pelo que sei, o ElasticSearch consulta bem em escala pequena. Por que usar ClickHouse em vez de armazenar arquivos json para logs históricos?
  • Trabalho nessa escala. Resposta curta: sim, é possível. Mas o custo de processamento pode ser inimaginável. Se a estratégia de indexação, ordenação e clusterização estiver ruim, uma busca por “registros que contêm esta string” pode facilmente custar de $1 a $10 por consulta. Pela minha experiência, com dados em grande volume, os princípios mais importantes são “tocar o mínimo possível de dados, o mínimo de vezes possível” e “mover o mínimo possível”. Basta uma serialização/desserialização extra, ou uma passagem a mais por disco ou rede, para o custo explodir. Nesse contexto, no caso do OTel, passar por mais um collector pode ir diretamente contra a eficiência. Mas, em escala de petabytes, o dinheiro economizado com essas pequenas otimizações sobra mesmo depois de pagar o salário de engenheiros para escrever código de serialização complexo
  • Por que usar ClickHouse para logs históricos em vez de arquivos json? Vários motivos. (1) Bancos de logs como o ClickHouse usam compressão por coluna, comprimindo cada campo separadamente, então ocupam muito menos espaço do que arquivos json comuns, inclusive comprimidos. (2) Bancos de logs são muito mais rápidos para consulta. Podem ser mais de 1000 vezes mais rápidos, porque simplesmente não leem os dados desnecessários. Link relacionado. (3) Buscar com grep em 100 PB de arquivos json é inviável na prática. Um banco de logs permite escala horizontal, bastando aumentar nós e armazenamento
  • É uma questão de escala e custo. Nossa empresa também esbarrou no problema do volume de logs. Se jogarmos json no Splunk do jeito que está, isso passa de 6 milhões de dólares por ano. Mas o orçamento aprovado é só de 5% a 10% disso. No texto, diziam que processar logs json exigia 8.000 CPUs; depois da otimização, resolvem com apenas 90 CPUs
  • Há 2 ou 3 anos, o desempenho de busca full text no ClickHouse deixava a desejar. Era rápido, e também lidava com grande volume no nível do ElasticSearch, mas dependendo do caso de uso, se não houvesse indexação prévia, eu sentia que o ES era bem mais rápido para agregações, agrupamentos e FTS
• Extremismo de observabilidade realmente parece uma religião nova. E com muito dinheiro também
  • Se você quiser investigar até anomalias desconhecidas, não existe exatamente uma alternativa melhor
  • O engraçado é a ironia: criam problemas para você sofrer com isso e depois vendem a estratégia de “pague uma assinatura mensal e tudo se resolve”
• O texto não mencionava qual era o período de retenção dos logs. Depois de um certo tempo, fico em dúvida se há mesmo necessidade de manter os dados brutos, em vez de só deixar dados resumidos/agregados
• Sempre que volto para o Postgres depois de usar Clickhouse, sinto um choque cultural. Não consigo aceitar que importar um dump de 20 GB demore vários minutos. Isso não deveria levar só alguns segundos?
  • Toda vez que uso Clickhouse eu sofro demais. Claro, ele tem casos de uso em que é necessário, e o Postgres não substitui tudo, mas o Clickhouse me passa a sensação de ter muitos “pontos de risco”, e, fora objetivos bem específicos e limitados, acho o Postgres melhor em quase tudo
• Quem pressiona pelo uso de wide events nunca fala da explosão de custo de dados de logs. Em comparação com a abordagem tradicional (métricas + traces + logs baseados em amostragem), fica claramente muito mais caro. Com certeza há ganhos, mas a questão do custo sempre fica de fora
  • Uma estrutura de wide events bem projetada pode, na verdade, reduzir o custo de armazenamento em comparação com logs tradicionais. Como cada requisição externa vira um único wide event, ele já contém todas as informações necessárias para depuração e análise posteriores. Veja também A practitioner's guide to wide events
• Tenho curiosidade sobre o truque central de sistemas como Clickhouse ou Dynamo. No fundo, é algo como uma gigantesca tabela hash?
  • Há dois truques em comum entre bancos de dados de grande escala como o Clickhouse. Primeiro, posicionar os dados em disco de forma inteligente para ignorar a maior parte deles e ler só os blocos necessários (armazenamento colunar, árvores do tipo LSM etc.). E comprimir tudo para minimizar também o IO de disco. Segundo, uma sintonia extrema para usar ao máximo todos os recursos (CPU, RAM, disco e rede). Por exemplo, o Clickhouse consegue processar mais de 1 bilhão de linhas por segundo por núcleo de CPU e escalar linearmente conforme o número de núcleos aumenta