Por qué Tesla eligió ClickHouse en lugar de Thanos para escalar Prometheus

Cada vez que una gran empresa abandona una pila tecnológica consolidada, internet reacciona igual: "Espera... ¿por qué no se limitaron a escalarla?".

Eso fue exactamente lo que ocurrió cuando se conoció que Tesla estaba migrando cargas de trabajo de métricas a ClickHouse. La afirmación que circulaba era que "Prometheus no escala horizontalmente", y la contrapregunta obvia no tardó en surgir: ¿por qué no recurrieron a Thanos o Cortex?

Es una duda razonable, y las respuestas resultan más interesantes que el propio titular.

Primero, Prometheus sí escala, pero con sus propias decisiones de diseño

Hay un mito que conviene desmontar de inmediato. Prometheus escala perfectamente, solo que no del mismo modo en que lo hace una base de datos SQL distribuida.

De serie, un único servidor de Prometheus escala verticalmente. Añades RAM y CPU, ajustas los tiempos de retención y controlas la cardinalidad. Cuando llegas a una escala seria, introduces patrones horizontales:

• Sharding por dominio funcional
• Federaciones
• Thanos
• Cortex
• Mimir

Como señaló sin rodeos un operador experimentado:

Prometheus puede gestionar una cardinalidad de 100 millones. Thanos puede gestionar miles de millones.

Hablamos de infraestructura real, muy por encima de un entorno doméstico. Por eso, la idea de que "Prometheus no escala horizontalmente" no es del todo exacta. Sencillamente no escala igual que una base de datos OLAP distribuida.

El argumento a favor de Thanos: elástico y nativo de almacenamiento de objetos

Una de las respuestas más sólidas del debate provino de alguien que administra tanto Thanos como ClickHouse y utiliza cada uno para señales distintas. Su configuración:

• Thanos para métricas
• ClickHouse para registros, trazas y errores

Esa separación resulta elocuente, porque las cargas de métricas y las de registros son naturalezas radicalmente distintas.

También destacan que escalar ClickHouse horizontalmente puede ser más complicado en ciertos aspectos, ya que cada shard depende de un disco local persistente que requiere atención, y modificar el número de shards es engorroso. Esa es una carga operativa real.

Con Thanos, el escenario es otro:

• Los componentes de consulta pueden escalar horizontalmente.
• Los nodos de almacenamiento escalan con el almacenamiento de objetos.
• El despliegue y los StatefulSets facilitan la escalabilidad.
• Los datos se dividen de forma natural mediante el almacenamiento de objetos de S3.

Dicho de otro modo, escalar Thanos es principalmente cuestión de orquestación y almacenamiento de objetos, mientras que escalar ClickHouse exige cálculos de particionamiento y planificación de discos. Son compromisos distintos.

Entonces, ¿por qué eligió Tesla ClickHouse?

Aquí es donde el asunto se pone interesante. La decisión probablemente tuvo menos que ver con un "Prometheus no da la talla" y más con el tipo de escala que necesitaban.

ClickHouse es una base de datos analítica. Está optimizada para:

• Conjuntos masivos de datos columnares
• Agregaciones complejas
• Consultas ad hoc
• Retención prolongada
• Análisis multiseñal

Prometheus (incluso con Thanos) está optimizado para:

• Métricas de series temporales
• Consultas operativas
• Alertas en tiempo real
• Ingesta masiva de telemetría
• Semántica de PromQL

Esos objetivos tienen puntos de contacto, pero no son idénticos. Si Tesla buscaba algo de lo siguiente, ClickHouse empieza a ganar atractivo:

• Análisis cruzado de métricas con otra telemetría
• Analítica histórica profunda
• Agregaciones arbitrarias tipo SQL
• Retenciones muy prolongadas a gran escala

El truco: tuvieron que reconstruir PromQL

Uno de los detalles más llamativos del debate es que, al parecer, Tesla implementó su propio transpilador (Comet) de PromQL a SQL, en colaboración con el equipo de ClickHouse. Ese detalle cambia el panorama.

Si te alejas del almacenamiento de Prometheus pero sigues queriendo la semántica de PromQL, tienes dos opciones:

1. Abandonar PromQL.
2. Recrearlo.

Decidieron recrearlo, lo que indica que PromQL es difícil de sustituir. Incluso si cambias los motores de almacenamiento, el modelo de consulta sigue importando. Si ClickHouse fuera un reemplazo directo de Prometheus no habría hecho falta una capa de transpilación, de modo que el simple hecho de haberla construido demuestra que la tarea no fue trivial.

La alta cardinalidad no está "resuelta" en ninguna parte

Otro hilo de la conversación apuntó a un problema de fondo: ¿qué pasa con la alta cardinalidad? ¿Acaso no sigue siendo un problema en Thanos o Cortex?

Es correcto. Cambiar de backend no resuelve mágicamente la alta cardinalidad, porque es un problema de modelado de datos. Si tu diseño de métricas incluye lo siguiente, lo pagarás en algún punto:

• Etiquetas sin límite
• Dimensiones por usuario
• Identificadores dinámicos
• Cargas de trabajo efímeras

Tanto si utilizas Prometheus, Thanos o ClickHouse, el coste solo cambia de lugar. Prometheus lo paga en memoria, Thanos lo paga en almacenamiento de objetos y tamaño de índices, y ClickHouse lo paga en presión sobre los shards y planificación de consultas. La cardinalidad no desaparece; cambia de forma.

El factor de la cultura operativa

Hay otra dimensión que no suele discutirse lo suficiente. Thanos transmite la idea de un "Prometheus, pero a lo grande". ClickHouse transmite que "estamos operando una base de datos analítica distribuida". Son movimientos culturalmente muy diferentes.

Escalar Thanos implica:

• Añadir nodos de almacenamiento.
• Añadir nodos de consulta.
• Dejar que el almacenamiento de objetos gestione los bloques.

Escalar ClickHouse implica:

• Planificar el número de shards.
• Equilibrar particiones.
• Gestionar la replicación.
• Pensar en la localidad de los discos.
• Ajustar SQL distribuido.

Un participante llegó a comentar que cambiar la cantidad de shards en ClickHouse es doloroso, y es una queja de peso. Por eso, el paso de Tesla probablemente respondió a una cuestión de capacidad antes que de comodidad.

Métricas frente a un almacén de datos multiseñal

Otra posibilidad es que buscaran un sistema único para algo más que métricas. ClickHouse se utiliza habitualmente para:

• Registros
• Trazas
• Eventos
• Analítica de negocio

Si centralizas la telemetría en un único motor analítico, reduces la proliferación de sistemas. Cambias la sencillez operativa de Prometheus y Thanos por la flexibilidad analítica de ClickHouse, SQL y herramientas a medida. Ninguna de las dos opciones es sencillamente "mejor"; cada una optimiza para objetivos distintos.

¿Cuál era su carga de trabajo?

Un comentarista lanzó una pregunta directa: ¿a qué llamas tú alta carga? Esa es la pregunta adecuada.

Si Tesla operaba bajo las siguientes condiciones, una base de datos analítica columnar empieza a tener todo el sentido:

• Cientos de millones de series temporales activas
• Requisitos masivos de retención a largo plazo
• Cargas de trabajo analíticas entre dominios
• Ventanas de ingesta desordenadas
• Consultas complejas más allá de los puntos fuertes de PromQL

Eso no desacredita a Thanos. Solo sugiere que su caso de uso pudo haber ido más allá del simple "monitoreo de métricas".

El comentario sobre la "elección extraña"

Una de las respuestas más francas describió el movimiento como "una elección sumamente extraña". Esa reacción resulta comprensible, porque para muchos administradores de Prometheus, Thanos representa la vía natural para escalar: almacenamiento de objetos, una capa de consulta sin estado, escalado sencillo de componentes y un PromQL bien dominado.

Pasar a ClickHouse parece un abandono de ese ecosistema. Sin embargo, si amplías la perspectiva, pudo haber sido un proceso de convergencia en el que las métricas pasan a formar parte de una estructura analítica más amplia.

Qué nos enseña esto en realidad

El debate revela más sobre filosofía de arquitectura que sobre la propia Tesla.

Si consideras que las métricas son:

• Señales operativas
• Centradas ante todo en series temporales
• Orientadas a alertas
• Nativas de PromQL

Entonces Thanos (o Cortex y Mimir) parece la ruta de escalado más limpia.

Si consideras que las métricas son:

• Una fuente de datos más
• Para consultar junto a registros y eventos
• Parte de un lago analítico unificado
• Exploradas mejor mediante SQL y computación distribuida

Entonces ClickHouse tiene sentido, aunque pagas esa flexibilidad con mayor complejidad.

Prometheus no salió perdiendo

El detalle más interesante sigue siendo el transpilador de PromQL. Incluso tras cambiar el almacenamiento, mantuvieron la semántica de PromQL, lo que demuestra que Prometheus no falló a nivel conceptual. Su modelo de datos y su lenguaje de consulta seguían siendo lo bastante valiosos como para emularlos. El almacenamiento cambió de sitio y la semántica permaneció, lo que se parece bastante a una evolución natural.

La conclusión

"¿Por qué no limitarse a escalar Thanos?" es una buena pregunta. Una todavía mejor es qué problema pretendían resolver en realidad.

Escalar métricas horizontalmente es un reto. Unificar conjuntos masivos de telemetría bajo un motor analítico potente es otro muy distinto. Prometheus junto a Thanos puede gestionar una escala asombrosa, con miles de millones de series en ciertas configuraciones. ClickHouse puede asumir enormes cargas analíticas, pero exige otra mentalidad operativa.

La decisión se reduce a qué capacidades buscas y qué clase de sistema estás dispuesto a operar. Una vez entiendes eso, el movimiento resulta plenamente deliberado.