Por que o ClickHouse está à frente na guerra da observabilidade

• Ao contrário da experiência de usar grep em sistemas pequenos, logs se tornam os dados mais difíceis de lidar em observabilidade quando serviços e consumidores aumentam, combinando alto volume, formato não estruturado e consultas imprevisíveis
• O ClickHouse começou como um banco de dados para análise de clickstream, mas se encaixa bem nos padrões de uso de logs: alto volume, foco em append, ordem temporal e leituras agregadas
• O armazenamento colunar permite ler apenas as colunas necessárias e, em dados reais de observabilidade, mostra taxa de compressão de 10–14x, em contraste com os 2–3x do Elasticsearch
• Na escala de 1 TB/dia, várias stacks são viáveis, mas, à medida que cresce para 5 TB/dia e 10 TB/dia, Elasticsearch, LGTM e Datadog mudam bastante em arquitetura ou custo, enquanto o ClickHouse escala principalmente com adição de shards
• O ClickHouse exige projeto de schema inicial e lida com a complexidade do mecanismo de consultas, mas seu modelo operacional não se abala muito mesmo quando os dados aumentam em uma ordem de grandeza ou mais

---

Por que logs são difíceis em observabilidade

• Desenvolvedores têm grandes expectativas para busca em logs por causa da experiência de lidar rapidamente com logs em sistemas pequenos usando grep, jq e tail -f
• Esse método funciona bem quando o sistema é pequeno, o volume de logs é baixo e quem consulta foi quem escreveu diretamente as linhas de log
• Quando a escala aumenta, surgem ao mesmo tempo schema drift, explosão de cardinalidade, consumidores entre equipes e demandas por dashboards
• Desenvolvedores não são os únicos que usam logs
  • A equipe de suporte ao cliente precisa encontrar eventos como pagamentos malsucedidos de um usuário específico
  • A equipe de dados pode criar dashboards de negócio em cima de linhas de log que engenheiros de backend podem alterar
  • Quem está de plantão espera que a caixa de busca funcione imediatamente, sem precisar aprender uma nova linguagem de consulta ou padrões de índice
• Tecnicamente, o volume de dados é grande, o formato é irregular e é difícil prever quais consultas serão feitas
• Desenvolvedores querem imediatismo, operações arbitrárias e schema flexível; usuários não técnicos querem dashboards estáveis e uma UI tolerante

A arquitetura do ClickHouse combina com logs

• O ClickHouse foi criado na Yandex para processar consultas analíticas em larga escala sobre dados de clickstream
• Ele não foi projetado especificamente para observabilidade, mas dados de clickstream e de observabilidade têm muitos pontos em comum
  • Grandes volumes de dados
  • Escritas focadas em append
  • Foco em ordem temporal
  • Predominância de leituras agregadas
  • Padrões de uso em que às vezes é necessário encontrar um registro específico
• Também há várias opções de operação
  • Pode ser executado diretamente com Helm chart
  • É possível usar o plugin do ClickHouse no Grafana, a própria UI web ou um frontend criado internamente
  • O exporter do ClickHouse no OpenTelemetry Collector permite inserir dados OTLP diretamente e assumir a gestão inicial do schema
• Foi projetado para varrer bilhões de linhas e ingerir volumes muito grandes de dados
• A linguagem de consulta não é uma nova linguagem dedicada, mas SQL

A diferença criada por armazenamento colunar e compressão

• Pela natureza dos dados, logs são próximos de append-only
  • Linhas de log não são atualizadas
  • Exclusões individuais são raras; quando o período de retenção termina, os dados são excluídos em massa
  • Em geral chegam em ordem temporal, mas não ficam perfeitamente ordenados
• O padrão de leitura muda explosivamente durante incidentes ou análises
  • Depois de dias sem ninguém olhar, durante um incidente as pessoas querem vasculhar bilhões de registros em segundos
  • É comum analisar vários campos em uma janela de tempo estreita, ou agregar com alguns filtros em uma janela de tempo ampla
  • É raro o padrão de buscar uma única linha por um ID específico, como em bancos transacionais
• Bancos orientados a linhas como Elasticsearch, Postgres e MySQL armazenam juntos todos os campos de uma linha de log
  • Mesmo que apenas 3 de 40 campos sejam necessários, o disco acaba lendo os 40
• O ClickHouse armazena cada coluna separadamente
  • Uma consulta que usa apenas timestamp, service e status_code lê somente essas colunas
  • Em dados de observabilidade com dezenas de atributos, mas em que uma consulta específica usa só 3 ou 4 colunas, a diferença no volume de leitura fica grande
• Dados colunares comprimem bem porque os valores dentro da mesma coluna são parecidos entre si
  • A coluna service_name pode ter apenas algumas centenas de strings únicas mesmo em bilhões de linhas
  • Em dados reais de observabilidade, é comum ver taxas de compressão de 10–14x
  • Isso contrasta claramente com os 2–3x do Elasticsearch

Em 1 TB/dia, a maioria das stacks é viável

• Na escala de 1 TB/dia, stacks modernas de observabilidade em geral são utilizáveis; há diferenças, mas ainda não em um nível doloroso

• Elasticsearch

  • Pode ser operado com um cluster Elasticsearch relativamente básico e um buffer Logstash
  • Busca de texto completo é um ponto forte do Elasticsearch e funciona bem nessa escala
  • Em dados mistos, há risco de mapping explosion, então é preciso desativar dynamic mapping ou definir templates com cuidado
  • A política de ILM hot → warm → delete é essencial mesmo nessa escala
  • O custo fica aproximadamente em US$ 6–9 mil por mês

• LGTM

  • O Alloy consolida a coleta em um único daemon
  • O Loki funciona bem quando desenvolvedores são orientados a adicionar labels úteis
  • Mimir e Tempo geralmente cumprem os papéis esperados
  • O custo fica aproximadamente em US$ 3,5–5 mil por mês

• Datadog

  • Em 1 TB/dia, a usabilidade é boa: basta instalar o agente e olhar os dashboards
  • Aparecem questões como pipeline medido, distinção entre logs indexados e ingeridos e custo de cardinalidade de métricas customizadas, mas nessa escala isso é administrável
  • O custo fica aproximadamente em US$ 45–75 mil por mês, com grande variação por negociação, então os números devem ser vistos de forma ampla
  • A lógica de preço do Datadog é algo como economizar um engenheiro dedicado

• ClickHouse

  • Em 1 TB/dia, o ClickHouse não é menos complexo que as outras opções
  • É necessário projetar o schema no início, e a chave ORDER BY é muito importante
  • Com ZSTD e codecs adequados, é possível obter compressão de 10–14x
  • O Altinity Operator cuida da coordenação do keeper, e o conjunto roda com cerca de 7 pods
  • Não há PromQL nativo, e o workflow de métricas passa pelo plugin do Grafana ou por chproxy e adapter
  • O custo fica aproximadamente em US$ 1,5–2,5 mil por mês

Em 5 TB/dia, as diferenças arquiteturais aumentam

• Em 5 TB/dia, a curva de crescimento fica íngreme para a maioria das stacks, e a diferença em relação ao ClickHouse se torna mais visível

• Elasticsearch

  • Kafka se torna praticamente obrigatório
  • Escrever diretamente no Elasticsearch pode derrubar o cluster durante picos de tráfego por causa de bulk reject e backpressure
  • Com target shard de 50 GB, incluindo réplicas, surgem cerca de 200 shards por dia, e o próprio tamanho do cluster state vira um problema
  • Por causa de searchable snapshot e frozen tier, a licença comercial da Elastic se torna quase necessária
  • O custo fica aproximadamente em US$ 40–55 mil por mês antes da licença

• Stack LGTM

  • Passa para o modo de microsserviços, operando mais de 65 pods e três sistemas separados
  • Cada sistema tem seu próprio pipeline de compaction, hash ring e camada de memcached
  • O ring de gossip/memberlist se torna uma preocupação operacional real
  • O rollout dos ingesters exige ajuste de -ingester.autoforget-unhealthy; se feito errado, pode haver perda ou duplicação de dados
  • O custo fica aproximadamente em US$ 22–32 mil por mês

• Datadog

  • Como não é preciso operar servidores diretamente, a complexidade operacional é baixa
  • Em compensação, torna-se necessária uma equipe dedicada de pipeline para reduzir os custos do Datadog
  • Surgem mecanismos como exclusion filters, sampling rules, cardinality caps e allow-list de tags
  • O custo fica aproximadamente em US$ 180–350 mil por mês, dependendo da agressividade da equipe de pipeline
  • A relação passa a ser a de reduzir custos olhando a documentação de cobrança do provedor SaaS

• ClickHouse

  • A maior mudança é a adição de shards
  • O operator, o mecanismo de consultas, a linguagem de consulta e o modelo mental permanecem os mesmos
  • Após adicionar shards, o rebalanceamento é manual, e a maioria das equipes contorna isso com provisionamento antecipado ou weighting em Distributed tables
  • Materialized views para rollups de dashboards deixam de ser apenas desejáveis e se tornam quase essenciais
  • O custo fica aproximadamente em US$ 7–11 mil por mês

Em 10 TB/dia, os modelos operacionais se separam

• 10 TB/dia é uma escala em que muitas soluções começam a ter dificuldade para suportar a carga operacional

• Elasticsearch

  • Passa-se a operar três clusters Elasticsearch separados para logs, métricas e APM, unidos por Cross-Cluster Search
  • O custo de NVMe no hot tier domina a conta
  • Nessa escala, equipes começam a avaliar alternativas seriamente, e muitas migrações recentes para ClickHouse vêm daí
  • O custo fica aproximadamente em US$ 95–140 mil por mês, além da licença comercial
  • Operar Elasticsearch nessa escala exige especialistas de verdade

• LGTM

  • São necessários cerca de 180 ou mais pods, configuração zone-aware, split-and-merge compaction, limites por tenant e shuffle sharding para evitar noisy neighbors
  • Uma equipe dedicada de plataforma de observabilidade com 3 a 5 pessoas se torna praticamente necessária
  • O custo fica aproximadamente em US$ 55–85 mil por mês

• Datadog

  • No sentido de não haver servidores para operar diretamente, continua simples, mas a fatura mensal pode chegar a seis ou sete dígitos
  • A organização provavelmente criará uma equipe de pipeline de pré-processamento para reduzir a fatura
  • Muitas empresas nessa escala usam uma configuração híbrida: Datadog para APM e métricas de alto valor, e logs em uma solução self-hosted
  • O alvo self-hosted é cada vez mais o ClickHouse
  • A estrutura passa a ter, ao mesmo tempo, a simplicidade do Datadog, a complexidade do pipeline e uma segunda stack self-hosted
  • O custo varia muito e pode chegar a mais de US$ 1 milhão por mês

• ClickHouse

  • A visão básica é a mesma da configuração de 1 TB/dia; a diferença é que há mais shards
  • Materialized views para rollups deixam de ser opcionais e passam a ser obrigatórias
  • Erros de projeto de schema cometidos dois anos antes podem aparecer de forma dolorosa nessa escala
  • O rebalanceamento após adicionar shards continua sendo manual
  • A maioria das equipes faz provisionamento antecipado ou usa clickhouse-copier e migração com dual-write
  • Para ingest muito bursty, Kafka se torna útil como buffer, mas não é obrigatório
  • O custo fica aproximadamente em US$ 18–28 mil por mês

Critérios de escolha

• Em 1 TB/dia, praticamente qualquer stack funciona, então vale escolher o que a equipe já conhece
• A pergunta importante não é se funciona hoje, mas se daqui a dois anos, com 5 vezes mais dados, uma equipe 2 vezes maior e o arquiteto inicial fora, ela ainda manterá a mesma forma
• Elasticsearch e LGTM mudam de arquitetura quando a escala aumenta
• Datadog é simples operacionalmente, mas do ponto de vista de custo se transforma em algo que exige uma equipe separada de finanças e pipeline
• O ClickHouse se expande adicionando shards
• O preço disso é aceitar, no início, o trabalho de projetar o schema e a complexidade do mecanismo de consultas
• Ao pagar esse preço, a experiência de desenvolvedores e operadores em geral se mantém mesmo quando os dados crescem em uma ordem de grandeza ou mais

[GN⁺]

Comentários no Lobste.rs

• Uma startup em que trabalhei brevemente em 2019 produziu várias coisas bem impressionantes e, naquela época, me mostrou um pouco do ClickHouse; fiquei realmente muito impressionado
  Até então eu achava que raramente precisaria de algo além do PostgreSQL, mas o ClickHouse me deu vontade de experimentar
  Também já usei ElasticSearch, InfluxDB etc., mas sempre achei meio ruins, provavelmente porque cada um resolveu criar sua própria linguagem de consulta do zero. Já o ClickHouse adotou o SQL familiar e só o estendeu de forma adequada onde era necessário
  Como acontece com produtos bem-sucedidos, no ClickHouse dá para sentir a qualidade da implementação e a consideração pelo usuário, e até os pequenos detalhes vêm bem ajustados por padrão
  Na empresa atual usamos HyperDX; os gráficos de métricas são meio trabalhosos, mas o tracing funciona bem. Eu achava que tracing rapidamente viraria uma ferramenta indispensável e aumentaria muito a produtividade, mas vendo que a adoção não aconteceu tanto quanto eu esperava, talvez não seja um recurso tão revolucionário assim. Ainda assim, é bom ver o ClickHouse se tornando um ator central nessa área e reduzindo a necessidade de lidar com outras coisas

  • Introduzir tracing em uma organização que vinha se virando só com métricas e logs é, pela minha experiência, uma subida bem íngreme
    É preciso muito trabalho de evangelização, reunir casos de uso e fazer o trabalho difícil de mostrar, na prática, que agora dá para fazer coisas que antes não davam e o quanto tarefas difíceis ficaram mais fáceis
    Tecnicamente, a adoção também precisa ser o mais suave possível, mas dependendo da stack e do contexto isso por si só pode exigir um grande esforço, e normalmente esse peso recai sobre a pessoa que está promovendo a adoção
    Não é diferente de uma iniciativa ampla em nível organizacional; ajuda ter credibilidade pessoal e uma ou duas pessoas que sejam verdadeiras fiéis dentro da empresa para espalhar isso
  • Fico curioso se você está falando da linguagem de consulta JSON do ElasticSearch. O ElasticSearch oferece suporte a multiple query languages, incluindo um dialeto de SQL
    Não sei qual é a qualidade desse suporte, mas a única que usei diretamente foi a linguagem de consulta em JSON, e só agora fiquei sabendo das outras
    SQL não é perfeito como linguagem de consulta. É irritante não poder duplicar cláusulas nem escrevê-las em ordem arbitrária, mas, ainda assim, SQL é uma linguagem muito boa

• Minha experiência é parecida com a do autor. A escalabilidade do ClickHouse é surpreendentemente boa e, mesmo operando por conta própria, fica mais perto de simplesmente adicionar mais cores
  O custo inicial de configuração pode ser um pouco maior, mas o schema é praticamente definido pela exportação do OTel, então dá para começar por aí e, quando precisar de mais desempenho nas consultas, ir extraindo colunas e materialized views
  Em troca, você reduz a preocupação com escala, consegue usar todos os seus dados diretamente em análises e até derivar métricas a partir dos traces
  Porém, a outra peça do quebra-cabeça, a visualização, ainda precisa melhorar bastante. O Grafana não é ideal para exibir e analisar traces em comparação com ferramentas como o Honeycomb. Espero que algum dos players existentes resolva isso em breve; talvez seja o HyperDX

• Este artigo começou forte, com uma introdução que parecia convincente, mas quando passou para a parte de analisar várias empresas desandou para um texto em formato de lista com um estilo de LLM de baixo esforço bem evidente
  Ao reler a introdução com mais senso crítico, esses sinais também foram ficando cada vez mais visíveis
  É um padrão que tenho visto com frequência crescente em posts recentes no Lobsters, então quero deixar isto como uma reflexão breve sobre uma observação mais geral, e não como um ataque a um artigo específico
  Pessoalmente, não tenho tanta experiência com ferramentas de observabilidade, então partes do texto foram interessantes para mim, independentemente da forma como foi escrito. Mas não quero cair no erro de confiar em LLMs em assuntos que não conheço e dizer que textos de LLM são falhos apenas nos assuntos que conheço
  Por isso não sei bem se devo confiar factualmente neste artigo ou na maioria dos textos parecidos. Parece claro que o autor transferiu uma parte grande do pensamento para a máquina, mas a ideia inicial em si parecia bastante clara
  Mesmo ao programar, uma ideia clara na minha cabeça só me convence de que há algo fundamental faltando depois que eu realmente escrevo o programa e ele falha em testes de casos de borda ou não passa na checagem de tipos
  Com a escrita é a mesma coisa: se você não constrói diretamente o argumento, monta o todo e considera cuidadosamente as objeções, acho que não entrega mais valor do que a clareza da ideia original
  Talvez seja isso que as pessoas que defendem escrever código apenas salvando prompts para LLMs futuras queiram dizer
  Mas, se programação ou escrita forem inteiramente assim, você abriu mão não só do pensamento, mas também de rigor, diligência e respeito
  Não sei bem o que o Lobsters deveria fazer a respeito. A tag vibecoding já parece uma solução sobrecarregada. Ainda assim, talvez uma tag cheiro de LLM ajudasse como sinal de alerta para falta de rigor

  • Eu também não queria transformar isso em um comentário de primeiro nível, mas, ao entrar no texto, vi que era simplesmente chavão de LLM, então senti que o tempo gasto lendo o começo foi meio desperdiçado
  • Para alguém que já usou um pouco ferramentas de observabilidade, o texto me pareceu bem claro e razoável
    O ponto central é que cada produto escala de uma forma diferente, e ele mostra com gráficos e explicações concretas o que acontece em cada escala
    Se houve algum trecho em que você sentiu uma desistência óbvia de pensar, fiquei curioso para ver exemplos
  • Matthew é, no mínimo, alguém bastante versado em observabilidade. Foi tech lead na Braintree e hoje é Principal na SYBO, conhecida por Subway Surfers
    As partes com palavrões também deixam transparecer um pouco da voz dele
    Ao passar no GPTZero, aparece 71% de probabilidade de LLM e 28% misto. Mas, por causa do limite de caracteres, tive que cortar a introdução, que era a parte que mais parecia humana
    Entendo a rejeição, mas parece mais um texto que foi de fato revisado e iterado, só que sem filtrar as expressões com cara de LLM nem otimizar o tom. Hoje em dia, só evitar em dash já não basta para escapar do cheiro

• Para quem tem experiência com Honeycomb, fico curioso sobre como ele se encaixa nesse contexto
  Pelo que sei, o Honeycomb também usa um formato de armazenamento colunar e depende bastante de compressão e bucketing para pular grandes volumes de dados na leitura. Pelo que entendo, não é uma abordagem baseada em índice invertido como Elastic ou Datadog, e também sei que o Datadog roda Elastic internamente

  • Lembro que, alguns anos atrás, Charity Majors, cofundadora do Honeycomb, disse no Twitter que, se o ClickHouse existisse quando começaram a empresa, provavelmente teriam simplesmente usado ele
    Ainda assim, não tenho certeza de quanto os dois sistemas realmente se sobrepõem conceitualmente. Seria interessante saber se o domínio do problema naturalmente levou a abordagens parecidas; pessoalmente, eu esperaria que sim

• Talvez algumas pessoas fiquem incomodadas, mas achei o uso de certas palavras tão dispersivo que simplesmente fiz um localizar e substituir por palavras que não me incomodassem, e o texto ficou muito melhor
  Não vou dizer quais palavras eram, mas são expressões usadas de forma cada vez mais imprecisa e que me irritam. Foi bom conseguir ler o texto com tranquilidade só com uma busca e substituição simples