ClickStack – die Open-Source-Alternative zu Datadog, gebaut mit ClickHouse und HyperDX

 (clickhouse.com)
4 Punkte von GN⁺ 2025-06-07 | 1 Kommentare | Auf WhatsApp teilen
  • ClickStack ist eine Open-Source-Observability-Plattform auf Basis von ClickHouse und HyperDX, die Logs, Metriken, Traces und Session-Replays an einem Ort integriert verarbeitet
  • Suche und Visualisierung von Logs und Traces werden auf einem ClickHouse-Cluster einfach und schnell unterstützt; jedes Schema kann ohne zusätzliche Arbeit angewendet werden
  • Sie bietet intuitive Suche, ereignisbasierte Alarme und Dashboard-Funktionen, damit Engineers Probleme schnell erkennen und darauf reagieren können
  • Der OpenTelemetry-Standard wird nativ unterstützt, zusammen mit SDK-Integrationen für verschiedene Sprachen und Plattformen
  • Im Vergleich zu bestehenden kommerziellen Lösungen ist sie günstiger und einfacher zu konfigurieren; statt umständlich zwischen mehreren Observability-Tools zu wechseln, lässt sich der gesamte Ablauf auf einer Plattform abwickeln

Hauptfunktionen

  • Korrelationsanalyse und Suche für Logs, Metriken, Session-Replays und Traces lassen sich an einem Ort durchführen
  • Nutzt bestehende ClickHouse-Schemata unverändert und bietet eine schemaunabhängige Struktur
  • Dank hoher Suchgeschwindigkeit und optimierter Visualisierung auch für große Datenmengen geeignet
  • Unterstützt sowohl Volltext- als auch Attributsuche; SQL ist optional
  • Analyse von Ereignistrends sowie einfache Alarmkonfiguration und Dashboard-Erstellung sind möglich
  • Unterstützung für native JSON-String-Abfragen
  • Mit Echtzeit-Logs und Trace-Tail-Funktion lassen sich die neuesten Ereignisse prüfen
  • OpenTelemetry-Integration und Unterstützung für **APM-(Performance-Monitoring-)**Umgebungen

Bereitstellung und Einstieg

  • Das ClickStack-Paket kann ClickHouse, HyperDX, den OpenTelemetry Collector und MongoDB für eine integrierte Bereitstellung enthalten
  • Die HyperDX-UI ist über den Browser erreichbar
  • Es kann auch mit ClickHouse Cloud verbunden werden und lässt sich leicht in verschiedenen Umgebungen bereitstellen

Anwendungsinstrumentierung und Integration

Um mit HyperDX Daten zu Logs, Metriken, Traces und Session-Replays zu erfassen, muss die Anwendung Telemetriedaten an HyperDX senden

  • SDKs und Integrationsoptionen: SDKs für Browser, Node.js, Python und weitere Sprachen/Umgebungen ermöglichen eine einfache Anbindung
  • Unterstützung des OpenTelemetry-Standards: kompatibel mit Kubernetes, JavaScript, Python, Java, Go, Ruby, PHP, .NET, Elixir, Rust und weiteren Sprachen und Laufzeitumgebungen
  • Der OpenTelemetry Collector ist standardmäßig unter http://localhost:4318 erreichbar

So kann man beitragen

  • Community-Beiträge in vielerlei Form sind willkommen, etwa durch PRs, das Einreichen von Issues, die Verbesserung der Dokumentation, Abstimmungen zu offenen Issues oder das Teilen neuer Use Cases

Entwicklungsziel und Philosophie

Das Ziel des HyperDX-Teams ist es, allen Engineers zu ermöglichen, Telemetriedaten aus Produktionsumgebungen zu nutzen, um Probleme schnell zu lösen

Wichtige bisherige Probleme:

  • Observability-Tools für den Betrieb sind teuer, und die Kosten steigen mit wachsender Datenmenge stark an
  • Konfiguration und Nutzung sind schwierig und erfordern SREs sowie Fachleute
  • Logs, Session-Replays, APM und andere Funktionen sind getrennt, was die Verknüpfung von Informationen umständlich macht

Um diese Grenzen zu überwinden, werden ClickStack und HyperDX als Open Source bereitgestellt

  • HyperDX wurde von ClickHouse übernommen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-06-07
Hacker-News-Kommentare

  • Die Frage, warum ein eigenes Frontend gebaut wurde statt des bereits vorhandenen Grafana

  • DataDog sei teuer, deshalb wirke HyperDX wirklich attraktiv; geteilt wurde außerdem, dass das eigene Produkt LogLayer(https://loglayer.dev) ein strukturierter Logger für TypeScript sei, der Logs an verschiedene Logger und Cloud-Dienste (u. a. DataDog) senden könne. Es wurde die Meinung geteilt, dass gerade eine Integration für HyperDX entwickelt werde und bald veröffentlicht werden solle; außerdem der Wunsch, im Abschnitt „integrations“ der eigenen Website einen Link zur Dokumentation zur Anbindung von HyperDX und LogLayer hinzuzufügen. Dazu wurde der zugehörige PR-Link geteilt(https://github.com/hyperdxio/hyperdx-js/pull/184)

    • Die Bitte, auch Unterstützung zum Senden von Logs an VictoriaLogs hinzuzufügen, zusammen mit einem Verweis auf die Dokumentation zu verschiedenen Dateningestion-Protokollen(https://docs.victoriametrics.com/victorialogs/data-ingestion/)
    • Positives Feedback, dass die Integration von LogLayer und HyperDX gut aussehe und man sie sich selbst ansehen wolle

  • Es wurde geteilt, dass HyperDX bereits in echter Produktion eingesetzt werde und man mit der Integration in ClickHouse sowie der Kosteneffizienz sehr zufrieden sei; gefragt wurde, ob für HyperDX eine Migration zu ClickStack vorbereitet werden müsse

    • Freude über Feedback von einem Produktionsnutzer und der Hinweis, dass HyperDX definitiv nicht verschwinden werde und auf der Marketing-Seite weiterhin als zentraler Bestandteil des Stacks hervorgehoben werde. Künftig wolle man sich stärker auf HyperDX v2 und das ClickStack-Muster konzentrieren, HyperDX selbst solle aber weiterhin auf die Endnutzererfahrung fokussiert bleiben. Zusätzlich wurde erklärt, dass ClickStack das Ziel habe, die Flexibilität und Performance des ClickHouse-basierten Kerns stärker auszuschöpfen. Man konzentriere sich auf das Engineering, damit sich die Veränderung sowohl in Open Source als auch in der Cloud auf beiden Seiten reibungslos vollziehe. Nebenbei wurde erwähnt, dass die Antwort sich wegen instabilem WLAN zuletzt verzögert habe

  • Geteilt wurde die Einschätzung, dass Tracing und Logging in OTel in Ordnung seien, die Metrics-Funktion von OTel aber als zu komplex entworfen wirke. Gefragt wurde, ob ClickStack statsd-Daten ingestieren könne, insbesondere mit Datadogs Tagging-Erweiterungen, ob es integriertes Service-Tagging und Verknüpfungen zwischen Traces/Logs/Metriken gebe, ob die UI Links zu verwandten Daten biete, warum das Elixir-SDK die hyperdx-Bibliothek nutze und ob Notebooks auf der Roadmap stünden

    • Zustimmung, dass dies gute Fragen seien, sowie Einordnung, warum der OTel-Metrics-Standard so vielfältig geworden sei und warum das bedauerlich sei. Es wurde erklärt, dass der OTel collector verschiedene Formate wie statsd einsammeln und direkt in ClickHouse schreiben könne, sodass statsd nutzbar sei(statsdreceiver-Dokumentation). Logs und Traces ließen sich über trace/span id und resource attributes verknüpfen, und in k8s-Workloads gebe es bereits Korrelation bis hin zu Metriken. Metrics Correlation über exemplars werde derzeit noch nicht unterstützt, sei aber geplant. Das Elixir-SDK sei gewählt worden, um Nutzerumgebungen passend zu unterstützen; die Bibliothek habe sich unabhängig weiterentwickelt, und man denke darüber nach, künftig auf das offizielle OTel-SDK umzusteigen. Als Beispiel wurde geteilt, dass eine OTel-Integration für Deno direkt schnell eingeführt worden sei. Notebooks sollten bald im experimentellen Status veröffentlicht werden und verschiedene Workflows ermöglichen. Es wurde außerdem Interesse an weiterem Nutzerfeedback geäußert
    • Die Rückfrage, warum OTel-Metriken als komplex empfunden würden, zusammen mit dem Hinweis, dass bestehende Metrik-Pipelines wie statsd oder der DD agent nicht zwingend einfach ersetzt werden müssten, was ein Vorteil sei

  • Die Einschätzung, dass HyperDX Signoz ähnele, da es ebenfalls auf ClickHouse basiere und Open-Source- sowie Cloud-Versionen anbiete, verbunden mit der Frage nach den Unterschieden; außerdem die Beobachtung, dass auch die UI ähnlich wirke

    • Zusätzliche Neugier, mehr über den direkten Vergleich mit Signoz zu hören

  • Es werde nach einer neuen Logging-Lösung als Ersatz für Kibana gesucht, und da die Erfahrungen mit ClickHouse gut seien, bestehe Interesse an der UI von HyperDX. Die aktuelle Log-Pipeline laufe mit Vector auf Kubernetes, Vector unterstütze einen OTel sink (Beta), und bei JSON-Daten werde überlegt, was der beste Weg für den Log-Transport sei. Betont wurde außerdem eine große Umgebung mit TB-skaligen Datenmengen und hohem Durchsatz

    • ClickHouse sei auf große Datenmengen und hohen Durchsatz spezialisiert; erwähnt wurde auch der Einsatz von direktem Schreiben aus Vector nach ClickHouse (z. B. in einer Präsentation von Anthropic). Es wurde vorgeschlagen, es einfach auszuprobieren und Rückmeldung zu geben, dann könne man helfen
    • Die Meinung, dass eine Standardisierung des Datentransportformats auf otel strategisch eine gute Wahl für die Zukunft sei, verbunden mit dem Gefühl, dass sich dadurch zwei Sorgen reduziert hätten

  • Die Frage nach den Unterschieden zwischen Signoz und HyperDX (oder ClickHouse), mit der Beobachtung, dass beide aus YC stammen und ClickHouse nutzen

    • Wie weiter unten erwähnt, sei der größte Unterschied, dass es sich um ein offiziell vom ClickHouse-Team entwickeltes First-Party-Produkt handle, das flexibel auf fast allen ClickHouse-Instanzen laufe und auch benutzerdefinierte Schemas unterstütze. Das sei wichtig für Hochleistungs-Tuning oder bestimmte große Umgebungen (z. B. Anthropic). Wenn bereits ClickHouse-Daten vorhanden seien, sei die Einführung sehr einfach. OTel werde nicht zwingend aufgezwungen; stattdessen würden auch Vector, Cribl, S3 und benutzerdefinierte Skripte nativ unterstützt. Es gebe außerdem Funktionen für Telemetry Wrangling (hoch-kardinale Event-Deltas, ML-basiertes automatisches Clustering von Logs/Spans usw.), wodurch sich Daten leichter untersuchen ließen. Mit Session Replay werde eine durchgängige Integration von Klicks bis zu Infrastrukturmetriken unterstützt. Intern werde das System zur Überwachung von ClickHouse Cloud im Maßstab von über 100 PB betrieben, mit genug Flexibilität, um sogar spezifische Nutzerprobleme End-to-End nachzuvollziehen. Philosophisch glaube man, dass ein vereinheitlichtes bzw. zentralisiertes Werkzeug zur Spurensuche in der Praxis besser zum Debugging passe als die übliche Trennung in die „3 pillars“ (logs/metrics/traces)
    • Es wurde klargestellt, dass mit „You“ ClickHouse gemeint war

  • Nach der Registrierung sei in der UI das Widget „Was this search result helpful?“ schon vor der ersten Suche sichtbar gewesen, was die UX verwirrend gemacht habe. Außerdem wurde ein Bug gefunden: Klickt man auf Hide, erscheint ein Feedback-Button, und wenn man diesen erneut anklickt, kehrt alles in den ursprünglichen Zustand zurück. Insgesamt wurde kritisiert, dass die Schrift monospace und zudem klein sei und dass kräftiges Weiß sowie helles Grün schlecht mit dem dunklen Hintergrund harmonierten. Auch ein Wechsel auf Systemschriftarten habe wenig verbessert, weshalb ein traditionellerer UI-Stil empfohlen wurde. Als Feedback wurde geteilt, dass das schwer lesbare Design vom Einsatz abhalte

  • Die Frage, ob ClickHouse das einzige stateful Element in diesem Stack sei, sowie Interesse an der Kompatibilität mit Rotel, einem in Rust geschriebenen OTEL collector(https://github.com/streamfold/rotel); außerdem der Hinweis, dass Datadog einen selbst entwickelten Ersatz für den OTEL collector mit besserer Performance habe

    • Rotel wirke gut geeignet für OTel-Integration in leichtgewichtigen Umgebungen wie Lambda. Da der OTel-Ingestion-Endpunkt von HyperDX bereits standardkonform sei, sollte es voraussichtlich direkt kompatibel sein. Man habe außerdem mit den Rotel-Entwicklern gesprochen, und da kürzlich ClickHouse-Unterstützung hinzugekommen sei, wirke die Gesamtlösung nun besonders stimmig