Reemplazar OTel y expandir la plataforma de observabilidad con Wide Events

• LogHouse escaló en un año de 19 PiB a más de 100 PB de datos de logs, llegando a casi 500 billones de filas
• Debido a las limitaciones de procesamiento de datos e ineficiencias de OpenTelemetry (OTel), se migró a un pipeline personalizado (SysEx) adaptado al sistema central
• Con esta transición, se logró mantener el uso de CPU por debajo del 10% incluso con un aumento de 20 veces en el volumen de eventos
• Con la adopción de HyperDX y ClickStack de ClickHouse, se construyó un entorno con UI y datos integrados, flexibilidad de esquema y una potente exploración de datos
• Mediante la adopción de un modelo de wide events y alta cardinalidad, ahora es posible almacenar y analizar todos los eventos sin agregación previa

---

Contexto y cambios

• LogHouse, la plataforma interna de logging para ClickHouse Cloud, creció en solo un año hasta convertirse en un sistema de gran escala: pasó de 19 PiB a más de 100 PB de datos, y de 37 billones de filas a casi 500 billones
• Al principio, toda la telemetría se recolectaba mediante OpenTelemetry (OTel), pero en un entorno de datos masivos se hicieron evidentes problemas de rendimiento, límites de recursos y desperdicio de CPU y pérdida de datos durante el proceso de transformación

Limitaciones de OTel y motivos para introducir un pipeline personalizado

• El pipeline de OTel era extremadamente ineficiente: los logs se convertían a JSON, luego se remapeaban al formato de OTel y pasaban repetidamente por conversiones y marshalling
• En la práctica, procesar 20 millones de filas por segundo con OTel requería alrededor de 8,000 núcleos de CPU
• Cuando el tráfico aumentaba bruscamente, el Collector se sobrecargaba y comenzaba a descartar logs, lo que provocaba datos no recolectados

Introducción de SysEx y su arquitectura

• SysEx (System Tables Exporter) mueve directamente a LogHouse los datos de las system tables de ClickHouse en sus tipos originales, sin transformación
• Usa scraping distribuido mediante una estructura de anillo hash, además de buffers con retraso temporal y ventanas deslizantes para evitar pérdida de datos y cumplir con los SLA internos
• Gracias a Go y a funciones personalizadas del cliente de ClickHouse, permite transferencia byte-to-byte sin marshalling de datos
• Para manejar esquemas variables, se aplican hash de esquema y administración dinámica de esquemas, y con el Merge table engine se integran múltiples versiones de esquema en una sola vista lógica
• También admite recolección basada en snapshots de tablas en memoria y tareas avanzadas de diagnóstico y análisis

Mejoras de rendimiento y eficiencia

• Con la adopción de SysEx, mientras OTel Collector procesa 2 millones de logs por segundo con 800 CPU, SysEx puede procesar 37 millones de logs con 70 CPU
• Esta mejora en eficiencia redujo drásticamente el uso de recursos, evitó la pérdida de eventos y permitió un entorno de soporte en tiempo real

El rol continuo de OTel

• OTel sigue siendo esencial por ofrecer una plataforma estándar y neutral frente a proveedores, y continúa siendo indispensable durante caídas del servicio o estados anómalos
• También puede capturar logs en situaciones de crash o fallas que SysEx no puede procesar
• Actualmente, para optimizar recursos, solo se eliminan los logs por debajo del nivel trace y se recolectan únicamente los de nivel info o superior

Integración de UI, HyperDX y ClickStack

• Se está migrando gradualmente desde una UI personalizada en Grafana hacia una UI nativa de ClickHouse basada en HyperDX
• HyperDX ofrece independencia de esquema, soporte para consultas Lucene y SQL, además de compatibilidad total con la amplia variedad de tipos de datos de ClickHouse
• También permite integrar datos provenientes de distintas estructuras de tablas y exporters personalizados sin necesidad de cambiar la UI
• Grafana sigue usándose de forma complementaria para métricas basadas en Prometheus y dashboards fijos

Adopción de Wide Events y del modelo de alta cardinalidad

• Los wide events son un enfoque innovador en el que cada fila incluye diverso contexto, como ID de consulta, nombre del Pod e información de versión, permitiendo almacenar todos los datos sin agregación
• A diferencia de Prometheus y otros sistemas, esto permite análisis profundos y consultas flexibles sin preocuparse por agregaciones previas, límites de labels o explosión de cardinalidad
• Las agregaciones necesarias se realizan en el momento del análisis, lo que permite equilibrar rendimiento y costo incluso en entornos de datos masivos

Visualización de datos y flexibilidad de consulta

• ClickHouse se integra muy bien con herramientas como Plotly y Jupyter notebook, lo que permite usar libremente distintos recursos de visualización
• Además de la exploración rápida con HyperDX basada en Lucene, ClickHouse permite hacer directamente análisis avanzados de causa raíz mediante consultas complejas con relaciones y condiciones (SQL, JOIN, etc.)

Crecimiento de diversas fuentes de datos basadas en Wide Events

• kubenetmon: proyecto open source de monitoreo de red para Kubernetes, enfocado en tráfico L3/L4, conexiones y análisis de costos
• Kubernetes Event Exporter: uso de un fork con ClickHouse sink añadido para rastrear cambios de estado en clústeres grandes; también se experimenta con snapshots completos de objetos
• Control Plane Data, RUM (Real User Monitoring) y Istio Access Log, entre otras capas de datos, han ampliado enormemente el alcance de interpretación y la capacidad de análisis correlacional

Consideraciones operativas y dirección futura

• Aunque SysEx puede exponerse en logs y métricas durante las consultas, fue diseñado con límites de memoria y una estructura que minimiza el impacto en caso de error
• Zero-impact scraping: se está investigando un enfoque completamente desacoplado (por ejemplo, usando plain rewritable disk basado en S3) para eliminar de raíz incluso el impacto sobre el clúster
• OTel sigue siendo importante para asegurar logs en etapas iniciales del servicio y en estados anómalos, pero si el enfoque zero-impact se estabiliza, su dependencia podría reducirse aún más

Evolución y uso del tipo JSON de ClickHouse

• El tipo JSON fue lanzado oficialmente como GA, permitiendo creación dinámica de columnas por campo, soporte para múltiples tipos y una respuesta flexible ante la explosión de esquemas
• Como la optimización de consultas JSON con muchas columnas aún no es perfecta, se están refinando enfoques como el almacenamiento paralelo por forma y la reevaluación de la practicidad del tipo Map
• En conjunto con HyperDX, es posible extraer y analizar automáticamente campos Map y JSON, y se planea ampliar aún más el uso de JSON en el futuro

Conclusión y cambio cultural

• LogHouse ya se consolidó como la plataforma central de observabilidad para la operación de ClickHouse Cloud, desde análisis de rendimiento hasta debugging en tiempo real
• Aunque el punto de partida fue la reducción de costos, la organización está viviendo una transformación técnica y cultural gracias a herramientas personalizadas como SysEx, la convivencia con OTel y la expansión de una UI flexible basada en HyperDX
• Un modelo de datos de Wide Events de gran escala y alta precisión está aportando nuevo valor y eficiencia en ingeniería, soporte y análisis de datos
• A partir de la experiencia obtenida operando a escala de 100 PB y 500 billones de filas, planean seguir liderando el futuro de la observabilidad

[GN⁺]

Comentarios de Hacker News

• Honestamente, no creo que esto sea algo de lo que presumir. Que estén almacenando 100 PB de logs es prueba de que todavía no han descubierto qué vale la pena conservar de verdad. La mayor parte de la información clave se puede entender con métricas y eventos estructurados. ¿El resto? Logs de trazas detalladas que nadie lee y que solo se revisan cuando de verdad hay una caída. ¿Una mejor forma de hacerlo? Introducir una “política de almacenamiento basada en interés”, por ejemplo eliminando automáticamente los logs que nunca se usaron en alertas o que no aparecieron en búsquedas durante 3 meses. Si no van por ese camino, esto no es más que un basurero digital de lujo con un poco de compresión encima
  • Yo prefiero lo contrario: recolectar todos los datos y filtrar cuando no se necesiten. Los logs de depuración no hacen falta normalmente, pero cuando sí hacen falta, son absolutamente indispensables. Si un evento es tan raro que ni siquiera se puede reproducir, ya no puedes volver a recolectar esos datos después. Si ya está todo guardado, solo hay que buscarlo, y eso me parece mucho mejor
  • He trabajado en varias empresas usando Datadog y, cuando el costo de renovación se dispara de forma absurda, siempre llega la presión de quedarse solo con métricas y algunos eventos limitados, reduciendo los logs. El problema es que, si hubiéramos sabido de antemano qué iba a pasar, lo habríamos arreglado desde antes. Cuando algo raro ocurre, los logs detallados son muy necesarios para averiguar qué fue lo que pasó. Pero, en la práctica, si no es una situación que se repite, no hay forma de saber de antemano qué logs son importantes
  • La “política de almacenamiento basada en interés” de verdad es una gran idea. Solo con contar cuántas veces se accede vía consultas o alertas por patrón de log ya se puede definir una política de TTL (tiempo de retención). De hecho, mi equipo adoptó este enfoque y redujo los costos de almacenamiento en 70%, conservando todos los datos importantes
  • El costo de enviar logs tampoco es gratis. Sobre todo en lenguajes que escriben los logs a disco lo más rápido posible para investigar la causa de un crash, el costo es todavía mayor. Si hay demasiada información, también se vuelve más difícil encontrar las correlaciones realmente importantes, y los logs de bugs ya resueltos pierden valor muy rápido. Yo prefiero los datos estadísticos. Los datos estadísticos son eficientes de agregar y, especialmente en lenguajes basados en GIL, el uso de OTEL a veces puede tener un overhead excesivo
  • Si los datos ya están almacenados, luego se puede filtrar o limpiar lo que haga falta. Me parece mejor guardar todo y usarlo cuando se necesite, que sufrir porque justo no está cuando hace falta. Claro, eso solo aplica si tienes los recursos para operar una infraestructura de este tamaño
• En realidad esto solo aplica a los logs de ClickHouse. No tiene mucha relación con otros tipos de logs. Claro, aun así ClickHouse me parece una solución excelente
  • Debes ser divertidísimo en las fiestas
• Menciono un punto de cuidado. Cuando un servicio entra en crash loop o se cae por una falla, con SysEx no se puede acceder a las tablas de sistema necesarias, así que no se pueden recolectar logs. Pero OpenTelemetry (OTel), al ser pasivo, puede capturar logs que salen por stdout y stderr incluso si el servicio todavía no se ha recuperado por completo. Así se pueden reunir logs incluso durante una falla y analizar la causa raíz
  • Todos los proyectos de OTel que he hecho fueron activos. Así que eso no me parece información nueva, sino más bien una explicación incorrecta o incompleta
• Me pregunto si un “wide event” realmente debería ocupar tanto espacio de almacenamiento. La observabilidad es, en esencia, un problema de muestreo. Basta con poder reconstruir lo mejor posible el estado en un momento dado usando la menor cantidad de almacenamiento. Se puede reducir el número de muestras o mejorar la eficiencia de compresión. Además, no creo que la tecnología de compresión ya haya llegado a su límite. En datos llenos de redundancia, seguro existe una enorme estructura de bajo rango (low rank). Claro, ya se usan índices invertidos y varios tipos de árboles, pero siento que también hay esperanza en métodos más experimentales, más de investigación, como la factorización tensorial de bajo rango. No trabajo en la industria, así que quizá se me esté escapando algo
• Nunca he trabajado a una escala como la de ClickHouse. ¿Logs de este volumen de verdad se pueden buscar? Según entiendo, ElasticSearch consulta bien a pequeña escala. ¿Cuál sería la razón para usar ClickHouse en vez de guardar archivos json para logs históricos?
  • Trabajo a esta escala. La respuesta corta es: sí, se puede. Pero el costo de procesarlo puede ser inimaginable. Si la estrategia de indexación, ordenamiento y clustering está mal hecha, una sola búsqueda de “registros que contienen esta cadena” te puede costar entre $1 y $10. En mi experiencia, con datos masivos siempre importan dos principios: “tocar la menor cantidad posible de datos, lo menos posible” y “mover lo menos posible”. Con solo una serialización/deserialización extra o una sola operación de disco o IO de red, el costo se dispara. En ese sentido, en OTel pasar por un collector adicional puede ir directamente en contra de la eficiencia. Pero a escala de petabytes, lo que ahorras con estas pequeñas optimizaciones alcanza y sobra para pagar el salario de un ingeniero que escriba código complejo de serialización
  • ¿Por qué usar ClickHouse para logs históricos en vez de archivos json? Hay varias razones. (1) Una base de datos de logs como ClickHouse usa compresión por columnas, comprimiendo cada campo por separado, así que ocupa muchísimo menos espacio que archivos json normales, incluso comprimidos. (2) Una base de datos de logs consulta muchísimo más rápido. Puede ser más de 1000 veces más rápida, porque simplemente no lee los datos que no hacen falta. Enlace relacionado. (3) Buscar con grep en 100 PB de archivos json no es realista. Una base de datos de logs sí puede escalar horizontalmente agregando más nodos y almacenamiento
  • Es un tema de escala y costo. En nuestra empresa también chocamos con el problema del volumen de logs. Si metes json tal cual en Splunk, cuesta más de 6 millones de dólares al año. Pero el presupuesto aprobado es solo del 5 al 10% de eso. En el artículo dicen que procesar logs json requería 8,000 CPU, pero después de optimizarlo se resolvió con solo 90 CPU
  • Hace 2 o 3 años, a ClickHouse le faltaba en búsqueda full text. Era rápido y podía manejar grandes volúmenes al nivel de ElasticSearch, pero según el caso de uso, si no indexabas por adelantado, sentía que ES era mucho mejor para agregaciones, agrupamientos y FTS
• El extremismo de la observabilidad de verdad parece una religión emergente. Y además tiene muchísimo dinero
  • Para investigar anomalías desconocidas, la verdad es que no hay muchas alternativas claras
  • Lo divertido es la ironía de que te hacen sufrir con estos problemas y luego te venden la estrategia de “paga una suscripción mensual y todo se resuelve”
• En el artículo no se menciona cuál es el período de retención de logs. Después de cierto tiempo, me pregunto si realmente hace falta conservar los datos crudos en vez de dejar solo datos resumidos o agregados
• Cada vez que vuelvo a Postgres después de usar ClickHouse, siento un choque cultural. No me entra en la cabeza que importar un dump de 20 GB tome varios minutos. ¿No debería hacerse eso en segundos?
  • Cada vez que uso ClickHouse la paso muy mal. Claro que ClickHouse tiene sus casos de uso y Postgres no puede reemplazarlo todo, pero siento que ClickHouse tiene muchos “puntos de riesgo” y que, salvo para objetivos muy específicos y limitados, Postgres es mejor en casi todo
• Quienes empujan el uso de wide events no hablan del incremento brutal en el costo de datos para logs. Comparado con el enfoque tradicional (métricas + trazas + logs basados en muestreo), claramente cuesta mucho más. Seguro hay beneficios, pero el tema del costo siempre queda fuera
  • Una estructura de wide events bien diseñada en realidad puede reducir el costo de almacenamiento frente a los logs tradicionales. Como una solicitud externa queda registrada como un solo wide event, ahí ya viene toda la información necesaria para depurar o analizar después. Ver también A practitioner's guide to wide events
• Tengo curiosidad por el truco central de sistemas como ClickHouse o Dynamo. ¿En esencia son como una tabla hash gigantesca?
  • Hay dos trucos comunes en bases de datos de gran escala como ClickHouse. El primero es organizar inteligentemente los datos en disco para poder ignorar la mayor parte y leer solo los bloques necesarios (almacenamiento columnar y familias tipo LSM tree, etc.). Y además comprimir todos los datos almacenados para minimizar también el IO de disco. El segundo es una optimización extrema para aprovechar al máximo todos los recursos (CPU, RAM, disco y red). Por ejemplo, ClickHouse puede procesar más de mil millones de filas por segundo por núcleo de CPU, y escala linealmente según la cantidad de núcleos