ClickStack – alternativa open source ao Datadog feita com ClickHouse e HyperDX

• ClickStack é uma plataforma de observabilidade open source baseada em ClickHouse e HyperDX, que integra logs, métricas, traces e session replay em um só lugar
• Oferece busca e visualização de logs e traces de forma simples e rápida em clusters ClickHouse, com suporte a qualquer esquema sem trabalho adicional
• Fornece busca intuitiva, alertas baseados em eventos e dashboards, permitindo que engenheiros identifiquem e respondam rapidamente a problemas
• Suporta o padrão OpenTelemetry nativamente e oferece integração de SDKs para diversas linguagens e plataformas
• Em comparação com soluções comerciais existentes, é mais barato e simples de configurar, além de permitir que todo o fluxo seja feito em uma única plataforma sem precisar alternar entre várias ferramentas de observabilidade

Principais recursos

• Permite fazer análise de correlação e busca de logs, métricas, session replay e traces em um só lugar
• Aproveita os esquemas já existentes do ClickHouse, com uma estrutura independente de esquema
• Adequado para grandes volumes de dados graças à alta velocidade de busca e à visualização otimizada
• Suporta tanto busca full-text quanto por atributos, e o uso de SQL é opcional
• Possibilita analisar tendências de mudanças em eventos e configurar alertas com facilidade, além de criar dashboards
• Suporte a consultas nativas de strings JSON
• Permite verificar eventos mais recentes com recursos de tail em tempo real para logs e traces
• Integração com OpenTelemetry e suporte a ambientes de APM (monitoramento de desempenho)

Implantação e como começar

• O pacote ClickStack pode ser implantado de forma integrada com ClickHouse, HyperDX, OpenTelemetry Collector e MongoDB
• A interface do HyperDX pode ser acessada pelo navegador
• Também pode ser integrado ao ambiente ClickHouse Cloud e é fácil de implantar em vários ambientes

Instrumentação e integração de aplicações

Para coletar dados de logs, métricas, traces e session replay com o HyperDX, a aplicação precisa enviar os dados de telemetria para o HyperDX

• Opções de SDK e integração: há SDKs para várias linguagens e ambientes, como navegador, Node.js e Python, permitindo integração fácil
• Suporte ao padrão OpenTelemetry: compatível com várias linguagens e runtimes, como Kubernetes, JavaScript, Python, Java, Go, Ruby, PHP, .NET, Elixir e Rust
• O coletor OpenTelemetry pode ser acessado por padrão no endereço http://localhost:4318

Como contribuir

• Contribuições da comunidade são bem-vindas de várias formas, como envio de PRs, registro de issues, melhoria da documentação, votação em issues abertas e compartilhamento de novos casos de uso

Motivação e filosofia de desenvolvimento

O objetivo da equipe do HyperDX é permitir que todos os engenheiros usem a telemetria do ambiente de produção para resolver problemas rapidamente

Principais problemas existentes:

• Ferramentas de observabilidade para produção são caras e têm custos crescentes conforme os dados escalam
• A configuração e o uso são complexos, exigindo SREs e especialistas
• Logs, session replay, APM e outros recursos ficam separados, tornando a correlação de informações trabalhosa

Para superar essas limitações, ClickStack e HyperDX são oferecidos como open source

• A HyperDX foi adquirida pela ClickHouse

[GN⁺]

Comentários do Hacker News

• Curiosidade sobre por que foi criado um frontend customizado em vez de usar o Grafana, que já existe

• Compartilhamento de que, com o preço do DataDog sendo alto, o HyperDX parece realmente atraente; o autor comenta que o LogLayer(https://loglayer.dev), que ele mantém, é um logger estruturado para TypeScript com suporte para enviar logs para vários tipos de loggers e serviços de nuvem (como DataDog), e que está desenvolvendo uma integração para o HyperDX com lançamento previsto em breve; também expressa o desejo de adicionar um link de documentação sobre como integrar HyperDX e LogLayer na seção "integrations" do seu site, além de compartilhar o PR relacionado(https://github.com/hyperdxio/hyperdx-js/pull/184)

  • Pedido para adicionar também a capacidade de enviar logs para o VictoriaLogs, junto com a sugestão e o link para a documentação de vários protocolos de ingestão de dados(https://docs.victoriametrics.com/victorialogs/data-ingestion/)
  • Feedback positivo dizendo que a integração entre LogLayer e HyperDX parece muito boa e que vai conferir pessoalmente

• Relato de uso do HyperDX em produção real, com grande satisfação com a integração com o ClickHouse e a eficiência de custos; pergunta se é necessário se preparar para migrar do HyperDX para o ClickStack

  • Saudação dizendo que sempre ficam felizes com feedback de usuários em produção; explicação de que o HyperDX não vai desaparecer de forma alguma e continua sendo destacado nas páginas de marketing como parte central da stack; informam que pretendem focar mais no HyperDX v2 e no padrão ClickStack daqui para frente, mas que o próprio HyperDX continuará priorizando a experiência do usuário final; acrescentam que o objetivo do ClickStack é aproveitar mais a flexibilidade e a performance do core baseado em ClickHouse; compartilham que a engenharia está focada em permitir uma transição suave tanto no open source quanto na nuvem; por fim, mencionam de passagem que responderam com atraso por causa de uma conexão Wi‑Fi instável recente

• Compartilhamento de que traces e logging do OTel são bons, mas a funcionalidade de métricas do OTel parece excessivamente complexa; pergunta se o ClickStack consegue ingerir dados statsd (especialmente com as extensões de tagging do Datadog), se existe tagging de serviço unificada e ligação entre traces/logs/métricas, se há links entre dados relacionados na UI, por que o SDK de Elixir usa a biblioteca hyperdx, e se a funcionalidade de Notebooks está no roadmap

  • Resposta dizendo que são ótimas perguntas, concordando com a frustração de que o padrão de métricas do OTel acabou ficando muito variado; explicam que o OTel collector pode coletar diversos formatos como statsd e escrever diretamente no ClickHouse, então é possível usar statsd(link da documentação do statsdreceiver); mencionam que logs e traces podem ser correlacionados por trace/span id e resource attributes, e que em workloads de k8s já existe correlação até com métricas; dizem que exemplars para correlação de métricas ainda não são suportados, mas estão nos planos; explicam que o SDK de Elixir foi uma escolha para dar suporte ao ambiente dos usuários, que a biblioteca evoluiu de forma independente e que estão considerando migrar para o SDK oficial do OTel no futuro; compartilham como exemplo que integraram rapidamente o OTel para Deno por conta própria; dizem que Notebooks deve ser liberado em breve em estado experimental e habilitar vários workflows, e manifestam interesse em mais feedback dos usuários
  • Pergunta sobre por que as métricas do OTel parecem complexas, junto com a observação de que uma vantagem é não precisar substituir facilmente pipelines de métricas já existentes, como statsd ou o agente do DD

• Opinião de que, assim como o Signoz, por ser baseado em ClickHouse e oferecer versões open source e cloud, o HyperDX parece semelhante; também compartilha a observação de que a UI é parecida e pergunta quais são as diferenças

  • Comentário adicional dizendo que gostaria de ouvir uma comparação mais direta com o Signoz

• Compartilhamento de que está procurando uma nova solução de logging para substituir o Kibana e, como teve uma boa experiência com ClickHouse, se interessou pela UI do HyperDX; explica que hoje seu pipeline de logs é Vector sobre Kubernetes, que o Vector oferece suporte beta a sink OTel, e que está pensando qual é a melhor forma de enviar logs quando os dados estão em JSON; enfatiza que o ambiente lida com tráfego de altíssimo volume, na casa de terabytes

  • Resposta dizendo que o ClickHouse é especializado em grande escala e alto throughput, e citando casos de uso de gravação direta no ClickHouse a partir do Vector (por exemplo, uma apresentação da Anthropic); sugerem testar na prática e deixar um feedback para que possam ajudar
  • Opinião de que padronizar o formato de envio de dados em otel é uma boa escolha estratégica para o futuro, e que isso parece reduzir duas preocupações de uma vez

• Pergunta sobre as diferenças entre Signoz e HyperDX (ou ClickHouse), observando que ambos vieram do YC e usam ClickHouse

  • Resposta de que, como mencionado abaixo, o maior diferencial é ser um produto 1st-party desenvolvido oficialmente pela equipe do ClickHouse; funciona com flexibilidade em quase todas as instâncias do ClickHouse e também suporta schemas customizados, o que é importante para tuning de alta performance ou certos ambientes de grande escala (por exemplo, Anthropic); há também a vantagem de adoção muito fácil para quem já tem dados no ClickHouse; não impõe OTel de forma obrigatória e oferece suporte nativo também para Vector, Cribl, S3, scripts customizados etc.; também há recursos de telemetry wrangling (event deltas de alta cardinalidade, clustering automático de logs/spans com ML etc.) que facilitam a exploração dos dados; com a funcionalidade de session replay, oferece integração ampla, do clique até métricas de infraestrutura; internamente, é operado no monitoramento do ClickHouse Cloud em escala de mais de 100PB, com flexibilidade para entender ponta a ponta até problemas específicos de usuários; filosoficamente, compartilham a crença de que, em vez de separar os tradicionais "3 pilares" (logs/métricas/traces), faz mais sentido criar uma ferramenta unificada e centralizada de exploração de pistas para debugging no mundo real
  • Esclarecimento de que "You" significa ClickHouse

• Compartilhamento de uma experiência confusa na UX após o cadastro: o widget "Was this search result helpful?" aparecia na UI antes mesmo de qualquer busca; ao clicar em Hide, surgia um botão de feedback e, ao clicar nele novamente, o estado voltava ao original, caracterizando um bug; também avalia que a fonte é monoespaçada no geral e pequena, e que o branco forte e o verde claro não harmonizam bem com o fundo escuro; diz que mesmo trocando para a fonte do sistema a melhora não foi grande e recomenda um estilo de UI mais tradicional; esse design difícil de ler o faz hesitar em usar o produto

• Pergunta se o ClickHouse é o único elemento stateful dessa stack; demonstra interesse na compatibilidade com o Rotel(https://github.com/streamfold/rotel), um collector OTEL em Rust; menciona que o Datadog tem um substituto próprio para o OTEL collector com performance superior

  • Resposta dizendo que o Rotel parece adequado para integração OTel em ambientes leves como lambda; como o endpoint de ingestão OTel do HyperDX já é padrão, acreditam que deve ser compatível imediatamente; mencionam também que já conversaram com os desenvolvedores do Rotel e destacam que o recente suporte ao ClickHouse deixou a história completa ainda mais sólida