Warum wechselte Tesla zu ClickHouse, statt Thanos zu skalieren, und was das über Prometheus im großen Maßstab aussagt

Jedes Mal, wenn ein großes Unternehmen von einem bekannten Stack wegzieht, reagiert das Internet gleich: "Moment... warum haben sie es nicht einfach skaliert?"

Genau das passierte, als Leute mitbekamen, dass Tesla darüber sprach, Metrik-Workloads zu ClickHouse zu verschieben. Die kursierende Behauptung war, "Prometheus skaliert nicht horizontal", und die Gegenfrage kam sofort: Warum nicht einfach Thanos oder Cortex verwenden?

Das ist eine faire Frage, und die Antworten sind interessanter als die Schlagzeile.

Zunächst: Prometheus skaliert doch, mit den passenden Design-Entscheidungen

Räumen wir gleich mit einem Mythos auf. Prometheus skaliert durchaus, nur eben anders als eine verteilte SQL-Datenbank. Von Haus aus skaliert ein einzelner Prometheus-Server vertikal: RAM und CPU hinzufügen, Retention justieren, Kardinalität im Griff behalten.

Im ernsthaften Maßstab kommen horizontale Muster dazu:

• Sharding nach funktionaler Domäne
• Federation
• Thanos
• Cortex
• Mimir

Wie es ein erfahrener Operator unverblümt formulierte:

Prometheus kann 100 Millionen Kardinalität handhaben. Thanos kann Milliarden.

Das ist kein Hobby-Maßstab, das ist echte Infrastruktur. Die Aussage "Prometheus skaliert nicht horizontal" trifft es also nicht. Prometheus skaliert bloß anders als eine verteilte OLAP-Datenbank.

Das Thanos-Argument: elastisch und nativ für Object Storage

Eine der stärksten Antworten in der Diskussion kam von jemandem, der Thanos und ClickHouse parallel betreibt und je nach Signal das eine oder das andere wählt. Bei ihm laufen die Metriken auf Thanos und Logs, Traces und Fehler auf ClickHouse. Diese Aufteilung ist aufschlussreich, denn Metrik-Workloads und Log-Workloads sind völlig verschiedene Tiere.

Er weist auf etwas Wichtiges hin: ClickHouse horizontal zu skalieren ist in mancher Hinsicht schwieriger, weil jeder Shard lokalen persistenten Disk-Speicher hat, um den man sich kümmern muss. Die Shard-Anzahl zu ändern ist schmerzhaft, und das ist eine sehr reale operative Last.

Bei Thanos sieht das anders aus. Query-Komponenten lassen sich horizontal skalieren, Store-Nodes skalieren mit dem Object Storage, Deployment und StatefulSets machen das Skalieren unkompliziert, und die Daten werden über S3-Object-Storage von sich aus geshardet. Thanos zu skalieren ist damit größtenteils Orchestrierung und Object Storage, während ClickHouse zu skalieren Shard-Mathematik und Disk-Planung bedeutet. Zwei verschiedene Sätze von Trade-offs.

Warum also würde Tesla ClickHouse wählen?

Hier wird es interessant. Vermutlich ging es weniger darum, dass "Prometheus nicht skalieren kann", als darum, welche Art von Skalierung Tesla brauchte.

ClickHouse ist eine analytische Datenbank, optimiert für massive spaltenorientierte Datensätze, komplexe Aggregationen, Ad-hoc-Abfragen, lange Retention und Multi-Signal-Analyse. Prometheus, auch mit Thanos, ist auf Time-Series-Metriken, operative Abfragen, Echtzeit-Alerting, hochvolumige Telemetrie und PromQL-Semantik ausgelegt. Diese Ziele überschneiden sich, deckungsgleich sind sie aber nicht.

Wenn Tesla Querschnittsanalysen von Metriken zusammen mit anderer Telemetrie wollte, dazu tiefe historische Analytik, beliebige SQL-artige Aggregationen und sehr lange Retention im massiven Maßstab, dann wirkt ClickHouse durchaus attraktiv.

Der Haken: Sie mussten PromQL nachbauen

Eines der interessantesten Details der Diskussion ist, dass Tesla Berichten zufolge gemeinsam mit dem ClickHouse-Team einen eigenen Transpiler namens Comet von PromQL zu SQL eingeführt hat.

Dieses Detail verändert den Ton. Wer vom Prometheus-Storage wegzieht und trotzdem PromQL-Semantik will, hat zwei Optionen:

1. PromQL aufgeben.
2. Es nachbauen.

Tesla hat es nachgebaut, und das sagt etwas aus: PromQL ist schwer zu ersetzen. Selbst wenn man die Storage-Engine wechselt, bleibt das Query-Modell wichtig. Wäre ClickHouse ein Drop-in-Ersatz für Prometheus, bräuchte es keine Transpiler-Schicht. Dass eine gebaut wurde, zeigt, dass der Wechsel eben nicht trivial war.

Hohe Kardinalität ist nirgendwo "gelöst"

Ein weiterer Diskussionsstrang traf einen Kernpunkt: Was ist mit hoher Kardinalität, ist die in Thanos oder Cortex nicht auch ein Problem? Doch, ist sie. Ein anderes Backend löst hohe Kardinalität nicht, denn das ist ein Problem der Datenmodellierung.

Wenn Ihr Metrik-Design unbegrenzte Labels, Pro-Nutzer-Dimensionen, dynamische Identifikatoren und kurzlebige Workloads enthält, zahlen Sie dafür irgendwo. Prometheus zahlt in Speicher, Thanos in Object Storage und Indexgröße, ClickHouse in Shard-Druck und Query-Planung. Kardinalität verschwindet nicht, sie ändert nur ihre Form.

Die Betriebskultur-Perspektive

Über eine Ebene wird zu wenig gesprochen. Thanos fühlt sich an wie "Prometheus, nur größer", ClickHouse fühlt sich an wie "wir betreiben eine verteilte analytische Datenbank". Das sind kulturell unterschiedliche Schritte.

Thanos zu skalieren heißt, Store-Nodes und Query-Nodes hinzuzufügen und den Object Storage die Blöcke verwalten zu lassen. ClickHouse zu skalieren heißt, Shard-Anzahlen zu planen, Partitionen auszubalancieren, Replikation zu verwalten, über Disk-Lokalität nachzudenken und verteiltes SQL zu tunen. Ein Kommentator sagte sogar, die Shard-Anzahl in ClickHouse zu ändern sei schmerzhaft, und das ist keine triviale Beschwerde. Teslas Schritt zielte also wohl auf Fähigkeiten und nicht auf Einfachheit.

Metriken oder Multi-Signal-Data-Warehouse

Eine andere Möglichkeit ist, dass Tesla ein System für mehr als Metriken wollte. ClickHouse wird häufig für Logs, Traces, Events und Business-Analytik eingesetzt, und wer Telemetrie in einer analytischen Engine zentralisiert, hat am Ende weniger Systeme zu betreiben.

Man tauscht die operative Einfachheit von Prometheus plus Thanos gegen die analytische Flexibilität von ClickHouse mit SQL und eigenem Tooling. Besser ist das nicht, es ist ein anderes Optimierungsziel.

Wie sah Teslas Workload aus?

Ein Kommentator fragte unverblümt: Was ist für Sie "hoch"? Das ist die richtige Frage.

Wenn Tesla mit Hunderten Millionen aktiver Time Series, massiven Anforderungen an Langzeit-Retention, domänenübergreifenden Analytik-Workloads, Out-of-Order-Ingestion-Fenstern und komplexen Query-Workloads jenseits der Stärken von PromQL zu tun hatte, dann ergibt eine spaltenorientierte Analytik-Datenbank Sinn. Thanos ist damit nicht entwertet. Es deutet eher darauf hin, dass Teslas Use Case über Metriken-Monitoring hinausging.

Der Kommentar zur seltsamen Entscheidung

Eine der offensten Antworten bezeichnete den Schritt als "wirklich eine sehr seltsame Entscheidung". Diese Reaktion sagt etwas aus, denn für viele Prometheus-Betreiber ist Thanos die natürliche Skalierungsgeschichte, mit Object Storage, zustandsloser Query-Schicht, einfach skalierbaren Komponenten und gut verstandenem PromQL.

Der Wechsel zu ClickHouse wirkt aus dieser Sicht wie eine Abkehr vom Ökosystem. Zoomt man heraus, war es vielleicht eher eine Konvergenz, bei der Metriken Teil eines breiteren Analytik-Gefüges werden.

Was das eigentlich lehrt

Diese Debatte handelt weniger von Tesla als von architektonischer Philosophie.

Wenn Metriken für Sie operative Signale sind, Time-Series-first, alert-getrieben und PromQL-nativ, dann ist Thanos oder Cortex oder Mimir die sauberste Skalierungsgeschichte. Wenn Metriken für Sie nur eine weitere Datenquelle sind, die man neben Logs und Events abfragt, Teil eines vereinheitlichten analytischen Data Lake und am besten per SQL und verteiltem Compute zu erschließen, dann ergibt ClickHouse Sinn. Für diese Flexibilität bezahlen Sie allerdings mit Komplexität.

Prometheus hat nicht "verloren"

Das interessanteste Detail bleibt der PromQL-Transpiler. Auch nach dem Storage-Wechsel hat Tesla die PromQL-Semantik behalten, und konzeptionell ist Prometheus damit nicht gescheitert. Sein Datenmodell und seine Query-Sprache waren immer noch wertvoll genug, um sie nachzubilden. Der Storage wechselte, die Semantik blieb, und das sieht nach Evolution aus.

Zwei verschiedene Probleme

"Warum nicht einfach Thanos skalieren?" ist die richtige Frage, aber es gibt eine bessere: Welches Problem wollte Tesla eigentlich lösen?

Metriken horizontal zu skalieren ist ein Problem. Massive Telemetrie-Datensätze unter einer leistungsfähigen analytischen Engine zu vereinheitlichen, ist ein anderes. Prometheus plus Thanos bewältigt erstaunliche Größenordnungen, in manchen Setups Milliarden von Series. ClickHouse bewältigt enorme analytische Workloads, verlangt dafür aber ein anderes operatives Mindset.

Bei der Wahl geht es also auch darum, welche Art von System Sie betreiben wollen. Wer das mitdenkt, findet Teslas Schritt weniger seltsam und eher beabsichtigt.