Reemplazar OTel y escalar una plataforma de observabilidad con wide events

• LogHouse, el sistema interno de ClickHouse, creció en un año desde 19 PiB y cerca de 40 billones de filas hasta almacenar más de 100 PB de logs sin comprimir y casi 500 billones de filas
• La ruta de ingesta existente centrada en OpenTelemetry alternaba entre JSON, el formato OTel y el formato nativo de ClickHouse, lo que elevaba el costo de CPU y el riesgo de pérdida de logs
• Con SysEx (System Tables Exporter), ClickHouse copia las tablas de sistema a LogHouse byte por byte y procesa 37 M logs/s con 70 núcleos de CPU
• OTel sigue siendo útil para logs de fallas basados en stdout·stderr y como formato estándar neutral frente a proveedores, pero la telemetría central de ClickHouse se está moviendo hacia SysEx y wide events
• Tras adoptar HyperDX, ClickHouse combina una UI nativa, búsqueda con sintaxis Lucene, análisis SQL y exploración independiente del esquema, reemplazando parte del rol de la UI personalizada basada en Grafana

---

LogHouse creció hasta 100 PB y 500 billones de filas

• LogHouse es la plataforma interna de logging creada para monitorear ClickHouse Cloud, y antes también servía para reemplazar los crecientes costos de Datadog
• Hace un año procesaba 19 PiB de datos sin comprimir y 37 billones de filas; hoy almacena más de 100 PB de datos sin comprimir y casi 500 billones de filas
• La composición principal de los datos almacenados actualmente es la siguiente
  • SysEx: 93.6 PB, 431 billones de filas
  • OTel: 14.5 PB, 16.7 billones de filas
• Antes toda la telemetría pasaba por OpenTelemetry, pero ahora la mayor parte de los datos llega desde SysEx, un exporter especializado creado por ClickHouse

Límites del pipeline de OpenTelemetry

• OpenTelemetry era adecuado como pipeline estándar inicial para enviar a ClickHouse todos los logs de Pods en entornos Kubernetes
• Los logs de texto en stdout de ClickHouse no eran suficientes para el análisis operativo; para el análisis real se necesitaban logs estructurados, métricas, detalles de ejecución, I/O de disco y estado de tareas en segundo plano desde las tablas system
• La ruta de logs OTel existente pasaba por varias etapas de transformación
  • La instancia de ClickHouse del cliente escribía logs en stdout como JSON
  • kubelet guardaba los logs en /var/log/…
  • El collector de OTel leía los logs desde disco, parseaba el JSON y lo convertía a una representación en memoria
  • El collector lo volvía a convertir al formato de logs de OTel
  • El cliente Go de ClickHouse lo reconvertía al formato nativo de ClickHouse y lo insertaba en LogHouse
• El pipeline OTel real incluía edge collector, transporte OTLP, gateway collector y procesamiento adicional, y cada etapa aumentaba el overhead, la latencia y la complejidad
• A medida que creció la escala, se hicieron evidentes dos problemas
  • Los tipos nativos de ClickHouse pasaban por JSON y el formato OTel, desperdiciando CPU y reduciendo la fidelidad de los datos
  • El agente OTel en los nodos Kubernetes chocaba con límites de CPU y memoria, y descartaba líneas de log durante picos de tráfico
• Se estima que procesar 20 M rows/s sin pérdidas con OTel requeriría alrededor de 8,000 núcleos de CPU en el conjunto de agentes y collectors

SysEx: un recolector especializado en transferencia ClickHouse-to-ClickHouse

• ClickHouse creó System Tables Exporter (SysEx) para transferir datos directamente desde las tablas de sistema de ClickHouse en los Pods de clientes hacia tablas de LogHouse
• SysEx realiza una copia byte por byte entre origen y destino, preservando los tipos nativos de ClickHouse y eliminando transformaciones intermedias
• Gracias a esta estructura, los ingenieros pueden convertir fácilmente las consultas que usaban para depurar live instances en consultas sobre datos históricos de toda la flota en LogHouse
  • El esquema de las tablas es el mismo, y solo se agregan columnas de enriquecimiento como nombre del Pod y versión de ClickHouse
• La arquitectura está compuesta por un pool de scrapers SysEx y un hash ring
  • El hash ring asigna los Pods de clientes a una réplica específica de scraper para distribuir la carga
  • El scraper ejecuta SELECT sobre la system table del Pod de origen y transmite los datos a LogHouse por streaming
  • El scraper coordina la transferencia de bytes entre origen y destino sin deserialización
• Para evitar perder flushes de buffers en las tablas de sistema, SysEx usa ventanas temporales deslizantes y normalmente consulta con 5 minutos de retraso respecto del tiempo real
• Como el comportamiento predeterminado del cliente Go de ClickHouse convierte los datos a tipos nativos de Go, ClickHouse contribuyó a clickhouse-go una función para omitir el marshalling interno
• SysEx usa un modelo pull, por lo que no requiere buffering pesado como OTel; si LogHouse no está disponible temporalmente o si la telemetría de origen aumenta de golpe, puede volver a scrapear ventanas pasadas para hacer backfill

Esquemas dinámicos y snapshots de estado

• SysEx requiere que los esquemas de origen y destino coincidan, pero los esquemas de las system tables de ClickHouse cambian con frecuencia al agregarse nuevas métricas y columnas
• Para manejarlo, cuando SysEx encuentra una system table, inspecciona su esquema, calcula su hash y verifica si en LogHouse existe una tabla con el mismo esquema
  • Si existe, inserta en la tabla existente
  • Si no existe, crea una nueva versión de esquema como text_log_6
• En el momento de la consulta, usa el motor de tablas Merge de ClickHouse para agrupar varias iteraciones de esquemas en una sola vista lógica
• El motor de tablas Merge permite seleccionar solo columnas compatibles o limitar la consulta a tablas que tengan las columnas solicitadas, habilitando consultas pese a cambios de esquema sin administración manual
• ClickHouse también captura periódicamente como snapshots system tables en memoria como system.processes y las almacena en LogHouse
• Estos snapshots se usan para analizar, con referencia histórica, el estado del clúster, los esquemas de tablas y la configuración del clúster en un momento específico

Análisis de toda la flota y cifras de eficiencia

• Gracias a SysEx, las consultas de Advanced Dashboard que los clientes usan para monitorear instancias individuales de ClickHouse pueden ejecutarse simultáneamente sobre toda la flota de instancias de clientes
• En el análisis de releases, se ejecutan consultas de diagnóstico antes y después del despliegue para verificar en tiempo real, a escala de flota, patrones de rendimiento de consultas, tendencias de uso de recursos y cambios en tasas de error
• El dashboard de soporte correlaciona, en la misma interfaz, consultas de Advanced Dashboard con logs de red, eventos de Kubernetes y eventos del data plane y del control plane
• La comparación de eficiencia según LogHouse es la siguiente
  • OTel Collectors: transmiten 2 M logs/s con más de 800 núcleos de CPU
  • LogHouse Scrapers (SysEx): transmiten 37 M logs/s con 70 núcleos de CPU
• SysEx multiplicó por 20 el volumen de eventos en la fuente de datos más importante, redujo la huella de CPU a menos del 10% de la anterior y evitó descartar eventos en el edge

Áreas donde OpenTelemetry sigue siendo necesario

• OpenTelemetry ofrece un formato neutral frente a proveedores y estandarizado, además de una buena experiencia de onboarding para nuevos usuarios, por lo que sigue siendo la opción predeterminada en ClickStack
• SysEx está fuertemente acoplado al interior de ClickHouse y usa una estructura pull que consulta live system tables; si un servicio está en crash loop o caído, no puede scrapear datos
• OpenTelemetry captura pasivamente los logs emitidos a stdout y stderr, por lo que puede recolectar logs durante una falla aunque el servicio no esté completamente healthy
• ClickHouse sigue ejecutando OpenTelemetry en todos los servicios de ClickHouse, pero cambió el alcance de la recolección
  • Antes ingería todo, incluso logs de nivel trace
  • Ahora solo recolecta nivel info o superior
• Después de este cambio, el collector y el gateway de OTel operan con muchos menos recursos y se mantienen como un pipeline más pequeño del orden de 2 M líneas de log/s mencionado antes

HyperDX y experiencia de exploración nativa de ClickHouse

• La primera UI de LogHouse era una experiencia de observabilidad personalizada construida sobre Grafana, pero con el crecimiento de SysEx y la telemetría de columnas anchas hizo falta una UI más profundamente integrada con ClickHouse
• HyperDX es una UI nativa de ClickHouse que permite explorar logs y traces, hacer correlación y análisis a gran escala
• Permite consultar con sintaxis Lucene, simplificando la exploración de datos, y se puede seguir usando SQL para análisis complejos de eventos
• El enfoque independiente del esquema de HyperDX v2.0 no exige una única estructura fija de tabla de logs
  • Maneja el formato de datos estandarizado pero cambiante del pipeline OpenTelemetry
  • También maneja tablas especializadas de columnas anchas de SysEx y otros exporters personalizados, sin conocimiento previo del esquema ni patrones grok complejos
• Grafana también sigue teniendo un rol en LogHouse
  • La app interna basada en Grafana permite especificar un namespace para saber dónde están los datos de cada servicio y enrutar consultas a la instancia de ClickHouse adecuada
  • Los dashboards y alertas existentes basados en métricas de Prometheus siguen en Grafana
  • Las métricas de alto nivel como kube_state_metrics, aunque no son ideales para investigación profunda, sí son adecuadas para alerting

Wide events y observabilidad de alta cardinalidad

• La adopción de SysEx impulsó el cambio desde una ingesta centrada en logs de stdout hacia un modelo centrado en wide events basados en system tables y datos de alta cardinalidad
• ClickHouse lo llama una combinación de LogHouse y ClickStack, no Observability 2.0
• En lugar del modelo tradicional de tres pilares, este modelo almacena telemetría de alta cardinalidad de múltiples fuentes en un warehouse central
• Cada row incluye contexto enriquecido como query identifier, nombre del Pod, metadatos de versión y detalles de red, sin preagregar ni descartar dimensiones para ajustarse a las limitaciones de un metric store
• En vez de resumir en el momento de la ingesta, almacena los datos originales tal como llegan y difiere la agregación hasta el query time
• La diferencia con Prometheus es que almacena todos los data points
  • Campos como insertDuration no se preagregan, sino que se preserva cada valor con sus dimensiones relacionadas
  • Si Prometheus almacenara timeseries para todas las combinaciones de labels, habría una explosión de cardinalidad
  • La preagregación con histogramas controla el uso de recursos, pero dificulta preguntar de qué instance, table o time window provino un spike específico de inserts
• Elasticsearch también fomentó los wide events y estructuras de documentos flexibles, pero el diseño columnar de ClickHouse permite almacenar y consultar de manera eficiente datos de eventos de alta cardinalidad y alto volumen a gran escala

Herramientas de data science y análisis SQL

• Se pueden visualizar múltiples características desde un solo wide event y volver al raw log desde un punto específico de un gráfico
• ClickHouse ofrece integraciones de visualización de datos y clientes de lenguaje, por lo que se pueden usar herramientas basadas en SQL como Plotly, Jupyter notebook, Hex, Bokeh y Evidence
• La búsqueda con sintaxis Lucene de HyperDX es adecuada para consultas y filtros rápidos, pero las preguntas complejas requieren SQL
• ClickHouse SQL puede expresar joins, operaciones basadas en tiempo y transformaciones
  • El ejemplo empareja eventos Killing y Created del mismo container en un stream de eventos de Kubernetes con ASOF JOIN para calcular el tiempo entre terminación y reinicio
  • La consulta de ejemplo procesó 17.78 M rows y 581.49 MB, tardó 0.099 segundos y tuvo un peak memory de 272.88 MiB
• Las métricas necesarias pueden derivarse en query time desde el warehouse de wide events, sin crear y desplegar previamente componentes específicos

Fuentes de datos agregadas a LogHouse

• LogHouse agregó más data sinks basados en wide events a pedido de los equipos de ingeniería y soporte
• kubenetmon: herramienta open source para monitoreo de networking en Kubernetes que usa Linux conntrack para capturar datos de conexiones L3/L4 y conteos de bytes y paquetes
  • Proporciona forensics, atribución de workload y Pod, y metering para seguimiento de costos como egress entre regiones
  • Proyecto: https://github.com/ClickHouse/kubenetmon
• Kubernetes Event Exporter: se hizo un fork de un exporter popular y se agregó un sink nativo de ClickHouse para analizar eventos de la API de Kubernetes a gran escala
  • Fork: ClickHouse/kubernetes-event-exporter
  • Está en marcha un plan para ingerir en LogHouse no solo eventos, sino todo el modelo de objetos de Kubernetes, y guardar snapshots de cada momento de cambio
• Control Plane Data: recopila datos operativos del área de Control Plane que todavía no habían sido incorporados a LogHouse
• Real User Monitoring (RUM): proyecto en curso que envía métricas de rendimiento frontend desde el navegador del usuario al pipeline OTel a través de un gateway público
• Istio Access Log: ingiere datos de tráfico a nivel HTTP del service mesh Istio para capturar patrones de request y response, latencia y decisiones de routing
  • Se combina con system.query_log y flujos de red de kubenetmon para analizar en forma cruzada SQL query, HTTP request y packet flow

Próximos pasos: zero-impact scraping y JSON

• Las consultas de scraping de SysEx están limitadas por strict memory limits, pero los clientes pueden preocuparse al verlas en logs y métricas
• ClickHouse está explorando zero-impact scraping, que no ejecuta consultas en el live system
  • Una dirección prometedora es aprovechar el plain rewritable disk de S3 donde ClickHouse ya escribe service logs
  • Si el worker pool de SysEx monta directamente la tabla de logs basada en disco, puede evitar consultar la instancia de ClickHouse en ejecución
• Si este enfoque tiene éxito, podrá mantener las ventajas actuales de formato nativo, alta fidelidad y mínima transformación, reduciendo además la percepción de impacto operativo
• El tipo JSON de ClickHouse llegó a GA en la versión 25.3; al aparecer nuevos campos, crea dinámicamente columnas del tipo adecuado y también maneja campos con múltiples tipos y schema explosion
• LogHouse está evaluando qué tan bien encaja JSON con los patrones de acceso de observabilidad a gran escala
  • Buscar strings en todo un blob JSON puede escanear miles de columnas
  • Existe una alternativa que consiste en almacenar el JSON como raw string junto con los datos estructurados
  • La mayoría de los atributos de log y resource son pequeños y estables, por lo que el tipo Map sigue siendo adecuado
  • HyperDX convierte automáticamente el acceso a maps en funciones JSONExtract