OTel ersetzen und die Observability-Plattform mit Wide Events erweitern

• Das interne LogHouse von ClickHouse ist innerhalb eines Jahres von 19 PiB bzw. rund 40 Billionen Zeilen auf mehr als 100 PB unkomprimierte Logs und fast 500 Billionen Zeilen angewachsen
• Der bisherige OpenTelemetry-zentrierte Erfassungspfad wechselte zwischen JSON, OTel-Format und ClickHouse Native Format hin und her und erhöhte dadurch CPU-Kosten sowie das Risiko von Log-Verlusten
• Mit SysEx (System Tables Exporter) kopiert ClickHouse Systemtabellen bytegenau nach LogHouse und verarbeitet dabei 37 Mio. Logs/s mit 70 CPU-Kernen
• OTel bleibt weiterhin nützlich für stdout-/stderr-basierte Fehler-Logs und anbieterneutrale Standardformate, aber die zentrale ClickHouse-Telemetrie verlagert sich zu SysEx und Wide Events
• Seit der Einführung von HyperDX werden ClickHouse-native UI, Suche mit Lucene-Syntax, SQL-Analyse und schemaunabhängige Exploration kombiniert und ersetzen damit teilweise die bisherige maßgeschneiderte UI auf Basis von Grafana

---

LogHouse wächst auf 100 PB und 500 Billionen Zeilen

• LogHouse ist die interne Logging-Plattform für das Monitoring von ClickHouse Cloud und diente zuvor auch dazu, steigende Datadog-Kosten zu ersetzen
• Vor einem Jahr verarbeitete LogHouse 19 PiB unkomprimierte Daten und 37 Billionen Zeilen, heute speichert es mehr als 100 PB unkomprimierte Daten und fast 500 Billionen Zeilen
• Die gespeicherten Daten setzen sich derzeit hauptsächlich wie folgt zusammen
  • SysEx: 93,6 PB, 431 Billionen Zeilen
  • OTel: 14,5 PB, 16,7 Billionen Zeilen
• Früher lief die gesamte Telemetrie über OpenTelemetry, heute kommt der Großteil der Daten über SysEx, einen von ClickHouse entwickelten spezialisierten Exporter

Grenzen der OpenTelemetry-Pipeline

• OpenTelemetry eignete sich gut als anfängliche Standard-Pipeline, um Logs aller Pods in einer Kubernetes-Umgebung nach ClickHouse zu senden
• Die Text-Logs aus stdout von ClickHouse allein reichten für Betriebsanalysen nicht aus; in der Praxis wurden strukturierte Logs, Metriken, Ausführungsdetails, Disk-I/O und Status von Hintergrundjobs aus den system-Tabellen benötigt
• Der bisherige OTel-Log-Pfad umfasste mehrere Transformationsschritte
  • Eine ClickHouse-Instanz des Kunden schreibt Logs als JSON nach stdout
  • kubelet speichert die Logs unter /var/log/…
  • Der OTel Collector liest die Logs von der Festplatte, parst das JSON und wandelt es in eine Repräsentation im Speicher um
  • Der Collector transformiert diese erneut in das OTel-Log-Format
  • Der ClickHouse-Go-Client wandelt sie nochmals in das ClickHouse Native Format um und fügt sie in LogHouse ein
• Die reale OTel-Pipeline umfasst außerdem Edge Collector, OTLP-Übertragung, Gateway Collector und zusätzliche Verarbeitung, wodurch jeder Schritt Overhead, Latenz und Komplexität erhöht
• Mit wachsender Größe traten zwei Probleme besonders deutlich hervor
  • Native ClickHouse-Typen verschwenden CPU, wenn sie erst durch JSON- und OTel-Formate geschleust werden, und die Datentreue sinkt
  • OTel-Agents auf Kubernetes-Knoten stoßen an CPU- und Speichergrenzen und verwerfen bei Verkehrsspitzen Log-Zeilen
• Für verlustfreie Verarbeitung von 20 Mio. rows/s auf OTel-Basis wären Schätzungen zufolge insgesamt rund 8.000 CPU-Kerne für Agents und Collector nötig

SysEx: ein auf ClickHouse-zu-ClickHouse-Übertragung spezialisierter Collector

• ClickHouse entwickelte den System Tables Exporter (SysEx), der Daten direkt aus den ClickHouse-Systemtabellen von Kunden-Pods in die Tabellen von LogHouse überträgt
• SysEx führt zwischen Quelle und Ziel eine bytegenaue Kopie aus, bewahrt damit native ClickHouse-Typen und eliminiert Zwischenkonvertierungen
• Dadurch lassen sich Abfragen, die Engineers zum Debugging einer Live-Instanz nutzen, leicht auf historische Daten der gesamten Flotte in LogHouse übertragen
  • Das Tabellenschema bleibt identisch, ergänzt nur um Enrichment-Spalten wie Pod-Name oder ClickHouse-Version
• Die Architektur besteht aus einem SysEx-Scraper-Pool und einem Hash Ring
  • Der Hash Ring weist Kunden-Pods bestimmten Scraper-Replikas zu und verteilt so die Last
  • Der Scraper führt SELECT auf der Systemtabelle des Quell-Pods aus und streamt die Daten nach LogHouse
  • Der Scraper koordiniert die Byte-Übertragung zwischen Quelle und Ziel ohne Deserialisierung
• Um verpasste Buffer-Flushing-Vorgänge in Systemtabellen zu vermeiden, verwendet SysEx ein gleitendes Zeitfenster und fragt typischerweise mit 5 Minuten Verzögerung gegenüber Echtzeit ab
• Da das Standardverhalten des Go-ClickHouse-Clients Daten in native Go-Typen konvertiert, hat ClickHouse eine Funktion zur Umgehung des internen Marshallings zu clickhouse-go beigetragen
• SysEx folgt einem Pull-basierten Modell und benötigt daher keine schwere Pufferung wie OTel; selbst wenn LogHouse vorübergehend nicht verfügbar ist oder die Quell-Telemetrie sprunghaft ansteigt, kann durch erneutes Scraping historischer Fenster ein Backfill erfolgen

Dynamische Schemata und Zustands-Snapshots

• SysEx setzt voraus, dass Quell- und Zielschema übereinstimmen, doch die Schemata der ClickHouse-Systemtabellen ändern sich häufig durch neue Metriken und zusätzliche Spalten
• Zur Handhabung prüft SysEx beim Auftreten einer Systemtabelle deren Schema, hasht es und kontrolliert, ob in LogHouse bereits eine Tabelle mit demselben Schema existiert
  • Falls ja, wird in die bestehende Tabelle geschrieben
  • Falls nein, wird eine neue Schemaversion wie text_log_6 erzeugt
• Zur Abfragezeit werden mehrere Schema-Varianten mit der Merge table engine von ClickHouse zu einer logischen Sicht zusammengeführt
• Die Merge table engine kann nur kompatible Spalten auswählen oder Abfragen auf Tabellen begrenzen, die die angeforderten Spalten enthalten, sodass sich Schemaänderungen ohne manuelle Pflege abfragen lassen
• ClickHouse erfasst auch In-Memory-Systemtabellen wie system.processes periodisch als Snapshots und speichert sie in LogHouse
• Diese Snapshots dienen dazu, Cluster-Zustand, Tabellenschemata und Cluster-Konfigurationen zu einem bestimmten historischen Zeitpunkt zu analysieren

Analyse über die gesamte Flotte und Effizienzkennzahlen

• Dank SysEx lassen sich Advanced Dashboard queries, die Kunden zur Überwachung einzelner ClickHouse-Instanzen nutzen, gleichzeitig über die gesamte Flotte von Kundeninstanzen ausführen
• Bei Release-Analysen werden Diagnoseabfragen vor und nach Deployments ausgeführt, um Muster der Query-Performance, Trends bei der Ressourcennutzung und Änderungen der Fehlerraten in Echtzeit auf Flottenebene zu sehen
• Support-Dashboards korrelieren Advanced-Dashboard-Abfragen zusammen mit Netzwerk-Logs, Kubernetes-Events sowie Data-Plane- und Control-Plane-Events in derselben Oberfläche
• Der Effizienzvergleich aus Sicht von LogHouse sieht wie folgt aus
  • OTel Collectors: mehr als 800 CPU-Kerne für 2 Mio. Logs/s
  • LogHouse Scrapers (SysEx): 70 CPU-Kerne für 37 Mio. Logs/s
• Bei den wichtigsten Datenquellen erhöhte SysEx das Event-Volumen um das 20-Fache, während der CPU-Footprint auf weniger als 10 % des bisherigen Werts sank und Events am Edge nicht mehr verworfen werden

Bereiche, in denen OpenTelemetry weiterhin nötig ist

• OpenTelemetry bleibt die Standardoption für ClickStack, weil es ein standardisiertes anbieterneutrales Format und eine gute Onboarding-Erfahrung für neue Nutzer bietet
• SysEx ist stark an das Innere von ClickHouse gekoppelt und basiert auf Pull-Abfragen gegen Live-Systemtabellen; befindet sich ein Service in einer Crash-Loop oder ist er ausgefallen, können keine Daten gescrapt werden
• OpenTelemetry erfasst dagegen passiv Logs, die auf stdout und stderr ausgegeben werden, und kann dadurch auch während Störungen Logs sammeln, selbst wenn der Service nicht vollständig gesund ist
• ClickHouse betreibt OpenTelemetry weiterhin auf allen ClickHouse-Services, verändert aber den Erfassungsumfang
  • Früher wurden sogar Trace-Level-Logs ingestiert
  • Heute werden nur noch Logs ab Info-Level erfasst
• Seit dieser Änderung benötigen OTel Collector und Gateway deutlich weniger Ressourcen und bleiben als kleinere Pipeline mit den bereits genannten 2 Mio. Log-Zeilen/s erhalten

HyperDX und die ClickHouse-native Explorationserfahrung

• Die erste UI von LogHouse war eine auf Grafana aufgebaute benutzerdefinierte Observability-Oberfläche, doch mit zunehmender SysEx- und Wide-Column-Telemetrie wurde eine stärker in ClickHouse integrierte UI notwendig
• HyperDX bietet eine ClickHouse-native UI für Log- und Trace-Exploration, Korrelation und Analysen im großen Maßstab
• Dank Lucene-Syntax lassen sich Abfragen einfacher formulieren, während für komplexe Event-Analysen weiterhin SQL genutzt werden kann
• Der schemaunabhängige Ansatz von HyperDX v2.0 verlangt keine einzelne fest vorgegebene Log-Tabellenstruktur
  • Er verarbeitet die standardisierten, aber wandelbaren Datenformate der OpenTelemetry-Pipeline
  • Ebenso unterstützt er spezialisierte Wide-Column-Tabellen von SysEx und anderen Custom Exportern ohne vorheriges Schemawissen oder komplexe Grok-Patterns
• Grafana spielt in LogHouse weiterhin eine Rolle
  • Interne Apps auf Grafana-Basis verlangen die Angabe eines Namespace, kennen dadurch den Speicherort der dienstspezifischen Daten und routen Abfragen an die passende ClickHouse-Instanz
  • Bestehende Dashboards und Alerts auf Basis von Prometheus-Metriken verbleiben weiterhin in Grafana
  • Hochrangige Metriken wie kube_state_metrics eignen sich zwar weniger für tiefgehende Untersuchungen, aber gut für Alerting

Wide Events und High-Cardinality-Observability

• Die Einführung von SysEx führte weg von stdout-zentrierter Log-Erfassung hin zu einem Modell auf Basis von Wide Events aus Systemtabellen und High-Cardinality-Daten
• ClickHouse bezeichnet dies nicht als Observability 2.0, sondern als Kombination aus LogHouse und ClickStack
• Anstelle des traditionellen Drei-Säulen-Modells speichert dieses Modell Telemetrie aus vielen Quellen mit hoher Kardinalität in einem zentralen Warehouse
• Jede Zeile enthält reichen Kontext wie Query-Identifier, Pod-Name, Versionsmetadaten oder Netzwerkdetails; Dimensionen werden nicht voraggregiert oder verworfen, nur um Beschränkungen eines Metrik-Stores einzuhalten
• Anstatt beim Ingest zusammenzufassen, werden Rohdaten unverändert gespeichert und Aggregationen auf die Query-Zeit verschoben
• Der Unterschied zu Prometheus besteht darin, dass alle Datenpunkte gespeichert werden
  • Felder wie insertDuration werden nicht voraggregiert, sondern jeder Wert bleibt zusammen mit den zugehörigen Dimensionen erhalten
  • Würde Prometheus Zeitreihen für alle Label-Kombinationen speichern, käme es zu einer Kardinalitätsexplosion
  • Die Voraggregation in Histogrammen begrenzt zwar den Ressourcenverbrauch, macht es aber schwer zu fragen, zu welcher Instanz, Tabelle und welchem Zeitfenster ein bestimmter Spike bei Inserts gehörte
• Auch Elasticsearch förderte Wide Events und flexible Dokumentstrukturen, doch das spaltenorientierte Design von ClickHouse ermöglicht effiziente Speicherung und Abfrage von Event-Daten mit hoher Kardinalität und hohem Volumen im großen Maßstab

Data-Science-Tools und SQL-Analyse

• Aus einem einzelnen Wide Event lassen sich mehrere Eigenschaften visualisieren, und von einem bestimmten Punkt im Diagramm kann direkt zu den Raw Logs zurückgesprungen werden
• ClickHouse bietet Integrationen für Datenvisualisierung und Sprach-Clients, sodass SQL-basierte Tools wie Plotly, Jupyter Notebook, Hex, Bokeh und Evidence genutzt werden können
• Die Suche mit Lucene-Syntax in HyperDX eignet sich für schnelle Suche und Filterung, für komplexe Fragen wird jedoch SQL benötigt
• Mit ClickHouse SQL lassen sich Joins, zeitbasierte Operationen und Transformationen ausdrücken
  • Ein Beispiel ordnet im Kubernetes-Event-Stream Killing- und Created-Events desselben Containers mit ASOF JOIN einander zu, um die Zeit zwischen Terminierung und Neustart zu berechnen
  • Die Beispielabfrage verarbeitete 17,78 Mio. Zeilen und 581,49 MB in 0,099 Sekunden bei einem Peak-Speicher von 272,88 MiB
• Benötigte Metriken müssen nicht vorab als Komponenten erstellt und ausgerollt werden, sondern können zur Query-Zeit aus dem Wide-Events-Warehouse abgeleitet werden

Zusätzliche Datenquellen in LogHouse

• LogHouse ergänzt auf Wunsch der Engineering- und Support-Teams weitere Daten-Sinks auf Basis von Wide Events
• kubenetmon: ein Open-Source-Tool zur Überwachung von Kubernetes-Netzwerken, das Linux conntrack nutzt, um L3/L4-Verbindungsdaten sowie Byte- und Paketanzahlen zu erfassen
  • Es unterstützt Forensik, Attribution zu Workloads und Pods sowie Kostenmetriken wie Cross-Region-Egress
  • Projekt: https://github.com/ClickHouse/kubenetmon
• Kubernetes Event Exporter: Ein populärer Exporter wurde geforkt und um einen nativen ClickHouse-Sink erweitert, um Ereignisse aus der Kubernetes-API in großem Maßstab zu analysieren
  • Fork: ClickHouse/kubernetes-event-exporter
  • Künftig sollen nicht nur Events, sondern das gesamte Kubernetes-Objektmodell in LogHouse ingestiert und Snapshots aller Änderungszeitpunkte gespeichert werden
• Control Plane Data: Es werden Betriebsdaten aus dem Control-Plane-Bereich erfasst, die bisher noch nicht in LogHouse onboarded waren
• Real User Monitoring (RUM): Ein laufendes Projekt, bei dem Frontend-Performance-Metriken aus dem Browser der Nutzer über ein öffentliches Gateway in die OTel-Pipeline gesendet werden
• Istio Access Log: Es werden HTTP-Traffic-Daten aus dem Istio Service Mesh ingestiert, um Request-/Response-Muster, Latenzen und Routing-Entscheidungen zu erfassen
  • In Kombination mit system.query_log und den Netzwerk-Flows von kubenetmon werden SQL-Abfragen, HTTP-Requests und Paketflüsse gemeinsam analysiert

Nächste Schritte: Zero-Impact-Scraping und JSON

• SysEx-Scrape-Abfragen sind durch strikte Speicherlimits begrenzt, was bei Kunden Sorgen auslösen kann, wenn sie dies in Logs und Metriken sehen
• ClickHouse untersucht derzeit Zero-Impact-Scraping, also ein Verfahren ohne Abfragen auf dem Live-System
  • Ein vielversprechender Ansatz ist die Nutzung des einfachen wiederbeschreibbaren S3-Datenträgers, auf den ClickHouse bereits Service-Logs schreibt
  • Wenn der SysEx-Worker-Pool die festplattenbasierten Log-Tabellen direkt mountet, könnten Abfragen gegen laufende ClickHouse-Instanzen umgangen werden
• Gelingt dieser Ansatz, bleiben die heutigen Vorteile wie natives Format, hohe Datentreue und minimale Transformation erhalten, während zugleich die wahrgenommene Betriebsbelastung sinkt
• Der JSON-Typ von ClickHouse hat in Version 25.3 GA erreicht, erstellt beim Auftreten neuer Felder dynamisch Spalten mit passendem Typ und verarbeitet Felder mit mehreren Typen sowie Schema Explosion
• LogHouse bewertet derzeit, wie gut JSON zu den großskaligen Observability-Zugriffsmustern passt
  • Eine Stringsuche über ein komplettes JSON-Blob kann Tausende von Spalten scannen
  • Ein möglicher Workaround ist die Speicherung von strukturierten Daten zusammen mit dem rohen JSON-String
  • Die meisten Log- und Resource-Attribute sind klein und stabil, weshalb der Map-Typ weiterhin geeignet ist
  • HyperDX wandelt Map-Zugriffe automatisch in die Funktion JSONExtract um