Sentry Alternativen für selbst gehostetes Error-Tracking

Welche Kosten beim selbst gehosteten Error-Tracking anfallen, bevor ein Ereignis gespeichert wird

Beim selbst gehosteten Error-Tracking gibt es eine Kennzahl, die die gesamte Entscheidung bestimmt: der Mindestbedarf an RAM. Die offizielle Dokumentation für das Self-Hosting von Sentry verlangt 4 CPU-Kerne, 16 GB RAM zuzüglich 16 GB Swap sowie 20 GB freien Festplattenspeicher, bevor Ihre Anwendung ein einziges Ereignis sendet. GlitchTip gibt einen Bedarf von 512 MB an. Alle hier aufgeführten Optionen akzeptieren Ereignisse von denselben Sentry-SDKs; es geht also nicht darum, wie Sie Ihren Code instrumentieren. Es ist eine Entscheidung darüber, wie groß der Server sein darf, für den Sie bezahlen und den Sie instand halten wollen.

Veröffentlichte Ressourcenwerte im direkten Vergleich

Dies sind die Zahlen, die jedes Projekt mit Stand August 2026 selbst veröffentlicht. Es handelt sich nicht um identische Messgrößen; lesen Sie daher die Anmerkung in jeder Zeile, bevor Sie diese vergleichen.

[
  {
    "tool": "Sentry self-hosted",
    "published_ram_gb": 16,
    "notes": "documented minimum, plus 16 GB of swap"
  },
  {
    "tool": "Bugsink",
    "published_ram_gb": 4,
    "notes": "the vendor's own published benchmark box, 2 vCPU"
  },
  {
    "tool": "GlitchTip",
    "published_ram_gb": 0.5,
    "notes": "documented recommendation, 256 MB stated as the minimum"
  }
]

Die 16 GB von Sentry sind ein dokumentiertes Minimum, wobei auf derselben Seite 32 GB empfohlen werden. Die 0.5 GB von GlitchTip sind eine Empfehlung; das Projekt gibt 256 MB als funktionierendes Minimum an, oder 128 MB zuzüglich Swap bei sorgfältiger Konfiguration. Die 4 GB von Bugsink sind keines von beidem: Es handelt sich um die Hardware, die der Anbieter für seinen eigenen Durchsatz-Benchmark verwendet hat. Ein veröffentlichter Wert ist ein Ausgangspunkt, kein Versprechen bezüglich Ihres Event-Volumens.

Sentry self-hosted: Das gesamte Produkt und die gesamte Last

Der offizielle Stack ist getsentry/self-hosted, ein Docker Compose-Projekt, das dieselben Komponenten ausführt, die Sentry auch in der Produktion verwendet. Die eigene Dokumentation beschreibt es als "funktionsvollständig und für Bereitstellungen mit geringem Volumen sowie Proofs-of-Concept verpackt". Dieser Satz ist die ehrliche Zusammenfassung. Sie erhalten jedes Feature und jedes bewegliche Teil, das diese Features am Laufen hält.

Installieren Sie von einem getaggten Release statt von master:

VERSION=$(curl -Ls -o /dev/null -w %{url_effective} https://github.com/getsentry/self-hosted/releases/latest)
VERSION=${VERSION##*/}
git clone https://github.com/getsentry/self-hosted.git
cd self-hosted
git checkout ${VERSION}
./install.sh

Starten Sie es anschließend:

docker compose up --wait

Sentry lauscht standardmäßig auf http://127.0.0.1:9000. Docker Engine 19.03.6 oder neuer sowie Docker Compose 2.32.2 oder neuer sind erforderlich; eine ältere Compose-Version scheitert bereits an der Dateisyntax, nicht an Sentry selbst.

Prüfen Sie, was Sie tatsächlich gestartet haben:

docker compose ps
free -h

docker compose ps listet jeden Dienst im Stack auf, und die Liste ist lang: Postgres, ClickHouse, Kafka, Redis, Relay, Snuba, Symbolicator sowie mehrere Worker- und Cron-Prozesse. Zählen Sie diese einmal, denn diese Zahl entspricht Ihrem Wartungsaufwand. Jeder Eintrag ist ein Prozess, der abstürzen, eine Festplatte füllen oder bei einer Migration fehlschlagen kann.

Wenn ein Dienst im Status Restarting verharrt, prüfen Sie vor allem anderen den Arbeitsspeicher:

dmesg -T | grep -i 'out of memory'

Eine Zeile wie Out of memory: Killed process 3412 (java) bedeutet, dass der OOM-Killer (Out of Memory Killer) des Kernels einen Container beendet hat, weil der Server keinen RAM mehr hatte. Der Dienst erreicht daher nie den Status "healthy" und der Stack startet nicht vollständig. Dies ist das übliche Ergebnis, wenn der vollständige Stack unterhalb der dokumentierten Mindestanforderungen betrieben wird. Die Dokumentation weist zudem auf die Festplattengeschwindigkeit hin: iowait über 10 % bedeutet, dass die Maschine mit der Ingest-Pipeline nicht Schritt halten kann. Lesen Sie dies aus der Spalte wa in top ab oder aus iostat -x 5, falls Sie sysstat installiert haben.

Upgrades sind der unterschätzte Teil

Sentry self-hosted erscheint monatlich unter CalVer, einem kalenderbasierten Versionsschema, mit einem Haupt-Release am 15. jedes Monats. Sie können nicht von einer alten Version direkt auf die neueste springen. Das Projekt definiert feste Zwischenversionen (Hard Stops); Sie müssen jede einzelne auschecken, um die jeweiligen Datenbankmigrationen durchzuführen. Stand August 2026 sind die veröffentlichten Hard Stops 9.1.2, 21.5.0, 21.6.3, 23.6.2, 23.11.0, 24.8.0, 25.5.1, 26.5.0 und 26.7.0. Die Dokumentation listet zudem Releases auf, die aufgrund von Migrationsproblemen übersprungen werden sollten, darunter 23.7.0, 25.9.0, 25.12.0 sowie der Bereich von 26.3.0 bis 26.4.0.

Ein Upgrade besteht aus einem Checkout und einem erneuten Ausführen des Installers:

git fetch
git checkout 26.7.0
./install.sh
docker compose up --wait

Erstellen Sie einen Snapshot des Servers, bevor Sie beginnen, da eine Migration über einen großen ClickHouse-Datensatz Stunden dauern kann und ein Fehler währenddessen die Datenbank in einem Zustand zwischen zwei Schemata hinterlässt. Die häufigste Ursache für fehlgeschlagene Sentry-Upgrades: Der Server wurde ein Jahr lang auf einer Version belassen, sodass der Sprung mehrere Hard Stops gleichzeitig überbrückt und eine der übersprungenen Migrationen entscheidend war.

Noch ein Hinweis, bevor Sie sich festlegen: Sentry self-hosted steht unter der Functional Source License (FSL), die Sentry selbst eingeführt hat. Es handelt sich um "Fair Source" und nicht um OSI-zertifizierte Open Source: Sie dürfen es für sich selbst betreiben, aber Sie dürfen es nicht als konkurrierenden Dienst verkaufen. Jedes Release wird zwei Jahre nach der Veröffentlichung unter die Apache 2.0-Lizenz gestellt.

GlitchTip: Die 512 MB Antwort

GlitchTip steht unter der MIT-Lizenz und empfängt Events von den Open-Source-SDKs von Sentry. Eine instrumentierte Anwendung lässt sich durch die Änderung eines einzigen Wertes migrieren: dem DSN (Data Source Name, die URL, an die Ihr SDK Events sendet). Es wird PostgreSQL 14 oder neuer benötigt. Valkey oder Redis 7 oder neuer sind optional; sie beschleunigen größere Instanzen.

Die Installation erfolgt über Docker und eine Compose-Datei:

sudo apt install docker.io
curl -O https://glitchtip.com/assets/compose.sample.yml
mv compose.sample.yml compose.yml

Bearbeiten Sie den Environment-Abschnitt, bevor Sie den Dienst starten. Die zwingend erforderlichen Werte sind das Secret, die Domain und der Mail-Pfad:

SECRET_KEY: <output of openssl rand -base64 50>
GLITCHTIP_DOMAIN: https://errors.example.com
DEFAULT_FROM_EMAIL: errors@example.com
EMAIL_URL: smtp://user:password@smtp.example.com:587

Das Beispiel verknüpft DATABASE_URL bereits mit dem eigenen postgres-Dienst. Ändern Sie diese Zeile nur, wenn Sie eine extern betriebene Datenbank verwenden. GLITCHTIP_DOMAIN muss das Schema enthalten. Ohne https:// am Anfang werden die Links in Benachrichtigungs-E-Mails falsch generiert und führen zu einer URL, die nicht erreichbar ist.

Starten Sie den Dienst und überwachen Sie den ersten Boot-Vorgang:

docker compose up -d
docker compose logs -f web

Die Image-Tags im Beispiel lauten mit Stand August 2026 postgres:18, valkey/valkey:9 und glitchtip/glitchtip:6. Behalten Sie diese festen Versionen bei. Eine Compose-Datei mit latest führt beim nächsten docker compose pull ein Upgrade Ihrer Datenbank-Engine durch. Ein Major-Version-Sprung bei Postgres während eine Instanz läuft, führt dazu, dass der Error-Tracker nicht mehr startet.

Um den Bereich von 256 MB bis 512 MB zu erreichen, finden Sie in den Kommentaren der Beispieldatei Hinweise zum Deaktivieren von Funktionen, beginnend mit Valkey sowie den optionalen Log- und Uptime-Features. Ohne Valkey nutzt GlitchTip die Datenbank für Cache- und Queue-Aufgaben; dies ist langsamer, aber weiterhin korrekt. Im All-in-One-Modus läuft der Worker innerhalb des Web-Prozesses, sodass Sie nur einen statt zwei Anwendungs-Container verwalten müssen.

Schalten Sie einen Proxy davor. Die Dokumentation von GlitchTip empfiehlt einen Proxy oder Load Balancer, der Anfragen puffert und Chunked Transfer-Encoding verarbeitet; als Beispiel wird Nginx genannt. Ohne Pufferung belegt ein langsamer Client einen Application-Worker für die gesamte Dauer des Uploads. Einige wenige langsame Sender können so alle verfügbaren Worker belegen, wodurch Anfragen von Clients mit stabiler Verbindung in Timeouts laufen.

Upgrades sind unkompliziert:

docker compose pull
docker compose stop
docker compose up -d

Datenbank-Migrationen werden beim Start automatisch ausgeführt. Erstellen Sie dennoch vorab einen Dump, da eine automatische Migration dennoch eine Migration bleibt.

Bugsink: Ein Container und eine Lizenz, die Sie lesen müssen

Bugsink ist das leichteste der drei Programme. Es spricht das Sentry-SDK-Protokoll und benötigt weder eine Message-Queue noch externe Dienste außer einer Datenbank. SQLite ist der Standard; MySQL und PostgreSQL werden unterstützt, sobald die Anforderungen steigen.

Eine temporäre Instanz, um die Oberfläche vor einer Entscheidung zu testen:

docker pull bugsink/bugsink:latest
docker run \
  -e SECRET_KEY=PUT_AN_ACTUAL_RANDOM_SECRET_HERE_OF_AT_LEAST_50_CHARS \
  -e CREATE_SUPERUSER=admin@example.org:admin \
  -e PORT=8000 \
  -p 8000:8000 \
  bugsink/bugsink

Öffnen Sie http://localhost:8000/ und melden Sie sich mit der Adresse und dem Passwort an, die Sie in CREATE_SUPERUSER übergeben haben. Dieser Container speichert beim Stoppen keine Daten. Für eine produktive Instanz verwenden Sie das compose-Beispiel des Projekts, das bugsink/bugsink:2 mit postgres:17-alpine kombiniert und DATABASE_URL, BASE_URL sowie BEHIND_HTTPS_PROXY setzt. Generieren Sie das Secret korrekt:

openssl rand -base64 50

BASE_URL muss mit der URL übereinstimmen, die Ihre Benutzer und SDKs tatsächlich verwenden, einschließlich des Schemas. Belassen Sie es bei http://localhost:8000 auf einem Server, den Sie unter https://errors.example.com erreichen, und jeder Link in einer Benachrichtigungs-E-Mail verweist auf einen Host, der für den Empfänger nicht auflösbar ist. Setzen Sie BEHIND_HTTPS_PROXY auf true, wenn Nginx oder Caddy TLS (Transport Layer Security) davor terminiert. Andernfalls erstellt Bugsink http://-URLs hinter Ihrem https://-Proxy, und Browser blockieren den gemischten Inhalt (Mixed Content).

Der Anbieter veröffentlicht eigene Durchsatzwerte: 18 Ereignisse pro Sekunde bei jeweils 50 KB. Das entspricht 1,5 Millionen Ereignissen pro Tag auf einem VPS mit 2 vCPU und 4 GB RAM. Betrachten Sie dies als Orientierungshilfe für die Leistungsfähigkeit des Tools, nicht als Garantie für Ihre Arbeitslast. Es zeigt jedoch, dass die Obergrenze weit über dem liegt, was eine kleine Anwendung erzeugt.

Nun zur Lizenz – dies ist der Teil, den Sie lesen sollten, bevor das Programm in Ihrem Stack landet. Bugsink wird unter der PolyForm Shield License 1.0.0 veröffentlicht. Das ist "Source Available", nicht Open Source: Sie dürfen es ausführen und modifizieren, aber Sie dürfen es nicht verwenden, um ein Produkt zu erstellen, das mit Bugsink konkurriert. Für einen internen Fehler-Tracker ist diese Einschränkung irrelevant. Falls Ihr Unternehmen Entwickler-Tools verkauft, lassen Sie den Lizenztext vorab prüfen.

Fehlerverfolgung und LLM-Observability sind weiterhin zwei verschiedene Werkzeuge

Suchen Sie nach einem Tool, das sowohl Fehlerverfolgung als auch LLM-Observability (Large Language Model) vereint, werden Sie auf Produkte stoßen, die beides versprechen. Die Datenstrukturen unterscheiden sich jedoch, weshalb eine Zusammenführung bisher nicht stattfindet. Ein Fehlerverfolgungssystem empfängt eine Exception mit einem Stack-Trace, berechnet daraus einen Fingerabdruck und fasst tausende Vorkommen zu einem einzigen Problem mit einem Zähler zusammen. Ein LLM-Tracing-Tool empfängt einen Span, der einen Prompt, eine Antwort, eine Token-Anzahl und eine Latenz enthält. Es muss jeden dieser Einträge einzeln speichern, da zwei Aufrufe mit identischen Eingaben separate Ereignisse darstellen, die eine Überprüfung wert sind.

Betreiben Sie daher beides. Senden Sie Exceptions an das Fehlerverfolgungssystem und leiten Sie Modellaufrufe an ein dafür spezialisiertes System weiter: selbst gehostetes Langfuse für Agent-Tracing deckt diesen Bereich ab, und selbst gehostete KI-Observability nähert sich derselben Aufgabe aus einem anderen Blickwinkel. Ihre Anwendung erzeugt bereits beide Arten von Fehlern. Ein Modellaufruf, der überzeugend klingenden Unsinn zurückgibt, löst keine Exception aus, weshalb ein Fehlerverfolgungssystem ihn Ihnen niemals anzeigen wird.

Festplattenwachstum ist der Fehler, der Sie später einholt

Jeder Fehler-Tracker ist eine schreibintensive Datenbank mit unbegrenztem Input. Ihre Anwendung entscheidet, wie viel sie schreibt, und ein neuer Bug in einem häufig genutzten Codepfad kann über Nacht eine Million Ereignisse erzeugen.

GlitchTip veröffentlicht einen Richtwert, mit dem man planen kann: Eine Instanz, die eine Million Ereignisse pro Monat verarbeitet, benötigt unter Umständen 30 GB Festplattenspeicher. Dies deckt einen Monat der Datenerfassung bei dieser Rate ab, und Ihr Aufbewahrungszeitraum bestimmt, wie viele Monate Sie gleichzeitig speichern.

Bugsink geht das Problem von der anderen Seite an. Anstatt eines festen Kontingents wendet es einen Aufbewahrungsalgorithmus basierend auf Ereignisanzahl und Ereignisalter an und legt die Obergrenzen direkt offen: MAX_RETENTION_EVENT_COUNT für die gesamte Installation, MAX_RETENTION_PER_PROJECT_EVENT_COUNT pro Projekt und MAX_EVENT_AGE_DAYS als absolutes Limit. Ein installationsweites Ereignisbudget festzulegen ist der ehrliche Weg, um eine Festplatte zu dimensionieren, da dieses Budget der Festplatte entspricht.

Überwachen Sie die tatsächlichen Zahlen auf dem System:

df -h /
docker system df -v
du -sh /var/lib/docker/volumes/*

docker system df -v gibt die Größen pro Volume aus, sodass Sie sehen können, welcher Dienst wächst. Ein Volume, das ohne Änderung des Datenverkehrs jede Woche mehrere Gigabyte zunimmt, bedeutet meist, dass die Aufbewahrungsrichtlinie nie konfiguriert wurde. Somit wird nichts gelöscht und die einzige Grenze ist die Partition.

Arbeitsspeicher ist das gleiche Problem in anderer Form. Ein Stack ohne Limits nimmt alles, was der Kernel anbietet. Wenn der Maschine der Speicher ausgeht, wählt der OOM-Killer den größten Prozess aus. Das kann durchaus Ihr Webserver sein und nicht der Tracker, der das Problem verursacht hat. Geben Sie jedem Dienst eine Obergrenze: Speicherlimits in Docker Compose zeigt die Syntax und das Verhalten eines Containers, wenn er sein Limit erreicht. Ein Container, der an seinem eigenen Limit beendet wird, ist ein isolierter Fehler. Ein Container, der vom Kernel beendet wird, reißt einen Nachbarn mit in den Abgrund.

Welcher Stack passt zu welchem VPS

• 1 GB oder 2 GB mit Reserven: GlitchTip im All-in-One-Modus bei deaktiviertem Valkey oder Bugsink mit SQLite. Beide laufen hier problemlos für eine Handvoll Anwendungen.
• 4 GB: Bugsink mit PostgreSQL oder GlitchTip mit aktiviertem Valkey und einem separaten Worker-Dienst. Ab dieser Größe ist kein Tuning mehr nötig, der Betrieb läuft stabil.
• 8 GB: Immer noch zu wenig für den offiziellen Sentry-Stack. Investieren Sie den Speicher lieber in ein längeres Aufbewahrungsfenster und eine größere Festplatte für die von Ihnen gewählte schlanke Option.
• Mindestens 16 GB, 32 GB empfohlen: Der offizielle Sentry-Self-Hosted-Stack. Dies ist nur sinnvoll, wenn Sie eine Sentry-Funktion benötigen, die von den schlankeren Projekten nicht unterstützt wird. Prüfen Sie die spezifische Funktion vorab in der Dokumentation des jeweiligen Projekts, da die kompatiblen Projekte die gängigen Funktionen bereits abdecken.

Egal was Sie betreiben, der Error-Tracker kann seinen eigenen Ausfall nicht melden. Überwachen Sie ihn daher von einem anderen System aus: Uptime Kuma, das von einem anderen Server aus überwacht benachrichtigt Sie, wenn der Tracker ausgefallen ist. Genau in diesem Moment beginnt Ihre Anwendung meist damit, Fehler zu werfen, die dann niemand mehr aufzeichnet.

Wann ein gehosteter Plan die günstigere Lösung ist

Das Self-Hosting eines Error-Trackers lohnt sich, wenn Datenschutzvorgaben dies erfordern oder wenn das Ereignisvolumen so hoch ist, dass eine Abrechnung pro Ereignis zu teuer wird. Außerhalb dieser Fälle sollten Sie die Kosten ehrlich kalkulieren. Die dokumentierte Mindestanforderung für Sentry ist ein Server mit 16 GB RAM, 4 Kernen und schnellem Speicher; ein VPS dieser Größe ist kein günstiger VPS. Hinzu kommt der operative Aufwand: Sie müssen bei jedem Update die strikte Reihenfolge einhalten und vor jeder Migration einen Snapshot erstellen – und das mehrmals pro Jahr.

GlitchTip und Bugsink verändern diese Rechnung grundlegend, da ein System mit 512 MB bis 4 GB RAM kostengünstig ist und das Upgrade ein docker compose pull darstellt. Deshalb entscheiden sich die meisten Anwender, die diese Frage stellen, für eines der kompatiblen Projekte anstatt für den offiziellen Stack. Sie wollten Error-Tracking und keine verteilte Daten-Pipeline, die ständig betreut werden muss.

Falls Sie noch abwägen, was überhaupt auf den Server gehört, ordnet die umfassendere Liste der Dienste, die sich für das Self-Hosting lohnen das Error-Tracking neben anderen Diensten ein, die um denselben Arbeitsspeicher konkurrieren.

FAQ

Kann ich Sentry auf einem 2 GB VPS selbst hosten?

Nein. Die Dokumentation für das Self-Hosting von Sentry schreibt mindestens 4 CPU-Kerne, 16 GB RAM zuzüglich 16 GB Swap sowie 20 GB freien Festplattenspeicher vor. Der Stack führt gleichzeitig Postgres, ClickHouse, Kafka, Redis und mehrere Worker-Prozesse aus; auf einem kleinen System beendet der Kernel daher Container, bevor die Installation abgeschlossen ist. Überprüfen Sie dies mit dmesg -T | grep -i 'out of memory', das eine Zeile ausgibt, die den beendeten Prozess benennt. Verwenden Sie für einen 2 GB VPS stattdessen GlitchTip, das mit 512 MB spezifiziert ist, oder Bugsink, das als einzelner Container auf Basis von SQLite läuft.

Muss ich meinen Anwendungscode ändern, um von Sentry zu GlitchTip oder Bugsink zu wechseln?

Nein. Beide akzeptieren Ereignisse von den Open-Source-SDKs von Sentry. Sie behalten das bereits installierte SDK bei und ändern lediglich einen Wert: die DSN, also die URL, an die das SDK Ereignisse sendet. Falls diese noch hartcodiert ist, verschieben Sie sie in eine Umgebungsvariable, verweisen Sie auf den neuen Host, lösen Sie dann eine Test-Exception aus und beobachten Sie, ob sie ankommt. Falls nichts erscheint, prüfen Sie, ob die Projektkennung in der DSN mit einem auf dem neuen Server existierenden Projekt übereinstimmt und ob Ihre Firewall der Anwendung erlaubt, diesen Host und Port zu erreichen.

Wie viel Festplattenspeicher benötigt selbst gehostetes Error-Tracking?

Dies hängt eher von Ihrem Ereignisvolumen und dem Aufbewahrungszeitraum ab als vom Werkzeug selbst. GlitchTip gibt 30 GB für eine Instanz an, die eine Million Ereignisse pro Monat verarbeitet. Bugsink erlaubt es Ihnen, das Budget direkt über MAX_RETENTION_EVENT_COUNT und MAX_EVENT_AGE_DAYS festzulegen; Sie wählen also die Obergrenze, woraus sich der Speicherbedarf ergibt. Konfigurieren Sie die Aufbewahrungsrichtlinie am ersten Tag. Ein Tracker ohne Aufbewahrungsrichtlinie wächst, bis df -h 100% anzeigt; an diesem Punkt stoppt die Aufnahme und Sie verlieren die Fehler, die Sie am dringendsten sehen wollten.

Warum schlägt das Upgrade von selbst gehostetem Sentry immer wieder fehl?

Weil das Upgrade einen zwingenden Zwischenschritt übersprungen hat. Sentry für das Self-Hosting definiert spezifische Versionen mit Datenbankmigrationen, die zwingend durchlaufen werden müssen. Stand August 2026 sind dies 9.1.2, 21.5.0, 21.6.3, 23.6.2, 23.11.0, 24.8.0, 25.5.1, 26.5.0 und 26.7.0. Ein direkter Sprung von einer alten Version auf die neueste überspringt diese Migrationen, sodass Schema und Code nicht mehr kompatibel sind und das Upgrade abbricht. Arbeiten Sie jeden dieser Zwischenschritte nacheinander ab und führen Sie bei jedem ./install.sh aus. Erstellen Sie vor Beginn einen Snapshot des Servers und lesen Sie die dokumentierte Liste der zu vermeidenden Releases, zu denen unter anderem 23.7.0, 25.9.0 und 25.12.0 gehören.