ClickStack – alternativa open source a Datadog creada con ClickHouse y HyperDX

• ClickStack es una plataforma de observabilidad open source basada en ClickHouse y HyperDX, que integra en un solo lugar logs, métricas, trazas y session replay
• Ofrece búsqueda y visualización de logs y trazas de forma fácil y rápida sobre clústeres de ClickHouse, y puede aplicarse a cualquier esquema sin trabajo adicional
• Proporciona búsqueda intuitiva, alertas basadas en eventos y funciones de dashboards para que los ingenieros puedan identificar y responder rápidamente a los problemas
• Soporta de forma nativa el estándar OpenTelemetry y ofrece integración de SDK para diversos lenguajes y plataformas
• Frente a las soluciones comerciales existentes, es más económico y fácil de configurar, y permite realizar todo el flujo en una sola plataforma sin tener que saltar entre varias herramientas de observabilidad

Funciones principales

• Permite realizar en un solo lugar el análisis de correlación y la búsqueda de logs, métricas, session replay y trazas
• Aprovecha directamente los esquemas existentes de ClickHouse y tiene una arquitectura independiente del esquema
• Gracias a su rápida velocidad de búsqueda y a la optimización de visualización, también es adecuado para grandes volúmenes de datos
• Soporta tanto búsqueda de texto completo como por atributos, y el uso de SQL es opcional
• Permite analizar tendencias de cambios en eventos y configurar alertas fácilmente, además de crear dashboards
• Soporta consultas nativas de cadenas JSON
• Permite revisar los eventos más recientes con funciones de tail en tiempo real para logs y trazas
• Integración con OpenTelemetry y soporte para entornos de APM (monitoreo de rendimiento)

Despliegue y cómo empezar

• El paquete de ClickStack puede desplegarse de forma integrada incluyendo ClickHouse, HyperDX, OpenTelemetry Collector y MongoDB
• Se puede acceder a la interfaz de HyperDX desde el navegador
• También puede integrarse con entornos de ClickHouse Cloud y desplegarse fácilmente en distintos entornos

Instrumentación e integración de aplicaciones

Para recopilar datos de logs, métricas, trazas y session replay con HyperDX, la aplicación debe enviar los datos de telemetría a HyperDX

• Opciones de SDK e integración: ofrece SDK para navegadores, Node.js, Python y otros lenguajes/entornos, por lo que se puede integrar fácilmente
• Soporte del estándar OpenTelemetry: es compatible con Kubernetes, JavaScript, Python, Java, Go, Ruby, PHP, .NET, Elixir, Rust y muchos otros lenguajes y runtimes
• El recolector de OpenTelemetry puede conectarse por defecto en http://localhost:4318

Cómo contribuir

• Se agradecen contribuciones de la comunidad de muchas formas, como enviar PR, registrar issues, mejorar la documentación, votar por issues abiertos o aportar nuevos casos de uso

Motivación y filosofía de desarrollo

El objetivo del equipo de HyperDX es permitir que todos los ingenieros usen la telemetría del entorno de producción para resolver problemas rápidamente

Principales problemas existentes:

• Las herramientas de observabilidad para producción son costosas y los gastos aumentan a medida que escalan los datos
• La dificultad de configuración y uso es alta, por lo que se necesitan SRE y especialistas
• Funciones como logs, session replay y APM están separadas entre sí, lo que vuelve engorrosa la correlación de información

Para superar estas limitaciones, ClickStack y HyperDX se ofrecen como open source

• HyperDX fue adquirida por ClickHouse

[GN⁺]

Comentarios de Hacker News

• Da curiosidad por qué hicieron un frontend personalizado en lugar de usar Grafana, que ya existe.

• Comparten que DataDog es caro, así que HyperDX se siente realmente atractivo. Mencionan que LogLayer(https://loglayer.dev), que ellos operan, es un logger estructurado para TypeScript con soporte para enviar logs a varios tipos de loggers y servicios en la nube (como DataDog), y comentan que están desarrollando una integración para HyperDX que planean lanzar pronto. También expresan que les gustaría agregar un enlace a la documentación sobre cómo integrar HyperDX con LogLayer en la sección "integrations" de su sitio, y comparten el PR relacionado(https://github.com/hyperdxio/hyperdx-js/pull/184).

  • Piden que también se agregue la capacidad de enviar logs a VictoriaLogs, y lo proponen junto con el enlace a la documentación de varios protocolos de ingesta de datos(https://docs.victoriametrics.com/victorialogs/data-ingestion/).
  • Dan una respuesta positiva diciendo que la integración entre LogLayer y HyperDX se ve genial y que la revisarán personalmente.

• Están usando HyperDX en producción real y están muy satisfechos con la integración con ClickHouse y la eficiencia de costos. Preguntan si necesitan prepararse para migrar de HyperDX a ClickStack.

  • Responden con gusto diciendo que siempre les entusiasma mucho recibir feedback de usuarios en producción. Explican que HyperDX no va a desaparecer en absoluto y que incluso en la página de marketing sigue destacado como parte central del stack. Indican que en adelante planean enfocarse más en HyperDX v2 y en el patrón de ClickStack, pero que HyperDX seguirá centrándose en la experiencia del usuario final. Añaden que el objetivo de ClickStack es aprovechar mucho más la flexibilidad y el rendimiento del core basado en ClickHouse, y comparten que están enfocados en ingeniería para que el cambio sea fluido tanto en open source como en cloud. Como nota aparte, mencionan que últimamente su wifi ha estado inestable y por eso respondieron tarde.

• Comparten que los traces y logs de Otel están bien, pero sienten que la funcionalidad de métricas de Otel está diseñada de forma demasiado compleja. Preguntan si ClickStack puede ingerir datos de statsd (especialmente con las extensiones de etiquetado de Datadog), si existe etiquetado de servicio unificado y vinculación entre traces/logs/métricas, si hay enlaces entre datos relacionados en la UI, por qué el SDK de Elixir usa la librería hyperdx, y si la función de Notebooks está en la hoja de ruta.

  • Responden que son buenas preguntas y coinciden en que una razón por la que el estándar de métricas de OTel se volvió tan amplio también lo hace frustrante. Indican que, como el OTel collector puede recolectar muchos formatos distintos como statsd y escribir directamente en ClickHouse, sí es posible usar statsd(documentación de statsdreceiver). Mencionan que logs y traces pueden vincularse mediante trace/span id y resource attributes, y que en workloads de k8s ya ofrecen correlación hasta métricas. Aclaran que todavía no soportan exemplars para correlación de métricas, pero está en los planes. Explican que el SDK de Elixir se eligió para dar soporte según el entorno de los usuarios, que la librería ha evolucionado de forma independiente y que están evaluando si migrar a un SDK oficial de OTel en el futuro. Comparten también un caso en el que incorporaron rápidamente una integración de OTel para Deno. Dicen que Notebooks se publicará pronto en estado experimental para habilitar varios flujos de trabajo, y expresan interés en recibir más feedback de usuarios.
  • Preguntan por qué sienten que las métricas de Otel son complejas y señalan como ventaja que no hace falta reemplazar fácilmente pipelines de métricas existentes como statsd o el agente de DD.

• Opinan que HyperDX parece similar a Signoz porque también está basado en ClickHouse y ofrece versiones open source y cloud, y sienten curiosidad por las diferencias. También observan que la UI se parece.

  • Añaden que les gustaría escuchar una comparación más directa con Signoz.

• Están explorando una nueva solución de logging para reemplazar Kibana y, como su experiencia con ClickHouse ha sido buena, les interesa la UI de HyperDX. Comparten que su pipeline actual de logs corre sobre Vector en Kubernetes y que Vector ya soporta un sink de OTel (beta), así que, dado que sus datos están en JSON, están pensando cuál es la mejor forma de enviar los logs. Enfatizan que manejan tráfico de gran volumen, a escala de TB, y de alto rendimiento.

  • Responden que ClickHouse está especializado en manejar gran volumen y alto throughput, y mencionan casos donde se usa escritura directa a ClickHouse desde Vector (por ejemplo, una presentación de Anthropic). Proponen que, si lo prueban y luego comparten su opinión, con gusto los ayudarán.
  • Opinan que estandarizar el formato de envío de datos en otel es una buena decisión estratégica a futuro, y comparten que sienten que eso reduce dos preocupaciones.

• Preguntan cuáles son las diferencias entre Signoz y HyperDX (o ClickHouse), observando que ambos salieron de YC y usan ClickHouse.

  • Responden que, como se menciona más abajo, la mayor diferencia es que este es un producto oficial desarrollado por el equipo de ClickHouse. Funciona de forma flexible en casi todas las instancias de ClickHouse y también soporta esquemas personalizados, lo cual es importante para tuning de alto rendimiento o para ciertos entornos de gran escala (por ejemplo, Anthropic). Destacan que, si ya se tienen datos en ClickHouse, adoptarlo es muy sencillo. Añaden que no obliga a usar otel, sino que también soporta de forma nativa Vector, Cribl, S3 y scripts personalizados. También cuenta con funciones de telemetry wrangling (como deltas de eventos de alta cardinalidad, clustering automático de logs/spans basado en ML, etc.), lo que facilita la exploración de datos. Dicen que también ofrece session replay para una integración amplia, desde clics hasta métricas de infraestructura. Mencionan que internamente lo operan en el monitoreo de ClickHouse Cloud a escala de 100PB+ y con la flexibilidad suficiente para rastrear de punta a punta problemas de usuarios específicos. Filosóficamente, comparten que creen que, en lugar de separar los "3 pilares" (logs/métricas/traces), es más adecuado para el debugging real construir una herramienta unificada y centralizada para explorar pistas.
  • Aclaran que “You” se refiere a ClickHouse.

• Comparten que, después de registrarse, el widget "Was this search result helpful?" aparecía en la UI incluso antes de hacer una búsqueda, lo que hizo confusa la UX. También encontraron un bug donde al presionar Hide aparecía el botón de feedback y, al volver a presionarlo, todo regresaba al estado original. Evalúan además que la fuente es monoespaciada en toda la interfaz y el texto es pequeño, y que el blanco fuerte y el verde brillante no combinan bien con el fondo oscuro. Comentan que incluso cambiando a una fuente del sistema no mejora mucho, por lo que recomiendan un estilo de UI más tradicional. Dan como feedback que el diseño difícil de leer les hace dudar en usarlo.

• Preguntan si ClickHouse es el único componente stateful de este stack y muestran interés en la compatibilidad con Rotel(https://github.com/streamfold/rotel), un collector OTEL en Rust. Mencionan que Datadog tiene un reemplazo del collector de OTEL desarrollado internamente con mejor rendimiento.

  • Responden que consideran que Rotel encaja bien para integrar OTel en entornos ligeros como lambda, y que como el endpoint de ingesta OTel de HyperDX ya es estándar, probablemente sería compatible de inmediato. Añaden que también han estado en contacto con los desarrolladores de Rotel y destacan que el soporte para ClickHouse se agregó recientemente, lo que fortalece bastante toda la historia.