Warum ClickHouse im Observability-Krieg die Nase vorn hat

• Logs sind – anders als die grep-Erfahrung in kleinen Systemen – in der Observability die am schwersten zu handhabenden Daten, sobald Services und Konsumenten zunehmen und große, unstrukturierte, unvorhersehbare Queries zusammenkommen
• ClickHouse begann als Datenbank für Clickstream-Analysen, passt aber gut zu Nutzungsmustern von Logs: hohes Volumen, append-lastig, zeitlich geordnet, aggregierende Lesezugriffe
• Die spaltenorientierte Speicherung liest nur die benötigten Spalten und erreicht bei realen Observability-Daten 10–14-fache Kompression, im Gegensatz zu 2–3x bei Elasticsearch
• Bei 1 TB/Tag sind mehrere Stacks möglich, doch je stärker das Volumen auf 5 TB/Tag und 10 TB/Tag wächst, desto stärker ändern sich Struktur oder Kosten bei Elasticsearch, LGTM und Datadog; ClickHouse skaliert vor allem durch Hinzufügen von Shards
• ClickHouse verlangt anfangs Schema-Design und den Umgang mit der Komplexität der Query Engine, aber das Betriebsmodell gerät auch bei Wachstum um ein- bis zweistellige Faktoren nicht stark ins Wanken

---

Warum Logs in der Observability schwierig sind

• Entwickler haben durch den Umgang mit Logs in kleinen Systemen per grep, jq und tail -f die Erwartung, Logsuche müsse sehr schnell funktionieren
• Dieser Ansatz funktioniert gut, wenn das System klein ist, die Logmenge gering ist und die Person, die die Queries ausführt, die Logzeilen selbst geschrieben hat
• Mit zunehmender Größe entstehen gleichzeitig Schema Drift, Kardinalitätsexplosion, teamübergreifende Konsumenten und Anforderungen an Dashboards
• Logs werden nicht nur von Entwicklern genutzt
  • Der Kundensupport muss Vorfälle wie eine fehlgeschlagene Zahlung eines bestimmten Nutzers finden
  • Datenteams können Business-Dashboards auf Logzeilen aufbauen, die Backend-Engineers ändern können
  • On-Call-Verantwortliche erwarten, dass ein Suchfeld direkt funktioniert, ohne eine neue Query-Sprache oder Index-Patterns lernen zu müssen
• Technisch sind die Datenmengen groß, die Formate unregelmäßig, und es ist schwer vorherzusagen, welche Queries gestellt werden
• Entwickler wollen Unmittelbarkeit, beliebige Operationen und lockere Schemata; nichttechnische Nutzer wollen stabile Dashboards und eine fehlertolerante UI

Warum die Struktur von ClickHouse zu Logs passt

• ClickHouse wurde bei Yandex entwickelt, um groß angelegte Analyse-Queries auf Clickstream-Daten zu verarbeiten
• Es wurde nicht speziell für Observability entwickelt, aber Clickstream- und Observability-Daten haben viele Gemeinsamkeiten
  • große Datenmengen
  • append-lastige Schreibvorgänge
  • Fokus auf zeitliche Reihenfolge
  • überwiegend aggregierende Lesezugriffe
  • Nutzungsmuster, bei denen gelegentlich bestimmte Datensätze gefunden werden müssen
• Auch beim Betrieb gibt es mehrere Optionen
  • Direktes Ausführen per Helm chart ist möglich
  • Man kann das ClickHouse-Plugin von Grafana, die eigene Web-UI oder ein selbst gebautes Frontend verwenden
  • Mit dem ClickHouse exporter des OpenTelemetry Collector lassen sich OTLP-Daten direkt einspeisen und die anfängliche Schemaverwaltung delegieren
• ClickHouse ist darauf ausgelegt, Milliarden von Zeilen zu scannen und sehr große Datenmengen aufzunehmen
• Die Query-Sprache ist keine neue Spezial-Sprache, sondern SQL

Der Unterschied durch spaltenorientierte Speicherung und Kompression

• Logs sind ihrer Datenform nach nahezu append-only
  • Logzeilen werden nicht aktualisiert
  • Einzelne Löschungen kommen kaum vor; nach Ablauf der Aufbewahrungsfrist wird in großen Mengen gelöscht
  • Sie treffen meist in zeitlicher Reihenfolge ein, sind aber nicht vollständig sortiert
• Lesemuster ändern sich bei Störungen oder Analysen explosionsartig
  • Tage lang schaut niemand hin, während einer Störung möchte man dann aber Milliarden Einträge in Sekunden durchsuchen
  • Häufig betrachtet man mehrere Felder in einem engen Zeitfenster oder aggregiert über einen breiten Zeitraum mit wenigen Filtern
  • Das Muster, wie bei einer Transaktionsdatenbank eine einzelne Zeile anhand einer bestimmten ID zu finden, ist selten
• Zeilenorientierte Datenbanken wie Elasticsearch, Postgres und MySQL speichern alle Felder einer Logzeile gemeinsam
  • Selbst wenn von 40 Feldern nur 3 benötigt werden, werden von der Platte 40 gelesen
• ClickHouse speichert jede Spalte separat
  • Eine Query, die nur timestamp, service und status_code nutzt, liest nur diese Spalten
  • Bei Observability-Daten mit Dutzenden Attributen, aber Queries, die nur 3–4 Spalten verwenden, wird der Unterschied bei der gelesenen Datenmenge groß
• Spaltendaten lassen sich gut komprimieren, weil Werte innerhalb derselben Spalte einander ähneln
  • Eine service_name-Spalte kann auch bei Milliarden Zeilen nur einige Hundert eindeutige Strings enthalten
  • Bei realen Observability-Daten sieht man häufig 10–14-fache Kompression
  • Das steht in deutlichem Gegensatz zu 2–3x bei Elasticsearch

Bei 1 TB/Tag sind die meisten Stacks möglich

• Bei 1 TB/Tag sind moderne Observability-Stacks im Allgemeinen brauchbar; es gibt Unterschiede, aber der Schmerz ist noch nicht groß

• Elasticsearch

  • Der Betrieb ist mit einem relativ einfachen Elasticsearch-Cluster und Logstash als Buffer möglich
  • Volltextsuche ist eine Stärke von Elasticsearch und funktioniert in diesem Maßstab gut
  • Bei gemischten Daten besteht das Risiko einer mapping explosion, daher sollte man dynamic mapping deaktivieren oder Templates sorgfältig definieren
  • Eine ILM-Policy von hot → warm → delete ist auch in diesem Maßstab unverzichtbar
  • Die Kosten liegen grob bei 6–9 Tsd. US-Dollar pro Monat

• LGTM

  • Alloy bündelt die Sammlung in einem einzigen Daemon
  • Loki funktioniert gut, wenn Entwickler darin geschult werden, nützliche Labels zu setzen
  • Mimir und Tempo erfüllen im Großen und Ganzen die erwarteten Rollen
  • Die Kosten liegen grob bei 3,5–5 Tsd. US-Dollar pro Monat

• Datadog

  • Bei 1 TB/Tag ist die Nutzbarkeit gut: Agents installieren und Dashboards ansehen
  • Probleme wie metered pipeline, die Unterscheidung zwischen indexed und ingested logs sowie Kosten durch custom metrics cardinality werden sichtbar, sind in diesem Maßstab aber beherrschbar
  • Die Kosten liegen grob bei 45–75 Tsd. US-Dollar pro Monat; da Verhandlungspreise stark variieren, sollte man die Zahlen nur als grobe Größenordnung sehen
  • Die Preislogik von Datadog lautet sinngemäß, dass man einen dedizierten Engineer einspart

• ClickHouse

  • Bei 1 TB/Tag ist ClickHouse nicht weniger komplex als die anderen Optionen
  • Anfangs ist Schema-Design nötig, und der ORDER BY-Key ist sehr wichtig
  • Mit ZSTD und passenden Codecs lassen sich 10–14x Kompression erreichen
  • Der Altinity Operator übernimmt die keeper coordination, und das Ganze läuft mit etwa 7 Pods
  • Es gibt kein natives PromQL; Metric-Workflows laufen über das Grafana-Plugin oder über chproxy und Adapter
  • Die Kosten liegen grob bei 1,5–2,5 Tsd. US-Dollar pro Monat

Bei 5 TB/Tag werden die strukturellen Unterschiede größer

• Bei 5 TB/Tag wird die Wachstumskurve bei den meisten Stacks steiler, und der Abstand zu ClickHouse wird deutlicher

• Elasticsearch

  • Kafka wird faktisch erforderlich
  • Schreibt man direkt nach Elasticsearch, können bulk rejects und backpressure bei Traffic-Spitzen den Cluster zu Fall bringen
  • Bei einer target shard size von 50 GB entstehen inklusive Replica etwa 200 Shards pro Tag, und die Größe des cluster state wird selbst zum Problem
  • Wegen searchable snapshots und frozen tier wird eine kommerzielle Elastic-Lizenz fast unvermeidlich
  • Die Kosten liegen vor Lizenzkosten bei 40–55 Tsd. US-Dollar pro Monat

• LGTM stack

  • Es wird ein Microservices-Modus mit mehr als 65 Pods und drei separaten Systemen betrieben
  • Jedes System hat eine compaction pipeline, einen hash ring und einen memcached tier
  • Der gossip/memberlist ring wird zu einem realen Betriebsthema
  • Für ingester rollouts ist eine Anpassung von -ingester.autoforget-unhealthy nötig; macht man es falsch, entstehen Datenverlust oder Duplikate
  • Die Kosten liegen grob bei 22–32 Tsd. US-Dollar pro Monat

• Datadog

  • Da man keine Server selbst betreibt, bleibt die Betriebskomplexität niedrig
  • Stattdessen wird ein eigenes Pipeline-Team nötig, das Datadog-Kosten senkt
  • Es entstehen Mechanismen wie exclusion filter, sampling rule, cardinality cap und tag allow-list
  • Die Kosten liegen je nach Aggressivität des Pipeline-Teams grob bei 180–350 Tsd. US-Dollar pro Monat
  • Die Beziehung wird eine, in der man Rechnungsdokumente des SaaS-Anbieters studieren muss, um Kosten zu senken

• ClickHouse

  • Die größte Veränderung ist das Hinzufügen von Shards
  • Operator, Query Engine, Query-Sprache und mentales Modell bleiben unverändert
  • Nach dem Hinzufügen von Shards erfolgt Rebalancing manuell; die meisten Teams umgehen das durch Vorab-Provisionierung oder Weighting in Distributed tables
  • Materialized views für Dashboard-Rollups werden von „nice to have“ fast zu einer Notwendigkeit
  • Die Kosten liegen grob bei 7–11 Tsd. US-Dollar pro Monat

Bei 10 TB/Tag trennen sich die Betriebsmodelle

• 10 TB/Tag ist ein Maßstab, bei dem viele Lösungen die Betriebslast nur schwer tragen können

• Elasticsearch

  • Man betreibt drei getrennte Elasticsearch-Cluster für logs, metrics und APM und verbindet sie per Cross-Cluster Search
  • Die Kosten für hot-tier NVMe dominieren die Rechnung
  • In diesem Maßstab beginnen Teams, Alternativen ernsthaft zu evaluieren; viele aktuelle ClickHouse-Migrationen kommen von hier
  • Die Kosten liegen zusätzlich zur kommerziellen Lizenz grob bei 95–140 Tsd. US-Dollar pro Monat
  • Für den Betrieb von Elasticsearch in diesem Maßstab braucht man echte Experten

• LGTM

  • Erforderlich sind etwa 180 oder mehr Pods, eine zone-aware Konfiguration, split-and-merge compaction, Limits pro Tenant und shuffle sharding zur Vermeidung von noisy neighbors
  • Ein dediziertes Observability-platform-Team mit 3–5 Personen wird nahezu erforderlich
  • Die Kosten liegen grob bei 55–85 Tsd. US-Dollar pro Monat

• Datadog

  • In dem Sinne, dass keine Server selbst betrieben werden müssen, bleibt es weiterhin einfach, aber die Monatsrechnung kann sechs- bis siebenstellig werden
  • Die Organisation wird wahrscheinlich ein Preprocessing-Pipeline-Team aufbauen, um die Rechnung zu senken
  • Viele Unternehmen in diesem Maßstab nutzen Datadog für APM und hochwertige Metriken und verlagern logs in eine selbst gehostete Hybrid-Konfiguration
  • Das Ziel für Self-Hosting wird zunehmend ClickHouse
  • Es entsteht eine Struktur, in der Datadogs Einfachheit, Pipeline-Komplexität und ein zweiter selbst gehosteter Stack gleichzeitig existieren
  • Die Kosten variieren stark und können über 1 Mio. US-Dollar pro Monat liegen

• ClickHouse

  • Das Grundbild ist dasselbe wie bei der 1-TB/Tag-Konfiguration; der Unterschied liegt in der größeren Zahl von Shards
  • Materialized views für Rollups werden nicht mehr optional, sondern Pflicht
  • Fehler im Schema-Design von vor zwei Jahren können sich in diesem Maßstab schmerzhaft zeigen
  • Rebalancing nach dem Hinzufügen von Shards bleibt manuell
  • Die meisten Teams provisionieren im Voraus oder nutzen clickhouse-copier und dual-write migration
  • Bei sehr bursty ingest wird Kafka als Buffer nützlich, ist aber nicht zwingend erforderlich
  • Die Kosten liegen grob bei 18–28 Tsd. US-Dollar pro Monat

Auswahlkriterien

• Bei 1 TB/Tag funktioniert im Großen und Ganzen jeder Stack, daher kann man wählen, was das Team bereits kennt
• Die wichtige Frage ist nicht, ob es heute funktioniert, sondern ob es in zwei Jahren, wenn die Datenmenge um den Faktor 5 und das Team um den Faktor 2 gewachsen ist und die ursprünglichen Designer gegangen sind, noch dieselbe Form beibehält
• Elasticsearch und LGTM verändern mit wachsender Größe ihre Struktur
• Datadog ist betrieblich einfach, verändert sich kostenseitig aber zu einem Modell, das ein separates Accounting- und Pipeline-Team erfordert
• ClickHouse wächst durch Hinzufügen von Shards in die Breite
• Der Preis dafür ist, dass man anfangs Schema-Design und die Komplexität der Query Engine akzeptieren muss
• Zahlt man diesen Preis, bleibt die Erfahrung für Entwickler und Betreiber im Großen und Ganzen erhalten, auch wenn die Datenmenge um mehr als eine Größenordnung wächst

[GN⁺]

Meinungen auf Lobste.rs

• Ein Startup, bei dem ich 2019 kurz gearbeitet habe, hat ziemlich viele beeindruckende Dinge gebaut und mir damals ein wenig ClickHouse gezeigt, was einen wirklich starken Eindruck hinterlassen hat.
  Bis dahin dachte ich, dass man selten etwas anderes als PostgreSQL brauchen würde, aber ClickHouse machte Lust darauf, es auszuprobieren.
  ElasticSearch, InfluxDB und Ähnliches hatte ich auch genutzt, fand sie aber immer eher enttäuschend; vermutlich, weil sie jeweils ihre eigene Abfragesprache von Grund auf neu erfunden haben. ClickHouse dagegen setzt auf vertrautes SQL und erweitert es nur dort sinnvoll, wo es nötig ist.
  Wie bei erfolgreichen Produkten spürt man bei ClickHouse die Qualität der Implementierung und die Rücksicht auf Nutzer, und selbst kleine Details sind standardmäßig gut getroffen.
  In meiner aktuellen Firma nutzen wir HyperDX. Metrik-Graphen sind etwas umständlich, aber Tracing funktioniert ziemlich gut. Ich dachte, Tracing würde schnell zu einem unverzichtbaren Werkzeug werden und die Produktivität stark erhöhen, aber da es nicht so stark angenommen wird wie erwartet, scheint es doch nicht ganz so spielverändernd zu sein. Trotzdem ist es erfreulich, dass ClickHouse in diesem Bereich zu einem zentralen Player wird und man sich dadurch mit weniger anderen Dingen beschäftigen muss.

  • Tracing in eine Organisation einzuführen, die sich bisher nur mit Metriken und Logs durchgeschlagen hat, ist meiner Erfahrung nach ein ziemlich steiler Anstieg.
    Es braucht viel Überzeugungsarbeit, man muss Anwendungsfälle sammeln und in mühsamer Arbeit direkt zeigen, dass man nun Dinge tun kann, die vorher nicht möglich waren, und wie viel einfacher schwierige Aufgaben geworden sind.
    Auch technisch muss die Einführung so reibungslos wie möglich sein, was je nach Stack und Situation selbst ein großer Aufwand sein kann, und diese Last fällt meist auf die Person zurück, die die Einführung vorantreibt.
    Es ist im Grunde nichts anderes als eine breit angelegte organisatorische Initiative, und es hilft, wenn es ein oder zwei echte Überzeugungstäter mit persönlicher Glaubwürdigkeit gibt, die das im Unternehmen verbreiten.
  • Ich frage mich, ob damit die JSON-Abfragesprache von ElasticSearch gemeint ist. ElasticSearch unterstützt multiple query languages, darunter auch einen SQL-Dialekt.
    Wie gut diese Unterstützung ist, weiß ich nicht; selbst genutzt habe ich nur die JSON-Abfragesprache, und von den anderen habe ich gerade erst erfahren.
    Als Abfragesprache ist SQL nicht perfekt. Dass man Klauseln nicht wiederholen und nicht in beliebiger Reihenfolge schreiben kann, ist nervig, aber SQL ist trotzdem eine sehr gute Sprache.

• Meine Erfahrung ähnelt der des Autors. Die Skalierbarkeit von ClickHouse ist erstaunlich gut, und wenn man es selbst betreibt, läuft es eher darauf hinaus, einfach mehr Cores hinzuzufügen.
  Die anfänglichen Einrichtungskosten können etwas höher sein, aber das Schema wird im Grunde durch den OTel-Export weitgehend vorgegeben. Damit kann man starten und dann Spalten und materialisierte Views herausziehen, wenn man mehr Abfrageleistung braucht.
  Dafür muss man sich weniger Sorgen um Skalierung machen, kann alle Daten direkt für Analysen nutzen und sogar Metriken aus Traces ableiten.
  Allerdings muss ein anderes Puzzleteil, die Visualisierung, noch deutlich besser werden. Grafana ist für die Anzeige und Analyse von Traces im Vergleich zu Tools wie Honeycomb nicht optimal. Ich hoffe, dass einer der bestehenden Player das bald löst, vielleicht HyperDX.

• Dieser Artikel wirkte zunächst so, als würde er mit einer überzeugenden Einleitung stark beginnen, fiel dann aber im Abschnitt, in dem verschiedene Firmen analysiert werden, in einen listenartigen Text mit deutlichem Low-Effort-LLM-Stil auseinander.
  Als ich auch die Einleitung noch einmal kritischer las, sah ich dort zunehmend dieselben Spuren.
  Das ist ein Muster, das ich in letzter Zeit auf Lobsters immer häufiger sehe, daher möchte ich es eher als kurzen Gedanken zu einer allgemeineren Beobachtung stehen lassen, statt diesen konkreten Artikel anzugreifen.
  Persönlich habe ich nicht sehr viel Erfahrung mit Observability-Tools, daher fand ich Teile des Artikels unabhängig von der Schreibweise interessant. Aber ich möchte nicht dem Fehler folgen, bei Themen, mit denen ich nicht vertraut bin, einem LLM zu glauben und bei vertrauten Themen zu sagen, LLM-Texte seien flawed.
  Deshalb bin ich mir nicht sicher, ob man diesen oder die meisten ähnlichen Artikel sachlich für verlässlich halten kann. Es scheint klar, dass der Autor große Teile des Denkens an die Maschine ausgelagert hat, auch wenn der ursprüngliche Gedanke ziemlich klar gewesen zu sein scheint.
  Auch beim Programmieren muss ein klarer Gedanke in meinem Kopf erst durch den Prozess, tatsächlich ein Programm zu schreiben, an Edge-Case-Tests zu scheitern oder den Typecheck nicht zu bestehen, bevor ich überzeugt bin, dass grundsätzlich etwas fehlt.
  Beim Schreiben ist es genauso: Wenn man seine Argumente nicht selbst formuliert, das Ganze zusammensetzt und Gegenargumente sorgfältig berücksichtigt, liefert man meiner Ansicht nach keinen Wert über den ursprünglichen klaren Gedanken hinaus.
  Das ist vermutlich auch der Punkt, den Leute meinen, die sagen, man solle Code so schreiben, dass man nur Prompts für künftige LLMs speichert.
  Aber wenn Programmieren oder Schreiben vollständig so abläuft, gibt man nicht nur das Denken auf, sondern auch Strenge, Sorgfalt und Respekt.
  Ich weiß nicht genau, was Lobsters dagegen tun sollte. Das vibecoding-Tag wirkt schon jetzt wie eine überlastete Lösung. Vielleicht wäre aber ein LLM-Geruch-Tag hilfreich, als Signal, auf mangelnde Strenge zu achten.

  • Ich wollte das auch nicht als Top-Level-Kommentar schreiben, aber als ich den Artikel öffnete, war es einfach LLM-Floskelware, und die Zeit, die ich mit dem Anfang verbracht habe, fühlte sich etwas verschwendet an.
  • Aus Sicht von jemandem, der ein paar Observability-Tools genutzt hat, wirkte der Artikel ziemlich klar und vernünftig.
    Die Kernaussage ist, dass jedes Produkt anders skaliert, und er zeigt mit Diagrammen und konkreten Erklärungen, was bei den jeweiligen Größenordnungen passiert.
    Wenn es Stellen gab, an denen sich das für dich eindeutig nach aufgegebenem Denken anfühlte, wären Beispiele interessant.
  • Matthew kennt sich zumindest mit Observability ziemlich gut aus. Er war Tech Lead bei Braintree und ist jetzt Principal bei SYBO, bekannt durch Subway Surfers.
    Auch die Stellen mit Schimpfwörtern lassen bis zu einem gewissen Grad seine eigene Stimme erkennen.
    Wenn man den Text in GPTZero steckt, kommt zwar eine LLM-Wahrscheinlichkeit von 71 % und 28 % gemischt heraus. Wegen der Zeichenbegrenzung habe ich allerdings die Einleitung abgeschnitten, die sich am menschlichsten las.
    Die Abneigung verstehe ich, aber es wirkt eher wie ein Text, der tatsächlich geprüft und iterativ überarbeitet wurde, ohne LLM-artige Formulierungen herauszufiltern oder den Ton zu optimieren. Inzwischen reicht es nicht mehr, einfach keine Gedankenstriche zu verwenden, um den Geruch zu vermeiden.

• Mich würde von Leuten mit Honeycomb-Erfahrung interessieren, wie es in diesen Kontext passt.
  Soweit ich weiß, nutzt auch Honeycomb ein spaltenorientiertes Speicherformat und verlässt sich stark auf Kompression und Bucketing, um beim Lesen große Datenmengen zu überspringen. Meines Wissens nutzt es keinen invertierten Index wie Elastic oder Datadog, und ich meine, dass Datadog intern ebenfalls Elastic betreibt.

  • Ich erinnere mich, dass Honeycomb-Mitgründerin Charity Majors vor ein paar Jahren auf Twitter gesagt hat: Wenn es ClickHouse damals bei der Gründung des Unternehmens schon gegeben hätte, hätten sie vermutlich einfach das verwendet.
    Allerdings bin ich nicht sicher, wie stark sich die beiden Systeme konzeptionell tatsächlich überschneiden. Es wäre interessant zu wissen, ob das Problemfeld natürlicherweise zu ähnlichen Ansätzen geführt hat; persönlich würde ich vermuten, dass es so war.

• Manche Leute könnten das unangenehm finden, aber die Verwendung bestimmter Wörter empfand ich als so ablenkend, dass ich sie einfach per Suchen und Ersetzen durch Wörter ersetzt habe, die mich nicht stören, und danach war der Artikel viel besser.
  Welche Wörter es waren, sage ich nicht, aber es sind Ausdrücke, die zunehmend ungenau verwendet werden und mich deshalb stören. Es war schön, dass der Text allein durch ein simples Suchen und Ersetzen angenehm zu lesen wurde.