Warum wechselte Tesla zu ClickHouse, statt Thanos zu skalieren - und was das wirklich über Prometheus im großen Maßstab aussagt
Jedes Mal, wenn ein großes Unternehmen von einem bekannten Stack wegzieht, reagiert das Internet auf dieselbe Weise.
"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 naheliegende 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 — aber mit Design-Entscheidungen
Räumen wir gleich mit einem Mythos auf.
Prometheus skaliert durchaus. Nur nicht auf dieselbe Weise wie eine verteilte SQL-Datenbank.
Von Haus aus ist ein einzelner Prometheus-Server vertikal skalierbar. RAM hinzufügen. CPU hinzufügen. Retention justieren. Kardinalität kontrollieren.
Im ernsthaften Maßstab führt man horizontale Muster ein:
- 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 Vorstellung, "Prometheus skaliert nicht horizontal", ist also nicht ganz zutreffend. Es skaliert nur nicht auf dieselbe Weise wie 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 sowohl Thanos als auch ClickHouse betreibt — und für unterschiedliche Signale jeweils das eine oder andere wählt.
Sein Setup:
- Thanos für Metriken
- ClickHouse für Logs, Traces, Fehler
Diese Aufteilung ist aufschlussreich.
Metrik-Workloads und Log-Workloads sind grundverschiedene Bestien.
Und 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.
Das ist eine sehr reale operative Last.
Bei Thanos?
- Query-Komponenten lassen sich horizontal skalieren.
- Store-Nodes skalieren mit dem Object Storage.
- Deployment und StatefulSets machen das Skalieren unkompliziert.
- Daten werden über S3-Object-Storage natürlich geshardet.
Anders gesagt: Thanos zu skalieren ist größtenteils Orchestrierung und Object Storage.
ClickHouse zu skalieren ist Shard-Mathematik und Disk-Planung.
Unterschiedliche Trade-offs.
Warum also würde Tesla ClickHouse wählen?
Jetzt kommen wir zum interessanten Teil.
Denn es geht vermutlich nicht darum, dass "Prometheus nicht skalieren kann".
Es geht darum, welche Art von Skalierung sie brauchten.
ClickHouse ist eine analytische Datenbank.
Sie ist optimiert für:
- Massive spaltenorientierte Datensätze
- Komplexe Aggregationen
- Ad-hoc-Abfragen
- Lange Retention
- Multi-Signal-Analyse
Prometheus (auch mit Thanos) ist optimiert für:
- Time-Series-Metriken
- Operative Abfragen
- Echtzeit-Alerting
- Hochvolumige Telemetrie
- PromQL-Semantik
Diese Ziele überschneiden sich — aber sie sind nicht identisch.
Wenn Tesla Folgendes wollte:
- Querschnittsanalyse von Metriken mit anderer Telemetrie
- Tiefe historische Analytik
- Beliebige SQL-artige Aggregationen
- Sehr lange Retention im massiven Maßstab
Dann beginnt ClickHouse attraktiv zu wirken.
Aber hier ist der Haken: Sie mussten PromQL nachbauen
Eines der interessantesten Details in der Diskussion:
Tesla führte Berichten zufolge einen eigenen Transpiler (Comet) von PromQL zu SQL ein — in Zusammenarbeit mit dem ClickHouse-Team.
Dieses Detail verändert den Ton.
Wenn man vom Prometheus-Storage wegzieht, aber weiterhin PromQL-Semantik will, hat man zwei Optionen:
- PromQL aufgeben.
- Es nachbauen.
Sie entschieden sich, es nachzubauen.
Das deutet auf etwas Mächtiges hin:
PromQL ist schwer zu ersetzen.
Selbst wenn man die Storage-Engine wechselt, zählt das Query-Modell immer noch.
Wäre ClickHouse ein Drop-in-Ersatz für Prometheus, bräuchte man keine Transpiler-Schicht.
Dass eine gebaut wurde, sagt, dass das nicht trivial war.
Hohe Kardinalität ist nirgendwo "gelöst"
Ein weiterer Diskussionsstrang traf einen Kernpunkt:
Was ist mit hoher Kardinalität? Ist das nicht auch in Thanos oder Cortex noch ein Problem?
Richtig.
Hohe Kardinalität wird nicht auf magische Weise durch den Wechsel des Backends gelöst.
Es ist ein Datenmodellierungsproblem.
Wenn Ihr Metrik-Design Folgendes enthält:
- Unbegrenzte Labels
- Pro-Nutzer-Dimensionen
- Dynamische Identifikatoren
- Kurzlebige Workloads
Zahlen Sie dafür irgendwo den Preis.
Prometheus?
Thanos?
ClickHouse?
Die Kosten verschieben sich nur.
Prometheus zahlt in Speicher.
Thanos zahlt in Object Storage und Indexgröße.
ClickHouse zahlt in Shard-Druck und Query-Planung.
Kardinalität verschwindet nicht. Sie ändert nur ihre Form.
Die Betriebskultur-Perspektive
Es gibt noch eine weitere Ebene, über die zu wenig gesprochen wird.
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-Skalierung sieht so aus:
- Store-Nodes hinzufügen.
- Query-Nodes hinzufügen.
- Object Storage die Blöcke verwalten lassen.
ClickHouse-Skalierung sieht so aus:
- Shard-Anzahlen planen.
- Partitionen ausbalancieren.
- Replikation verwalten.
- Über Disk-Lokalität nachdenken.
- Verteiltes SQL tunen.
Ein Kommentator sagte sogar, die Shard-Anzahl in ClickHouse zu ändern sei schmerzhaft.
Das ist keine triviale Beschwerde.
Teslas Schritt ging also vermutlich nicht um Einfachheit.
Es ging um Fähigkeiten.
Metriken vs. Multi-Signal-Data-Warehouse
Eine andere Möglichkeit?
Sie wollten ein System für mehr als nur Metriken.
ClickHouse wird häufig verwendet für:
- Logs
- Traces
- Events
- Business-Analytik
Wenn man Telemetrie in einer analytischen Engine zentralisiert, reduziert man die Systemzersplitterung.
Man tauscht:
Operative Einfachheit (Prometheus + Thanos)
Gegen:
Analytische Flexibilität (ClickHouse + SQL + Custom Tooling)
Das ist keine "bessere" Entscheidung.
Es ist ein anderes Optimierungsziel.
Die eigentliche Frage: Wie sah ihr Workload aus?
Ein Kommentator fragte unverblümt:
Was ist für Sie "hoch"?
Das ist die richtige Frage.
Wenn Tesla in folgendem Bereich operierte:
- Hunderte Millionen aktiver Time Series
- Massive Anforderungen an Langzeit-Retention
- Domänenübergreifende Analytik-Workloads
- Out-of-Order-Ingestion-Fenster
- Komplexe Query-Workloads jenseits der Stärken von PromQL
Dann beginnt eine spaltenorientierte Analytik-Datenbank sinnvoll zu wirken.
Aber das entwertet Thanos nicht.
Es deutet nur darauf hin, dass ihr Use Case möglicherweise ü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.
Object Storage.
Zustandslose Query-Schicht.
Einfaches Skalieren der Komponenten.
Gut verstandenes PromQL.
Der Wechsel zu ClickHouse wirkt wie eine Abkehr von diesem Ökosystem.
Aber zoomt man heraus, war es vielleicht keine Abkehr.
Es war vielleicht Konvergenz.
Metriken, die Teil eines breiteren Analytik-Gefüges werden.
Was das eigentlich lehrt
Bei dieser Debatte geht es nicht um Tesla.
Es geht um architektonische Philosophie.
Wenn Sie glauben, Metriken sind:
- Operative Signale
- Time-Series-first
- Alert-getrieben
- PromQL-nativ
Dann wirkt Thanos (oder Cortex/Mimir) wie die sauberste Skalierungsgeschichte.
Wenn Sie glauben, Metriken sind:
- Nur eine weitere Datenquelle
- Neben Logs und Events abzufragen
- Teil eines vereinheitlichten analytischen Data Lake
- Am besten per SQL und verteiltem Compute zu erschließen
Dann ergibt ClickHouse Sinn.
Aber Sie bezahlen für diese Flexibilität mit Komplexität.
Prometheus hat nicht "verloren"
Das interessanteste Detail bleibt der PromQL-Transpiler.
Auch nach dem Storage-Wechsel bewahrten sie die PromQL-Semantik.
Das zeigt: Prometheus ist konzeptionell nicht gescheitert.
Sein Datenmodell und seine Query-Sprache waren immer noch wertvoll genug, um sie nachzubilden.
Storage wechselte.
Semantik blieb.
Das ist keine Niederlage.
Das ist Evolution.
Die eigentliche Erkenntnis
"Warum nicht einfach Thanos skalieren?" ist die richtige Frage.
Aber die bessere Frage lautet:
Welches Problem versuchten sie eigentlich zu 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 kann erstaunliche Größenordnungen bewältigen — in manchen Setups Milliarden von Series.
ClickHouse kann enorme analytische Workloads bewältigen — verlangt aber ein anderes operatives Mindset.
Bei der Wahl geht es nicht allein um Fähigkeiten.
Es geht darum, welche Art von System Sie betreiben wollen.
Und sobald man das versteht, wirkt der Schritt nicht mehr seltsam.
Er wirkt beabsichtigt.