Superlog selbst hosten: Ressourcen und Grenzen prüfen

Was das Self-Hosting von Superlog tatsächlich installiert

Für das Self-Hosting von Superlog klonen Sie das Repository, starten Postgres, ClickHouse und einen OpenTelemetry-Collector mit Docker Compose, führen eine Datenbankmigration aus und starten anschließend vier Node-Dienste aus dem Quellcode. Ihre Anwendungen senden OTLP-Traces, -Logs und -Metriken an einen Intake-Port. Superlog bildet daraus Fingerprints, gruppiert wiederkehrende Ereignisse zu einem einzelnen Incident und der standardmäßige Community-Agent-Runner erstellt eine lokale Incident-Zusammenfassung. Die Installation dauert einen Nachmittag. Der Ressourcenbedarf und die tatsächlichen Einschränkungen sind die Punkte, die Sie vor dem Start lesen sollten.

Superlog steht unter der Apache-2.0-Lizenz und befindet sich unter github.com/superloglabs/superlog. Am 13. Oktober 2026 hat das Projekt etwa 1.5k Sterne, ungefähr 490 Commits auf main und überhaupt keine Release-Tags. Fixieren Sie selbst einen Commit, statt beliebigen Code auszuführen, der am Morgen Ihres Klonens zufällig auf main vorhanden war.

Welche Fragen Superlog beantwortet, die Uptime Kuma und Langfuse nicht beantworten

Self-hosted-Monitoringtools wirken von außen austauschbar. Das sind sie nicht. Der Einsatz des falschen Tools belegt einen Server, ohne Ihnen einen Nutzen zu bringen.

• Uptime Kuma prüft Ihre Endpunkte von außen und beantwortet eine Frage: Ist der Dienst erreichbar?
• Zabbix überwacht Hosts und Dienste unter Ubuntu 24.04 und vergleicht CPU, Arbeitsspeicher, Datenträger und Dienststatus mit den von Ihnen festgelegten Schwellwerten.
• Langfuse zeichnet LLM-Aufrufe nach und erfasst für jeden Aufruf den Prompt, das Modell, die Token-Anzahl, die Latenz und die Kosten.
• Superlog übernimmt die Telemetriedaten, die Ihre normalen Dienste bereits ausgeben, und wandelt wiederkehrende Fehler in Incidents um.

Superlog beantwortet eine andere Frage: Was ist ausgefallen, welcher Teil ist ausgefallen und warum? Das Tool ist nicht auf LLM-Aufrufe spezialisiert und prüft Ihre Systeme nicht von außen. Es nimmt OTLP aus Ihrem normalen Anwendungscode entgegen und setzt beim Triage-Schritt einen Agenten ein. Dieser Schritt entspricht der ersten Prüfung, die eine für den Bereitschaftsdienst zuständige Person ohnehin durchführen würde.

Für das Budget eines VPS ist der Speicher entscheidend. Superlog verwendet einen Column Store, weil Telemetriedaten einmal geschrieben und anschließend über Zeitbereiche hinweg aus Millionen von Zeilen abgefragt werden. Dafür ist ClickHouse vorgesehen, nicht Postgres. Postgres bleibt Teil des Stacks und speichert die kleinen relationalen Daten: Projekte, Benutzer, Incidents und Ingest-Keys.

Was startet docker compose up -d tatsächlich?

Drei Container, und keiner davon ist Superlog. Das überrascht viele, die eine Installation mit einem einzigen Befehl erwarten.

• postgres:16, veröffentlicht auf dem Host-Port 5434
• clickhouse/clickhouse-server:26.1, auf 8123 für HTTP und 9000 für das native Protokoll
• otel/opentelemetry-collector-contrib:0.150.1, auf 4317 für gRPC und 4318 für OTLP über HTTP

Die Superlog-Anwendungen laufen aus dem Quellcode auf dem Host und werden von pnpm dev gestartet. Am 13. Oktober 2026 gibt es im Repository keine Compose-Datei für den Produktivbetrieb. Für einen dauerhaft laufenden Betrieb benötigen Sie daher eigene systemd-Units oder die im Verzeichnisbaum enthaltenen Dockerfiles der einzelnen Anwendungen. Die Anwendungen api, worker und proxy enthalten jeweils ein start-Skript, mit dem sich eine Unit kapseln lässt. Für die Webanwendung gibt es kein solches Skript. Sie ist eine Vite-Anwendung. Bauen Sie sie daher mit ihrem build-Skript und stellen Sie die Ausgabe als statische Dateien über nginx oder Caddy bereit. Alternativ können Sie ihr preview-Skript ausführen. Dieses ist vite preview.

Behalten Sie den Pfad eines Spans im Blick. Jeder Fehler weiter unten bedeutet, dass einer seiner Übergänge unterbrochen ist. Ihre Anwendung sendet OTLP an den Superlog-Intake-Proxy. Der Proxy authentifiziert die Anfrage mit Ihrem Ingest-Key, versieht sie mit der Projekt-ID und leitet sie an den Collector weiter. Der Collector entfernt alle superlog.*-Attribute, die der Client zu setzen versucht hat, fügt superlog.project_id aus dem vom Proxy bereitgestellten Header hinzu, bündelt die Daten und schreibt sie in ClickHouse. Die Webanwendung und die API lesen die Telemetriedaten anschließend aus ClickHouse. Alle übrigen Daten lesen sie aus Postgres.

Das Entfernen dieser Attribute ist eine echte Maßnahme zur Mandantentrennung und keine bloße Dekoration. Ohne diese Maßnahme könnte jeder mit einem gültigen Ingest-Key superlog.project_id selbst setzen und Daten in das Projekt eines anderen Mandanten schreiben.

Wie groß muss die VPS sein?

Planen Sie für eine einzelne Node-Installation bei geringem Ingest-Volumen mit 4 vCPU, 8 GB RAM und 40 GB SSD. Das ist eine Planungsuntergrenze, keine Messung. Verwenden Sie diese Größe daher als Ausgangspunkt und prüfen Sie sie anhand Ihres eigenen Datenverkehrs.

Der Arbeitsspeicher wird auf vier Bereiche verteilt. ClickHouse ist für Systeme mit viel RAM ausgelegt, und die Standardeinstellungen gehen davon aus. Postgres 16 ist in diesem Fall genügsam, da es Metadaten statt Telemetriedaten speichert. Auch der Collector benötigt wenig Speicher. Die vier Node-Prozesse umfassen einen Vite-Entwicklungsserver und drei tsx watch-Prozesse. Messen Sie deren Speicherverbrauch auf Ihrem eigenen System.

Der Speicherplatz ist das weniger offensichtliche Problem. pnpm install in diesem Monorepo lädt das AWS SDK, einen ClickHouse-Client, das OpenTelemetry SDK und eine React-Toolchain, bevor Sie auch nur einen einzigen Span ingestiert haben. ClickHouse wächst anschließend mit Ihrem Datenverkehr. Messen Sie beides:

df -h /
free -m
docker stats --no-stream
docker compose exec clickhouse clickhouse-client --database superlog --query "SELECT table, formatReadableSize(sum(bytes_on_disk)) AS size FROM system.parts WHERE active AND database = 'superlog' GROUP BY table ORDER BY sum(bytes_on_disk) DESC"

Problematisch ist die Lastspitze: ein fehlerhaftes Deployment, das pro Minute Tausende identischer Fehler erzeugt. Das Fingerprinting fasst diese für den Leser zu einem Incident zusammen. ClickHouse schreibt darunter jedoch weiterhin jede einzelne Zeile.

Sie legen die Aufbewahrungsdauer selbst fest. Der ClickHouse-Exporter des Collectors erstellt die Tabellen, otel_traces, otel_logs und jeweils eine Tabelle pro Metriktyp. Eine Aufbewahrungsdauer wird nur angewendet, wenn die Konfiguration in infra/collector/config.yaml eine solche festlegt. Ohne eigene Einstellung läuft nichts automatisch ab. Ein stark ausgelasteter Monat füllt daher die gesamte Festplatte, wenn Sie dies nicht einplanen.

Von einem festgelegten Commit installieren

git clone https://github.com/superloglabs/superlog.git
cd superlog
git tag -l
git log -1 --format='%H %cs %s'

git tag -l gibt am 13. Oktober 2026 erwartungsgemäß nichts aus. Wählen Sie den getesteten Commit aus und bleiben Sie bei diesem:

git checkout 0d3a6c8bb63eda3493e6ba0003e7c2a70750bc1e

Als Nächstes die Toolchain:

node -v
corepack enable
corepack prepare pnpm@9.12.0 --activate
pnpm -v

package.json deklariert engines.node als >=20.0.0 und packageManager als pnpm@9.12.0. Eine inkompatible Node-Version verhindert die Installation nicht automatisch: Die Durchsetzung der Engine-Anforderungen hängt von der Konfiguration ab, und pnpm 9.12.0 verwendet einen Warnpfad, wenn engineStrict deaktiviert ist. Das nodejs-Paket im Ubuntu-24.04-Archiv ist älter als 20. Installieren Sie daher Node 20 oder neuer über NodeSource oder nvm. Das Repository enthält eine .nvmrc. Daher wählt nvm use die vorgesehene Version aus, wenn Sie nvm verwenden.

pnpm install
docker compose up -d
docker compose ps

Warten Sie auf die Health-Checks, statt up -d als Bereitschaftssignal zu interpretieren. Postgres und ClickHouse deklarieren beide einen Health-Check in der Compose-Datei:

curl -sS http://127.0.0.1:8123/ping
pg_isready -h 127.0.0.1 -p 5434 -U postgres

ClickHouse antwortet auf Ok., und pg_isready antwortet auf accepting connections. Ein abgelehnter Verbindungsaufbau auf 8123 bedeutet, dass der Container noch startet oder beendet wurde. docker compose logs clickhouse zeigt, welcher Fall vorliegt, und docker inspect $(docker compose ps -q clickhouse) | grep -i oomkilled meldet true, wenn der Kernel den Prozess wegen Speichermangels beendet hat. Das deutet darauf hin, dass der Server zu klein ist, und nicht auf ein Problem in Ihrer Konfiguration.

Danach folgen die Migration und die Anwendungen:

pnpm --filter @superlog/db db:migrate
pnpm dev

Beachten Sie den Port: 5434, nicht 5432. Die Compose-Datei veröffentlicht Postgres auf 5434, damit es nicht mit einem bereits auf dem Host installierten Postgres kollidiert. Die .env.example-Dateien der Anwendung verwenden denselben Port, zusammen mit DATABASE_URL=postgres://postgres:postgres@localhost:5434/superlog. Wenn Sie die Migration auf einem Server, auf dem bereits Postgres läuft, an 5432 richten, erhalten Sie entweder eine abgelehnte Verbindung oder wenden die Migration, schlimmer noch, auf die falsche Datenbank an.

pnpm dev führt turbo run dev aus. Dadurch wird das dev-Skript jeder Anwendung über Turborepo gestartet, einschließlich api, web, worker und proxy. Die Ausgaben werden dabei in einem Terminal zusammengeführt. Das Procfile-Repository listet dieselben vier Prozesse auf und schreibt die Ausgabe jedes Prozesses zusätzlich in tmp/logs/. Starten Sie die Prozesse mit einem Procfile-Runner wie overmind oder foreman statt mit pnpm dev, wenn tail -f tmp/logs/proxy.log der Ort sein soll, an dem Sie den Ingest überwachen. Die README nennt http://localhost:5173 für die Webanwendung, http://localhost:4100 für die API und http://localhost:4101 für die OTLP-Annahme.

Prüfen Sie, was tatsächlich an einen Port gebunden ist, bevor Sie etwas darauf verweisen:

ss -lntp | grep -E '4000|4100|4101|5173'
curl -sS http://127.0.0.1:4101/health

Das ist später wichtig. Der Proxy liest seinen Port aus der Umgebungsvariablen PORT und verwendet 4000 als Fallback, wenn PORT nicht gesetzt ist. Auch die geladene apps/proxy/.env.example setzt PORT=4000, obwohl die README den Ingest auf 4101 nennt. Beides wurde am 13. Oktober 2026 geprüft. Verwenden Sie den Port, den ss anzeigt. Die folgenden Beispiele verwenden 4101. Ersetzen Sie diesen Wert durch 4000, wenn dieser Port gebunden ist. Eine selbst erstellte systemd-Unit setzt keine Variablen, sofern Sie PORT nicht darin definieren. Ein auf 4101 gerichteter Exporter schlägt daher mit einer abgelehnten Verbindung fehl, wenn der Proxy auf 4000 lauscht, und liefert Ihnen keinen weiteren Hinweis.

Einen Trace senden, einen Fehler erzeugen, einen Incident sehen

Erstellen Sie in der Webanwendung ein Projekt und kopieren Sie dessen Ingest-Key. Die Intake authentifiziert jede Anfrage anhand dieses Keys. Telemetrie ohne diesen Key erreicht ClickHouse daher nicht.

Richten Sie ein beliebiges OpenTelemetry SDK mit den standardmäßigen Umgebungsvariablen auf die Intake aus:

export OTEL_SERVICE_NAME=checkout-api
export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
export OTEL_EXPORTER_OTLP_ENDPOINT=http://127.0.0.1:4101
export OTEL_EXPORTER_OTLP_HEADERS='x-api-key=YOUR_INGEST_KEY'

Die Intake liest den Key aus dem Header x-api-key. Sie akzeptiert außerdem authorization: bearer YOUR_INGEST_KEY, wenn sich Ihr Exporter auf diese Weise einfacher konfigurieren lässt. Sie stellt die drei standardmäßigen OTLP-Pfade /v1/traces, /v1/logs und /v1/metrics sowie /health bereit.

Ein häufiger Fehler sollte ausdrücklich genannt werden. OTEL_EXPORTER_OTLP_ENDPOINT ist eine Basis-URL, an die das SDK den Signalpfad anhängt. Signalspezifische Variablen wie OTEL_EXPORTER_OTLP_TRACES_ENDPOINT werden genau so verwendet, wie sie angegeben sind. Es wird kein Pfad angehängt. Setzen Sie die signalspezifische Variable auf http://127.0.0.1:4101, sendet jeder Export an /. Das ist keine Route. Es kommt daher nichts an. Das SDK protokolliert einen Exportfehler, während Ihre Anwendung weiterhin fehlerfrei wirkt.

Bei einem Node-Dienst genügt der Pfad ohne Codeänderungen, um die Pipeline zu prüfen:

npm install @opentelemetry/api @opentelemetry/auto-instrumentations-node
node --require @opentelemetry/auto-instrumentations-node/register server.js

Lösen Sie nun absichtlich einen Fehler aus. Jede Route, die eine Exception auslöst, ist geeignet:

curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:3000/boom

Prüfen Sie die einzelnen Stationen in dieser Reihenfolge. Die erste Lücke zeigt, welche Station ausgefallen ist:

tail -n 50 tmp/logs/proxy.log
docker compose exec clickhouse clickhouse-client --database superlog --query 'SELECT count() FROM otel_traces'

Ein steigender Zähler in otel_traces bei gleichzeitig leerer Webanwendung weist auf eine Projektabweichung hin. Prüfen Sie daher, zu welchem Projekt der Ingest-Key gehört. Ein unveränderter Zähler bei Aktivität im Proxy-Log weist auf den Collector oder den Schreibvorgang in ClickHouse hin. Lesen Sie in diesem Fall docker compose logs collector. Gibt es im Proxy-Log überhaupt keine Aktivität, hat der Exporter die Intake nicht erreicht: falscher Port, falscher Pfad oder abgelehnter Key.

In der Webanwendung erscheinen diese wiederholten Fehler als ein Incident und nicht als eine Zeile pro Anfrage. Superlog erstellt Fingerprints für eingehende Signale und gruppiert übereinstimmende Signale. Dadurch enthält der Posteingang nicht 4,000 identische Fehler, sondern eine Seite mit einem Eintrag. Der standardmäßige Community-Agent-Runner erfasst anschließend eine lokale Incident-Zusammenfassung für diese Gruppe.

Für eine modellgestützte Untersuchung müssen ein Model Provider und ein kompatibler Agent-Runner konfiguriert sein. Der standardmäßige Community-Runner erfasst eine lokale Zusammenfassung. Übernehmen Sie diese Variablennamen aus der Datei .env.example im jeweiligen App-Verzeichnis des von Ihnen festgelegten Commits und nicht aus einer externen Anleitung. Die Variablennamen ändern sich zusammen mit main. Dasselbe gilt für die GitHub- und Sentry-Integrationen. Ihre jeweiligen Einrichtungsdokumente befinden sich unter docs/github-app-setup.md und docs/sentry-app-setup.md. Webhook-Payloads sind unter docs/webhooks.md dokumentiert.

Den Intake privat halten und den Agenten nur lesend betreiben

Docker veröffentlicht Container-Ports standardmäßig auf 0.0.0.0. Diese veröffentlichten Ports umgehen ufw. Docker leitet Container-Verkehr in der Tabelle nat weiter. Ein Paket für einen veröffentlichten Port wird daher umgeleitet, bevor es die Ketten INPUT und OUTPUT erreicht, in denen die Regeln von ufw liegen. ufw kann den Zugriff dort nicht mehr steuern. Auf einem VPS mit öffentlicher IP stellt die mitgelieferte Compose-Datei ClickHouse HTTP auf Port 8123 und Postgres auf Port 5434 bereit. Beide Ports sind dadurch aus dem Internet erreichbar. Die Zugangsdaten in dieser Datei sind Entwicklungsstandardwerte: der ClickHouse-Benutzer default mit leerem Passwort sowie Postgres mit postgres als Benutzer und Passwort.

Binden Sie die Ports an das Loopback-Interface. Jeder veröffentlichte Port in der Compose-Datei bezieht die Host-Seite aus einer Umgebungsvariablen. Daher genügt eine .env im Repository-Stammverzeichnis:

POSTGRES_HOST_PORT=127.0.0.1:5434
CLICKHOUSE_HTTP_HOST_PORT=127.0.0.1:8123
CLICKHOUSE_TCP_HOST_PORT=127.0.0.1:9000
COLLECTOR_GRPC_HOST_PORT=127.0.0.1:4317
COLLECTOR_HTTP_HOST_PORT=127.0.0.1:4318

Prüfen Sie das Ergebnis, bevor Sie darauf vertrauen, und erstellen Sie die Container anschließend neu:

docker compose config
docker compose up -d
ss -lntp | grep -E '5434|8123|9000|4317|4318'

docker compose config gibt die aufgelöste Datei aus. Dadurch können Sie 127.0.0.1:5434:5432 ablesen, statt zu raten. ss sollte anschließend 127.0.0.1:5434 anzeigen und niemals 0.0.0.0:5434. Wenn Sie ports einfach erneut in einer Compose-Override-Datei deklarieren, bleiben beide Bindings erhalten, sobald sich die Host-IP unterscheidet. Compose 2.24.4 und höher unterstützt ports: !override, um die Liste zu ersetzen.

Auch der Intake benötigt diese Absicherung. Ihr Ingest-Key wird in einem Header übertragen. Daher muss davor TLS (Transport Layer Security) verwendet werden. Beenden Sie TLS in nginx oder Caddy vor dem Proxy. Alternativ betreiben Sie den Ingest in einem privaten Netzwerk oder über einen WireGuard-Tunnel. Die Webanwendung auf Port 5173 ist ein Vite-Entwicklungsserver. Sie darf keinesfalls aus dem Internet erreichbar sein.

Nun zum Agenten selbst. Superlog bewirbt den Agenten damit, dass er einen Fehler untersucht und eine Lösung vorschlägt. Entscheidend ist dabei das Wort „vorschlägt“. Betreiben Sie ihn in Produktionsumgebungen zunächst nur mit Lesezugriff, bis Sie sein Verhalten bei mehreren echten Vorfällen beobachtet haben. Eine schreibgeschützte GitHub App kann keinen Fix-Branch pushen und keine Pull Requests öffnen. Für diesen Ablauf verlangt die Einrichtungsanleitung Schreibberechtigungen für Contents und Pull requests sowie Schreibberechtigungen für Issues, damit Kommentare erstellt werden können. Ein Agent, der Telemetriedaten liest und einen Patch schreibt, ist nützlich. Ein Agent, der Ihre Dienste neu starten kann, stellt ein anderes Risiko dar. Diese Berechtigung sollten Sie bewusst vergeben und nicht standardmäßig übernehmen. Bei der Konfiguration eines modellbasierten Runners verdient auch der Kostenaspekt Aufmerksamkeit: kalkulieren Sie die Agentenkosten auf einem VPS bevor Sie ihn auf ein lautes Produktionssystem ansetzen, und führen Sie ein Protokoll der tatsächlichen Aktionen des Agenten, damit ein unerwarteter Pull Request anhand eines Audit-Trails nachvollziehbar bleibt.

Fehler, die auftreten können, und die Bezeichnungen dafür

• ERR_PNPM_UNSUPPORTED_ENGINE während pnpm install bedeutet, dass eine Engine-Anforderung nicht kompatibel ist. pnpm 9.12.0 prüft die Anforderungen für Node und pnpm. Lesen Sie die gewünschten und die aktuellen Versionen aus der Fehlermeldung ab. Prüfen Sie anschließend node -v und pnpm -v.
• ECONNREFUSED 127.0.0.1:5434 während der Migration bedeutet, dass der Compose-Stack nicht läuft oder dass DATABASE_URL den falschen Port angibt.
• Prüfen Sie Neustarts von ClickHouse mit docker compose logs clickhouse. Prüfen Sie anschließend im Container, ob OOMKilled den Status true hat.
• Wenn ein Exporter Erfolg meldet, die Webanwendung aber leer bleibt, wurden die Daten wahrscheinlich direkt an den Collector auf Port 4318 gesendet. Dadurch wird das Project-Stamping übersprungen, das der Proxy übernimmt.
• Eine abgelehnte Verbindung auf Port 4101 bedeutet normalerweise, dass der Proxy auf Port 4000 lauscht. Das ist der Port, auf den der Code zurückfällt und den .env.example festlegt. Setzen Sie PORT explizit in der Unit-Datei oder in .env der Anwendung.
• Wenn docker compose ps 0.0.0.0:8123 anzeigt, sind Ihre Loopback-Bindings nicht aktiv. Führen Sie docker compose config aus und lesen Sie die aufgelösten Ports ab.

Flawless, HyperProbe und die Rolle von Superlog

Diese Kategorie ist noch jung. Die Tools unterscheiden sich darin, worauf der Agent zugreifen darf. Das Flawless-Repository stellt inzwischen CISRE vor, eine AI-SRE-Plattform (Site Reliability Engineering) für Kubernetes und Cloud-Infrastruktur unter der PolyForm-Noncommercial-Lizenz. HyperProbe platziert Probes in einem laufenden Prozess, um den Variablenstatus zu erfassen, und stellt diesen Status einem Assistant über MCP (Model Context Protocol) bereit. Außerdem ist dort das Self-Hosting mit Docker Compose und einem Lizenzschlüssel dokumentiert.

Superlog liegt zwischen diesen beiden Ansätzen. Es verwaltet die gesamte Pipeline, von der OTLP-Annahme bis zur Speicherung in ClickHouse. Der Agent wird beim Triage-Schritt eingesetzt, nicht beim Beheben des Problems. Genau deshalb ist Self-Hosting eine Infrastrukturentscheidung und kein Container, den Sie anschließend vergessen können. Wenn Sie Superlog betreiben, betreiben Sie einen Column Store. Er benötigt dieselbe Pflege wie jede andere Datenbank, die Sie selbst verwalten.

FAQ

Wie viel RAM benötigt ein selbst gehostetes Superlog?

Planen Sie für einen einzelnen Knoten bei geringem Ingest-Volumen mit 8 GB RAM, 4 vCPU und 40 GB Speicherplatz. Der Stack besteht aus Postgres, ClickHouse, einem OpenTelemetry-Collector und vier Node-Prozessen. ClickHouse benötigt außerdem ausreichend Reserven. Ermitteln Sie Ihre eigenen Werte mit docker stats --no-stream und free -m, statt einer veröffentlichten Angabe zu vertrauen, auch dieser hier.

Auf welchen Port muss ich meinen OTLP-Exporter verweisen?

Auf den Superlog-Intake-Proxy, den die README auf http://localhost:4101 legt. Er stellt /v1/traces, /v1/logs und /v1/metrics bereit und authentifiziert sich mit dem Ingest-Key Ihres Projekts, der aus dem Header x-api-key oder einem Header authorization: bearer stammt. Port 4318 gehört zum darunterliegenden OpenTelemetry-Collector. Wenn Sie direkt dorthin exportieren, umgehen Sie den Proxy. Der Proxy versieht die Daten mit Ihrer Projekt-ID. Der Proxy verwendet Port 4000 als Fallback, wenn PORT nicht gesetzt ist. Auch .env.example setzt 4000. Führen Sie daher ss -lntp aus und prüfen Sie, an welchen Port der Dienst gebunden ist, bevor Sie 4101 annehmen.

Ersetzt Superlog Uptime Kuma oder Zabbix?

Nein. Uptime Kuma prüft, ob ein Endpunkt von außerhalb Ihres Netzwerks antwortet. Zabbix überwacht Host- und Servicemetriken anhand der von Ihnen festgelegten Schwellenwerte. Superlog verarbeitet die von Ihren Anwendungen ausgegebenen Traces, Logs und Metriken und gruppiert wiederholte Fehler zu Incidents. Betreiben Sie zusätzlich einen externen Uptime-Probe. Ein Probe an einem anderen Standort meldet weiterhin, wenn der Server mit Ihrer Telemetrie-Pipeline ausgefallen ist.

Kann der Superlog-Agent meine Produktionssysteme ändern?

Nur über Berechtigungen, die Sie ihm erteilen. Der standardmäßige Community-Runner erstellt eine lokale Incident-Zusammenfassung. Andere Laufzeitumgebungen für Untersuchungen hängen von dem Runner ab, den Sie konfigurieren. Beschränken Sie Produktionszugangsdaten auf Leseberechtigungen. Zum Öffnen von Pull Requests sind separate GitHub-Schreibberechtigungen für Branches und Pull Requests erforderlich. Behandeln Sie Schreibzugriff auf die Produktion als eine separate, bewusste Entscheidung. Ein Agent, der Dienste neu starten kann, ist eine wesentlich größere Verpflichtung als ein Agent, der Telemetrie liest und einen Patch zur Prüfung erstellt.

Sollte ich einen Commit festschreiben oder main verfolgen?

Schreiben Sie einen Commit fest. Am 13 October 2026 gab es im Repository keine Release-Tags. Notieren Sie die SHA, die Sie getestet haben, stellen Sie genau diese Version bereit und lesen Sie den Diff, bevor Sie aktualisieren. git log --oneline <old-sha>..main ist die Prüfung. Die .env.example-Dateien der einzelnen Anwendungen sind nach jedem Update der erste Ort, an dem Sie nach neu erforderlichen Variablen suchen sollten.