Superlog: selbstgehostete OpenTelemetry-Ablage mit Agenten-Runnern für Incident-Zusammenfassungen
Open-source observability tool that uses AI agents to self-heal your software
Auf einen Blick
- Was ist das?
- Superlog bündelt OTLP-Ingest, Postgres-Schema, ClickHouse-Abfragen und einen austauschbaren Agent-Runner in einem Monorepo. Der offene Teil endet dort, wo die eigentliche Untersuchung beginnt: Die Community-Edition zeichnet nur eine lokale Zusammenfassung auf.
- Für wen ist es gedacht?
- Wer ohnehin OpenTelemetry-Daten sammelt und die Auswertung selbst hosten will, findet in Superlog ein Monorepo mit klarer Aufteilung in Proxy, API, Worker und Datenbankpakete. Wer eine fertige Incident-Untersuchung erwartet, sollte zuerst prüfen, was der community-Agent-Runner tatsächlich liefert, bevor er den Betrieb aufsetzt.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich TypeScript, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welches Problem Superlog adressiert und für wen es gedacht ist
Die README beschreibt Superlog als agentisches Telemetriesystem, das Traces, Logs und Metriken aufnimmt, verrauschte Signale zu Incidents gruppiert und die Infrastruktur beobachtet. Das ist eine präzise Problembeschreibung: Nicht die Erfassung von Telemetrie ist der Engpass, sondern die Verdichtung. Wer OpenTelemetry bereits einsetzt, kennt den Zustand, in dem Rohdaten reichlich vorhanden sind und trotzdem niemand sagen kann, welcher der zwanzig gleichzeitig ausgelösten Alarme zusammengehört.
Die Zielgruppe lässt sich aus dem Repository-Layout ableiten. Es gibt einen OTLP-Ingest-Proxy, Worker-Prozesse, ein Postgres-Schema und ClickHouse-gestützte Telemetrieabfragen. Das setzt ein Team voraus, das Docker und pnpm bedienen kann und bereit ist, eine Datenbanklandschaft selbst zu betreiben. Für Einzelentwickler mit einer kleinen Anwendung ist der Aufwand aus Postgres, ClickHouse, Proxy, API, Worker und Web-Frontend schwer zu rechtfertigen.
Bemerkenswert ist die Formulierung open-core. Das Repository enthält ausdrücklich die kostenlose Community-Edition. Eine gehostete Cloud-Variante mit kostenlosem Tarif, Pay-to-go-Plan und monatlichen Credit-Paketen wird daneben angeboten. Wer das Projekt evaluiert, sollte also von Anfang an trennen, welche Funktionen im offenen Repository liegen und welche nur in der gehosteten Ausgabe.
Der Ingest-Pfad: OTLP-Proxy, Postgres und ClickHouse
Der Datenfluss beginnt laut Repository-Beschreibung am OTLP-Ingest-Proxy in apps/proxy. Dieser nimmt Telemetrie entgegen und leitet sie in die Speicherschicht. Die Aufteilung ist erkennbar zweigeteilt: packages/db enthält das Drizzle-Schema und die Migrationen für Postgres, während die Telemetrieabfragen ClickHouse-gestützt laufen. Postgres trägt damit die organisatorischen Daten, ClickHouse die analytischen Abfragen über große Mengen an Traces, Logs und Metriken.
Das ist eine bewusste Architekturentscheidung und keine Selbstverständlichkeit. Sie bedeutet aber auch, dass ein Betrieb zwei Datenbanksysteme aktuell halten muss. Die README nennt keine Angaben zu Datenaufbewahrung, Kompaktierung oder Partitionsstrategie in ClickHouse. Wer Superlog produktiv einsetzen will, muss diese Fragen aus dem Schema selbst beantworten, weil das Material sie nicht beantwortet.
Ein weiteres Paket ist packages/fingerprint mit Helfern zum Fingerprinting von Telemetrie. Das ist der Mechanismus, der hinter dem Gruppieren von Signalen zu Incidents steht: Ähnliche oder wiederkehrende Signale werden über einen Fingerprint zusammengeführt, statt als getrennte Alarme aufzuschlagen. Wie der Fingerprint genau gebildet wird und wie stabil er über Deployments hinweg bleibt, lässt sich aus dem bereitgestellten Material nicht entnehmen. Genau dort liegt aber die praktisch wichtigste Frage, weil eine Incident-Gruppierung, die nach jedem Deployment neue Gruppen bildet, ihren Zweck verfehlt.
Der Agent-Runner: Schnittstelle im offenen Teil, Untersuchung im gehosteten Teil
Die README listet unter den Bestandteilen der Community-Edition ausdrücklich Agent-Runner-Schnittstellen für austauschbare Untersuchungslaufzeiten und einen Standard-Runner namens community, der eine lokale Incident-Zusammenfassung aufzeichnet. Diese Formulierung ist sorgfältig gewählt und sollte beim Lesen ernst genommen werden. Die Schnittstelle ist offen, der mitgelieferte Runner zeichnet auf, er untersucht nicht.
Das ist der zentrale Bruch zwischen Anspruch und offenem Umfang. Der Projekttitel spricht von Selbstheilung, die Beschreibung nennt Agenten, aber der einzige im Repository enthaltene Runner erzeugt eine Zusammenfassung. Ob die tatsächliche Ursachenanalyse, das Vorschlagen von Korrekturen oder das Ausführen von Reparaturen in der gehosteten Edition liegen, sagt das Material nicht explizit. Die Formulierung pluggable investigation runtimes legt jedoch nahe, dass hier eine Erweiterungsschnittstelle für eigene Laufzeiten gedacht ist.
Für ein Team, das selbst einen Runner implementieren will, ist das ein gangbarer Weg: Die Worker-Prozesse in apps/worker übernehmen laut Layout Hintergrundjobs und die Agent-Orchestrierung. Der Aufwand liegt dann beim Team, nicht beim Projekt. Wer dagegen eine fertige Lösung für automatische Fehlerbehebung sucht, wird im offenen Repository nicht fündig. Diese Unterscheidung ist der wichtigste Punkt bei der Bewertung von Superlog.
Installation und lokaler Start
Die README nennt drei Voraussetzungen: Node.js in Version 20 oder höher, pnpm ab Version 9 und Docker. Die Installation erfolgt über pnpm install. Danach startet der lokale Stack in drei Schritten:
docker compose up -d pnpm --filter @superlog/db db:migrate pnpm dev
Der Filteraufruf auf @superlog/db führt die Migrationen aus dem Drizzle-Schema aus. Das ist der Schritt, der die Postgres-Struktur anlegt. Die Reihenfolge ist nicht beliebig: Ohne Migrationen starten API und Worker gegen ein leeres Schema.
Als lokale Dienste nennt die README Web auf http://localhost:5173, API auf http://localhost:4100 und den OTLP-Eingang auf http://localhost:4101. Für den Typecheck steht pnpm typecheck bereit. Ein Hinweis für den Produktivbetrieb: Port 4101 ist der Endpunkt, an den eure OpenTelemetry-SDKs oder Collector-Instanzen ihre Daten senden. Wenn dieser Port nicht erreichbar ist, bleibt die gesamte Kette leer, unabhängig davon, ob Web und API laufen.
Die README beschreibt außerdem einen alternativen Installationsweg über einen Coding-Agenten: npx skills add superloglabs/skills --all. Das verweist auf ein separates Repository mit Skills. Wer diesen Weg wählt, sollte beachten, dass damit ein externes Repository in den eigenen Projektkontext geladen wird.
Grenzen: wo Superlog das falsche Werkzeug ist
Die deutlichste Grenze ist bereits genannt: Der Standard-Runner zeichnet nur eine Zusammenfassung auf. Wer erwartet, dass das System einen fehlerhaften Deploy erkennt und zurückrollt, wird das im offenen Repository nicht finden.
Eine zweite Grenze ist der Betriebsaufwand. Postgres und ClickHouse gleichzeitig zu betreiben, bedeutet zwei Backup-Strategien, zwei Upgrade-Pfade und zwei Ressourcenprofile. Dazu kommt der OTLP-Proxy als eigener Dienst. Teams, die bisher einen verwalteten Observability-Dienst nutzen, unterschätzen diesen Wechsel regelmäßig.
Drittens: Die README nennt keine Angaben zu Mandantenfähigkeit, Authentifizierung oder Zugriffskontrolle. Für eine selbstgehostete Instanz, auf der mehrere Teams oder gar externe Kunden ihre Telemetrie ablegen, ist das eine offene Frage, die vor dem Rollout geklärt werden muss. Telemetrie enthält häufig Nutzungsdaten, Fehlermeldungen mit Variableninhalten und Stacktraces. Wer sie zentral sammelt, sammelt unter Umständen personenbezogene Daten mit.
Und schließlich der Reifegrad: Das Repository hat keine abgerufenen Releases. Es gibt also keine veröffentlichten Versionsstände, an denen man sich orientieren könnte. Wer heute einsteigt, arbeitet gegen den Branch main. Das ist ein legitimer Zustand für ein junges Projekt, aber es bedeutet, dass es keinen versionierten Upgrade-Pfad gibt.
Alternativen und der tatsächliche Unterschied im Ansatz
Der naheliegende Vergleich ist Grafana mit Loki, Tempo und Prometheus. Der Unterschied liegt nicht im Funktionsumfang, sondern im Auswertungsmodell. Grafana stellt Dashboards, Abfragesprachen und Alerting-Regeln bereit und überlässt die Interpretation dem Menschen, der vor dem Bildschirm sitzt. Superlog setzt eine Ebene darüber: Fingerprinting und Incident-Gruppierung sollen die Interpretation vorstrukturieren, bevor jemand hinschaut.
Das ist ein anderer Ansatz mit anderen Kosten. Bei Grafana ist das Verhalten deterministisch und vollständig dokumentiert; man kann jede Abfrage nachvollziehen. Bei einer Gruppierung über Fingerprints und einen Agent-Runner hängt das Ergebnis von Heuristiken und, im Fall des Runners, von einem Modell ab. Für Teams mit Audit-Anforderungen an die Nachvollziehbarkeit von Alarmeentscheidungen ist das ein relevanter Unterschied.
Ein zweiter Vergleichspunkt ist der Betriebsmodus. Grafana lässt sich mit einem einzelnen Dienst und einer Datenbank betreiben. Superlog verlangt Postgres und ClickHouse. Wer ClickHouse ohnehin betreibt, hat diesen Aufwand bereits bezahlt. Wer nicht, sollte ihn in die Entscheidung einrechnen.
Ein dritter Punkt betrifft die Erweiterbarkeit. Superlog definiert Agent-Runner als austauschbare Schnittstelle. Das ist ein Modell, das Teams erlaubt, eigene Untersuchungslogik einzubringen, ohne das Projekt zu forken. Ob diese Schnittstelle stabil genug ist, um sie als Vertrag zu behandeln, lässt sich aus dem Material nicht beurteilen.
Wartung, Upgrades und Lizenz
Zum Wartungsaufwand macht das Material nur indirekte Aussagen. Der letzte Push liegt im September 2026, das Repository ist nicht archiviert. Es gibt keine abgerufenen Releases, also auch keine Release Notes, aus denen sich Upgrade-Schritte ableiten ließen. Ein Upgrade bedeutet daher, den Branch main zu verfolgen und die Migrationen aus packages/db anzuwenden. Der Aufruf pnpm --filter @superlog/db db:migrate ist der einzige im Material genannte Migrationsschritt.
Für den Betrieb heißt das: Vor jedem Upgrade ist zu prüfen, ob neue Migrationen hinzugekommen sind, und ob diese rückwärtskompatibel sind. Drizzle-Migrationen sind in der Regel vorwärtsgerichtet; ein Rollback ist nicht automatisch vorgesehen. Das ist kein spezifisches Problem von Superlog, aber bei fehlenden Releases fällt die übliche Absicherung über Versionsnummern weg.
Lizenzrechtlich steht Superlog unter Apache License 2.0. Diese Lizenz erlaubt kommerzielle Nutzung, Modifikation und Weitergabe, verlangt aber die Beibehaltung von Urheberrechts- und Lizenzhinweisen sowie die Kennzeichnung geänderter Dateien. Wer den Code forkt und einen eigenen Agent-Runner beisteuert, sollte die Hinweise in den geänderten Dateien setzen. Das ist eine allgemeine Beobachtung zur Lizenz und keine Rechtsberatung. Für die konkrete Ausgestaltung, insbesondere bei einer Weitergabe als eigenes Produkt, ist eigene Prüfung nötig.
Offen bleibt, wie sich die Trennung zwischen Community- und Cloud-Edition langfristig auf die Wartung des offenen Repositories auswirkt. Das Material gibt dazu keine Auskunft. Wer sich auf die Schnittstellen in apps/worker verlässt, sollte im Blick behalten, ob sie sich mit der gehosteten Ausgabe mitentwickeln.
Redaktionelles Fazit
Wer ohnehin OpenTelemetry-Daten sammelt und die Auswertung selbst hosten will, findet in Superlog ein Monorepo mit klarer Aufteilung in Proxy, API, Worker und Datenbankpakete. Wer eine fertige Incident-Untersuchung erwartet, sollte zuerst prüfen, was der community-Agent-Runner tatsächlich liefert, bevor er den Betrieb aufsetzt. Vor dem Rollout sind drei Dinge zu klären: ob die ClickHouse-Abfragen im packages/db-Schema zu euren Trace-Volumina passen, ob der OTLP-Proxy auf Port 4101 hinter eurem Load Balancer betrieben werden kann, und ob der Apache-2.0-Umfang des Repositories eure Anforderungen an eine gehostete Ausgabe abdeckt. Wer diese drei Punkte beantwortet hat, kann entscheiden; wer sie offen lässt, betreibt eine Telemetrie-Ablage und nennt sie fälschlich Selbstheilung.
Community-Notizen