OTel ersetzen und die Observability-Plattform mit Wide Events erweitern

• LogHouse verarbeitete innerhalb eines Jahres statt 19 PiB inzwischen mehr als 100 PB an Log-Daten und skalierte auf rund 500 Billionen Zeilen
• Wegen der Grenzen und Ineffizienzen der Datenverarbeitung mit OpenTelemetry (OTel) wurde auf eine maßgeschneiderte Pipeline (SysEx) umgestellt, die auf die Kernsysteme zugeschnitten ist
• Durch diesen Wechsel konnte die Ereignisverarbeitung um das 20-Fache gesteigert werden, während die CPU-Auslastung unter 10 % blieb
• Mit der Einführung von HyperDX und ClickStack in ClickHouse wurden UI und Daten integriert sowie Schema-Flexibilität und eine leistungsfähige Umgebung zur Datenexploration geschaffen
• Durch die Einführung von Wide Events und einem High-Cardinality-Modell können nun alle Ereignisse ohne Vorab-Aggregation gespeichert und analysiert werden

---

Hintergrund und Wandel

• LogHouse, die interne Logging-Plattform für ClickHouse Cloud, ist innerhalb eines Jahres von einem System mit 19 PiB und 37 Billionen Zeilen zu einer Großplattform mit mehr als 100 PB Daten und fast 500 Billionen Zeilen gewachsen
• Anfangs wurde die gesamte Telemetrie über OpenTelemetry (OTel) erfasst, doch in einer Umgebung mit sehr großen Datenmengen traten die Grenzen bei Performance und Ressourcen sowie Probleme durch CPU-Verschwendung und Datenverlust bei der Datentransformation deutlich hervor

Grenzen von OTel und Gründe für die Einführung einer maßgeschneiderten Pipeline

• Die OTel-Pipeline war extrem ineffizient, weil Logs in JSON umgewandelt, anschließend erneut auf das OTel-Format gemappt und dabei mehrfach konvertiert und marshalled wurden
• Tatsächlich wären für die Verarbeitung von 20 Millionen Zeilen pro Sekunde auf OTel-Basis rund 8.000 CPU-Kerne nötig gewesen
• Bei plötzlichen Lastspitzen wurden die Collector überlastet, wodurch Logs verworfen wurden und nicht erfasste Daten entstanden

Einführung und Architektur von SysEx

• SysEx (System Tables Exporter) überträgt Daten aus den system tables von ClickHouse direkt und ohne Konvertierung in ihren ursprünglichen Typen nach LogHouse
• Verteiltes Scraping über eine Hash-Ring-Struktur, ein zeitverzögerter Puffer sowie ein Sliding-Window-Verfahren verhindern Datenverluste und erfüllen interne SLAs
• Mit Go und angepassten Funktionen des ClickHouse-Clients ist eine byte-to-byte-Übertragung ohne Data Marshaling möglich
• Um mit variablen Schemas umzugehen, werden Schema-Hashes und dynamisches Schema-Management eingesetzt; mit der Merge table engine werden mehrere Schemaversionen in einer logischen Sicht zusammengeführt
• Erfassung speicherbasierter Tabellen auf Snapshot-Basis sowie Unterstützung für fortgeschrittene Diagnose- und Analyseaufgaben

Verbesserungen bei Leistung und Effizienz

• Mit SysEx kann der OTel Collector zwar 2 Millionen Logs pro Sekunde mit 800 CPUs verarbeiten, SysEx jedoch 37 Millionen Logs mit nur 70 CPUs
• Diese Effizienzsteigerung senkt den Ressourcenverbrauch drastisch, verhindert Event-Verluste und ermöglicht eine Echtzeit-Supportumgebung

Die fortbestehende Rolle von OTel

• OTel bietet weiterhin einen standardisierten, vendor-neutralen Plattformansatz und bleibt bei Serviceausfällen oder abnormalen Zuständen unverzichtbar
• Auch in Crash- oder Fehlerfällen, die SysEx nicht verarbeiten kann, lassen sich weiterhin Logs erfassen
• Aktuell werden nur noch Logs unterhalb des Trace-Levels entfernt; ab dem Info-Level wird gesammelt, um Ressourcen zu optimieren

UI-Integration mit HyperDX und ClickStack

• Von einer bisherigen maßgeschneiderten Grafana-Oberfläche wird schrittweise auf eine ClickHouse-native UI auf Basis von HyperDX umgestellt
• HyperDX ist schemaunabhängig, unterstützt Lucene-Abfragen und SQL und bietet vollständige Kompatibilität mit den vielfältigen Datentypen von ClickHouse
• Auch Daten aus unterschiedlichen Tabellenstrukturen und aus maßgeschneiderten Exporter-Quellen lassen sich ohne Änderungen an der UI integrieren
• Grafana übernimmt weiterhin Prometheus-basierte Metriken und feste Dashboards, sodass beide Lösungen komplementär eingesetzt werden

Einführung von Wide Events und High-Cardinality-Modellen

• Wide Events sind ein grundlegender neuer Ansatz, bei dem jede Zeile vielfältigen Kontext wie Query-ID, Pod-Namen oder Versionsinformationen enthält, sodass alle Daten ohne Aggregation gespeichert werden
• Anders als bei Prometheus und ähnlichen Systemen sind dadurch tiefgehende Analysen und flexible Abfragen ohne Vorab-Aggregation, Label-Beschränkungen oder Sorgen vor Cardinality-Explosion möglich
• Indem benötigte Aggregationen erst zum Zeitpunkt der Analyse durchgeführt werden, lassen sich in Umgebungen mit großen Datenmengen Performance und Kosten zugleich optimieren

Datenvisualisierung und Flexibilität bei Abfragen

• ClickHouse lässt sich hervorragend mit Plotly, Jupyter notebook und anderen Tools integrieren, sodass sich verschiedenste Visualisierungswerkzeuge frei nutzen lassen
• Neben der schnellen Exploration mit HyperDX auf Lucene-Basis sind in ClickHouse selbst auch hochgradige Ursachenanalysen über komplexe relationale und bedingte Abfragen (SQL, JOIN usw.) möglich

Zunahme verschiedener Datenquellen auf Basis von Wide Events

• kubenetmon: Open-Source-Tool zur Überwachung von Kubernetes-Netzwerken für L3/L4-Traffic, Verbindungen und Kostenanalysen
• Kubernetes Event Exporter: Nutzung eines Forks mit zusätzlichem ClickHouse-Sink zur Verfolgung von Zustandsänderungen in großen Clustern; Experimente mit vollständigen Objekt-Snapshots laufen
• Control Plane Data, RUM (Real User Monitoring), Istio Access Log und weitere Daten aus verschiedenen Schichten erweitern Interpretationsspielraum und Korrelationsanalysen deutlich

Betriebliche Überlegungen und künftige Ausrichtung

• SysEx kann während Abfragen in Logs und Metriken sichtbar werden, ist jedoch so entworfen, dass Speichergrenzen eingehalten und Auswirkungen bei Fehlern minimiert werden
• Zero-impact scraping: Es wird an einem vollständig entkoppelten Ansatz geforscht, der etwa eine S3-basierte plain rewritable disk nutzt und selbst die Auswirkungen auf den Cluster grundsätzlich eliminiert
• OTel bleibt für frühe Servicephasen und abnormale Zustände wichtig, etwa zur Sicherung von Logs; wenn sich der Zero-Impact-Ansatz stabilisiert, dürfte die Abhängigkeit davon jedoch weiter sinken

Weiterentwicklung und Nutzung des JSON-Typs in ClickHouse

• Der JSON-Typ ist nun offiziell als GA verfügbar und erlaubt dynamische Spaltenerzeugung pro Feld, Unterstützung mehrerer Typen und einen flexiblen Umgang selbst bei Schema-Explosion
• Da die Optimierung von JSON-Abfragen mit sehr vielen Spalten noch nicht vollständig ausgereift ist, werden parallele Speicherformen je nach Struktur eingesetzt und die Praxistauglichkeit des Map-Typs erneut bestätigt
• In Verbindung mit HyperDX lassen sich Map- und JSON-Felder automatisch extrahieren und analysieren; eine breitere Nutzung von JSON ist geplant

Fazit und kultureller Wandel

• LogHouse hat sich inzwischen von der Leistungsanalyse bis zum Echtzeit-Debugging als zentrale Observability-Plattform für den Betrieb von ClickHouse Cloud etabliert
• Kostensenkung war der Ausgangspunkt, doch mit maßgeschneiderten Werkzeugen wie SysEx, dem Zusammenspiel mit OTel und dem Ausbau einer flexiblen UI auf Basis von HyperDX findet ein technischer und kultureller Wandel statt
• Ein hochpräzises, großskaliges Datenmodell auf Basis von Wide Events schafft neuen Wert und höhere Effizienz für Engineering, Support und Datenanalyse gleichermaßen
• Auf Basis der Erfahrungen mit 100 PB und 500 Billionen Zeilen soll die Zukunft der Observability auch weiterhin aktiv mitgestaltet werden

[GN⁺]

Hacker-News-Kommentare

• Ehrlich gesagt halte ich das nicht für etwas, womit man groß angeben sollte. Dass man 100 PB an Logs speichert, ist eher ein Beleg dafür, dass man noch nicht herausgefunden hat, was wirklich aufbewahrt werden muss. Die meisten entscheidenden Informationen lassen sich mit Metriken und strukturierten Events ausreichend erfassen. Und der Rest? Detaillierte Trace-Logs, die niemand liest und die man nur anschaut, wenn es wirklich einen Ausfall gibt. Eine bessere Methode? Eine „interessebasierte Speicherpolitik“ einführen, bei der Logs, die nie in einem Alarm verwendet wurden oder drei Monate lang nie in einer Suche auftauchten, automatisch gelöscht werden. Ohne so einen Ansatz ist das hier nur ein sehr edler digitaler Müllhaufen mit etwas Komprimierung
  • Ich bevorzuge eher den gegenteiligen Ansatz: alles sammeln und erst dann filtern, wenn es nicht gebraucht wird. Debug-Logs braucht man im Alltag nicht, aber wenn man sie braucht, sind sie wirklich unverzichtbar. Wenn ein Event so selten ist, dass es sich nicht reproduzieren lässt, kann man die Daten nicht erst dann wieder sammeln. Wenn schon alles gespeichert ist, muss man es nur noch finden, und das ist aus meiner Sicht viel besser
  • Ich habe in mehreren Firmen mit Datadog gearbeitet und oft erlebt, dass bei absurden Verlängerungskosten Druck gemacht wurde, nur noch Metriken und begrenzte Events zu behalten und die Logs zu reduzieren. Das Problem ist: Wenn man vorher gewusst hätte, was passieren wird, hätte man es längst behoben. Wenn etwas seltsam ist und man herausfinden muss, was überhaupt passiert ist, braucht man detaillierte Logs sehr dringend. In der Realität kann man aber nicht wissen, welche Logs wichtig sein werden, solange die Situation nicht wiederholt auftritt
  • „Interessebasierte Speicherpolitik“ ist wirklich eine großartige Idee. Schon wenn man nur zählt, wie oft pro Logmuster darauf per Query oder Alarm zugegriffen wird, kann man daraus TTL-Richtlinien ableiten. Unser Team hat diesen Ansatz tatsächlich eingeführt, die Speicherkosten um 70 % gesenkt und trotzdem alle wichtigen Daten behalten
  • Auch der Versand von Logs ist nicht kostenlos. Vor allem in Sprachen, die Logs zur Ursachenanalyse von Crashes so schnell wie möglich auf die Platte schreiben, steigen die Kosten noch stärker. Wenn es zu viele Informationen gibt, wird es auch schwerer, die wirklich wichtigen Korrelationen zu finden, und Logs zu bereits behobenen Bugs verlieren schnell an Wert. Ich bevorzuge statistische Daten. Die lassen sich effizient aggregieren, und gerade in GIL-basierten Sprachen kann der Overhead bei OTEL mitunter übermäßig hoch sein
  • Wenn die Daten bereits gespeichert sind, ist Filtern oder Aufräumen danach aus meiner Sicht lösbar. Alles zu speichern und es bei Bedarf zu nutzen, ist besser, als es im entscheidenden Moment nicht zu haben und sich damit herumzuärgern. Natürlich setzt das voraus, dass man die Ressourcen hat, um eine solche Infrastruktur in diesem Maßstab zu betreiben
• Das gilt eigentlich nur für ClickHouse-Logs. Mit anderen Arten von Logs hat das wenig zu tun. ClickHouse selbst finde ich allerdings eine wirklich gute Lösung
  • Klingt, als wärst du auf Partys ein Riesenspaß
• Ein Punkt zur Vorsicht. Wenn ein Service in einer Crash-Loop hängt oder wegen einer Störung komplett down ist, kann man über SysEx nicht auf die benötigten Systemtabellen zugreifen und daher keine Logs einsammeln. OpenTelemetry (OTel) ist dagegen passiv, sodass sich Logs aus stdout und stderr auch dann noch erfassen lassen, wenn der Service noch nicht vollständig wiederhergestellt ist. So kann man selbst im Störungszustand Logs sammeln und bis zur Root Cause Analysis vordringen
  • Alle OTel-Projekte, die ich gemacht habe, waren aktiv aufgebaut. Daher wirkt diese Aussage auf mich nicht wie eine neue Information, sondern eher wie eine falsche oder unvollständige Erklärung
• Ich frage mich, ob „wide events“ wirklich so viel Speicherplatz verbrauchen müssen. Observability ist im Kern ein Sampling-Problem. Es reicht, den Zustand zu einem bestimmten Zeitpunkt mit möglichst wenig Speicher möglichst gut rekonstruieren zu können. Man kann entweder die Anzahl der Samples senken oder die Kompression effizienter machen. Ich glaube außerdem nicht, dass die Kompressionstechniken schon an ihre Grenzen gestoßen sind. In Daten voller Redundanz steckt sicher eine enorme niedrigdimensionale Struktur. Natürlich gibt es schon Inverted Indexes und allerlei Bäume, aber ich habe das Gefühl, dass auch experimentellere, forschungsnahe Methoden wie niedrigdimensionale Tensorzerlegung Potenzial haben. Ich komme allerdings nicht aus der Branche, also übersehe ich vielleicht etwas
• Ich habe nie mit einer ClickHouse-Skalierung in dieser Größenordnung gearbeitet. Sind Logs bei diesem Volumen überhaupt wirklich durchsuchbar? Ich weiß, dass ElasticSearch in kleinerem Maßstab gut abfragbar ist. Warum sollte man für historische Logs ClickHouse statt einfach gespeicherter JSON-Dateien verwenden?
  • Ich arbeite in genau diesem Maßstab. Die kurze Antwort: Ja, es geht. Aber die Verarbeitungskosten können jede Vorstellung sprengen. Wenn Indexierungs-, Sortier- und Clustering-Strategien schlecht sind, kann eine einzige Suche nach „Datensätzen mit dieser Zeichenkette“ schon 1 bis 10 Dollar kosten. Meiner Erfahrung nach gelten bei großen Datenmengen immer die Prinzipien „so wenig Daten wie möglich so wenig wie möglich anfassen“ und „so wenig wie möglich bewegen“. Schon ein einziger zusätzlicher Durchlauf für Serialisierung/Deserialisierung oder Disk- bzw. Netzwerk-I/O lässt die Kosten explodieren. Im Fall von OTel kann also schon ein zusätzlicher Hop über den Collector frontal gegen Effizienz verstoßen. Auf Petabyte-Skala spart man mit solchen kleinen Optimierungen aber genug Geld, um davon locker das Gehalt eines Engineers zu bezahlen, der komplexen Serialisierungscode schreibt
  • Warum man ClickHouse statt JSON-Dateien für historische Logs verwendet? Dafür gibt es mehrere Gründe. (1) Eine Log-Datenbank wie ClickHouse komprimiert spaltenweise und damit jedes Feld separat, sodass deutlich weniger Speicher benötigt wird als bei normalen JSON-Dateien, auch komprimierten. (2) Log-Datenbanken sind bei Abfragen viel schneller. 1000x schneller ist durchaus möglich, weil unnötige Daten gar nicht erst gelesen werden. Passender Link. (3) 100 PB an JSON-Dateien mit grep zu durchsuchen, ist praktisch unmöglich. Eine Log-Datenbank lässt sich horizontal skalieren, indem man einfach mehr Storage-Nodes und Speicherplatz hinzufügt
  • Es ist eine Frage von Größenordnung und Kosten. Auch unsere Firma ist an die Grenzen beim Log-Volumen gestoßen. Wenn man JSON einfach in Splunk kippt, kostet das pro Jahr über 6 Millionen Dollar. Das genehmigte Budget liegt aber nur bei 5 bis 10 % davon. Im Artikel hieß es, dass für die Verarbeitung von JSON-Logs 8.000 CPUs nötig waren, nach der Optimierung aber nur noch 90 CPUs
  • Vor 2 bis 3 Jahren war die Full-Text-Suche in ClickHouse noch etwas enttäuschend. Es ist schnell und kann auch große Datenmengen auf ElasticSearch-Niveau verarbeiten, aber je nach Einsatzfall hat sich für Bundles, Gruppierung und FTS ElasticSearch ohne vorherige Indizierung deutlich schneller angefühlt
• Observability-Extremismus wirkt wirklich wie eine neue Religion. Und sie hat auch noch sehr viel Geld
  • Wenn man bis zu unbekannten Anomalien vordringen will, gibt es dafür ehrlich gesagt keine besonders gute Alternative
  • Das Ironische ist, dass man erst Probleme dieser Art erschafft und es dann mit der Strategie verkauft: „Zahl einfach ein Abo, dann ist alles gelöst“
• Im Artikel wurde nicht erwähnt, wie lange die Logs aufbewahrt werden. Sobald ein bestimmter Zeitraum überschritten ist, erscheint es fraglich, ob man die Rohdaten überhaupt noch behalten muss, statt nur verdichtete oder aggregierte Daten
• Wenn ich nach der Arbeit mit ClickHouse wieder zu Postgres zurückkehre, fühlt sich das jedes Mal wie ein Kulturschock an. Dass der Import eines 20-GB-Dumps mehrere Minuten dauert, erscheint mir völlig absurd. Sollte das nicht in ein paar Sekunden erledigt sein?
  • Jedes Mal, wenn ich ClickHouse benutze, ist es unglaublich anstrengend. Natürlich gibt es Einsatzfälle, in denen ClickHouse gebraucht wird, und Postgres kann nicht alles ersetzen. Trotzdem habe ich das Gefühl, dass ClickHouse viele „Gefahrenstellen“ hat und Postgres in fast jeder Hinsicht besser ist, solange es nicht um einen sehr eng begrenzten Spezialzweck geht
• Leute, die Druck bekommen, wide events zu verwenden, sprechen nie darüber, wie stark die Datenkosten für Logs explodieren. Verglichen mit dem bisherigen Ansatz aus Metriken + Traces + samplebasierten Logs ist es definitiv viel teurer. Es gibt sicher Vorteile, aber die Kostenseite fehlt immer
  • Eine sauber entworfene Wide-Event-Struktur kann die Speicherkosten gegenüber traditionellen Logs sogar senken. Ein externer Request wird dann als genau ein wide event erfasst, das bereits alle Informationen für späteres Debugging oder Analysen enthält. Siehe dazu A practitioner's guide to wide events
• Mich interessiert der zentrale Trick hinter Systemen wie ClickHouse oder Dynamo. Ist das im Wesentlichen eine Art riesige Hashtabelle?
  • Es gibt zwei gemeinsame Tricks großer Datenbanken wie ClickHouse. Erstens werden Daten auf der Platte so intelligent angeordnet, dass man den Großteil ignorieren und nur die benötigten Blöcke lesen kann, etwa durch spaltenorientierte Speicherung und LSM-Baum-ähnliche Verfahren. Außerdem werden die gespeicherten Daten vollständig komprimiert, um auch Disk-I/O zu minimieren. Zweitens gibt es extremes Tuning, damit alle Ressourcen — CPU, RAM, Disk und Netzwerk — maximal ausgelastet werden. ClickHouse kann zum Beispiel pro CPU-Kern mehr als 1 Milliarde Zeilen pro Sekunde verarbeiten und skaliert linear mit der Anzahl der Kerne