Zelf-gehoste Sentry alternatieven vergelijken

Wat zelf-gehoste foutopsporing kost voordat er één event wordt opgeslagen

Zelf-gehoste foutopsporing (error tracking) wordt bepaald door één getal dat de gehele keuze beïnvloedt: de minimale hoeveelheid RAM. De eigen documentatie voor zelf-gehoste Sentry vereist 4 CPU-cores, 16 GB RAM plus 16 GB swap, en 20 GB vrije schijfruimte, nog voordat uw applicatie één enkel event verstuurt. GlitchTip documenteert 512 MB. Alle opties in dit overzicht accepteren events van dezelfde Sentry SDK's, dus dit is geen beslissing over hoe u uw code instrumenteert. Het is een beslissing over hoe groot de server is waarvoor u bereid bent te betalen en die u in de lucht wilt houden.

Gepubliceerde resourcecijfers, naast elkaar

Dit zijn de cijfers die elk project over zichzelf publiceert, per oktober 2026. Dit zijn geen vergelijkbare meetwaarden; lees daarom de opmerking bij elke rij voordat u ze vergelijkt.

[
  {
    "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"
  }
]

De 16 GB van Sentry is een gedocumenteerd minimum, waarbij dezelfde pagina 32 GB aanbeveelt. De 0.5 GB van GlitchTip is een aanbeveling; het project vermeldt 256 MB als werkend minimum, of 128 MB plus swap bij een zorgvuldige configuratie. De 4 GB van Bugsink is geen van beide: dit is de specificatie van de server die de leverancier gebruikte voor de eigen doorvoerbenchmark. Een gepubliceerd cijfer is een uitgangspunt, geen garantie voor uw eventvolume.

Sentry self-hosted: het volledige product en de volledige rekening

De officiële stack is getsentry/self-hosted, een Docker Compose-project dat dezelfde componenten draait als Sentry in productie. De eigen documentatie omschrijft het als "feature-complete en verpakt voor kleinschalige implementaties en proofs-of-concept". Die zin is de eerlijke samenvatting. U krijgt elke functie en elk bewegend onderdeel dat nodig is om die functies te laten werken.

Installeer vanaf een getagde release in plaats van vanaf 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

Start het vervolgens:

docker compose up --wait

Sentry luistert standaard op http://127.0.0.1:9000. Docker Engine 19.03.6 of nieuwer en Docker Compose 2.32.2 of nieuwer zijn vereist; het installatieprogramma controleert beide: een oudere versie van Compose stopt ./install.sh met een regel die begint met FAIL: Expected minimum, waarin de gevonden versie wordt vermeld, waarna het script met een foutmelding afsluit.

Bekijk wat u daadwerkelijk heeft gestart:

docker compose ps
free -h

docker compose ps somt elke service in de stack op, en de lijst is lang: Postgres, ClickHouse, Kafka, Redis, Relay, Snuba, Symbolicator en diverse worker- en cron-processen. Tel ze één keer, want dat aantal is uw onderhoudslast. Elk item is een proces dat kan crashen, een schijf kan vullen of een migratie kan laten mislukken.

Als een service in de status Restarting blijft staan, kijk dan eerst naar het geheugengebruik:

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

Een regel zoals Out of memory: Killed process 3412 (java) betekent dat de OOM killer (out of memory killer) van de kernel een container heeft beëindigd omdat de server onvoldoende RAM had. Hierdoor wordt die service nooit gezond en voltooit de stack het opstartproces niet. Dit is het gebruikelijke resultaat wanneer de volledige stack onder de gedocumenteerde minimumvereisten wordt gedraaid. De documentatie wijst ook op schijfsnelheid: iowait boven de 10% betekent waarschijnlijk dat de machine de ingest-pipeline niet kan bijhouden. Lees dit af in de kolom wa in top, of via iostat -x 5 als u sysstat heeft geïnstalleerd.

Upgrades zijn het onderdeel dat mensen onderschatten

Sentry self-hosted verschijnt maandelijks onder CalVer, een op de kalender gebaseerd versieschema, met een primaire release op de 15e van elke maand. U kunt niet direct van een oude versie naar de nieuwste springen. Het project definieert harde stop-versies; u moet elke versie achtereenvolgens uitchecken om de bijbehorende databasemigraties uit te voeren. Per oktober 2026 zijn de gepubliceerde harde 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 en 26.7.0. De documentatie vermeldt ook releases die moeten worden overgeslagen vanwege migratieproblemen, waaronder 23.7.0, 25.9.0, 25.12.0 en het bereik van 26.3.0 tot 26.4.0.

Een upgrade bestaat uit een checkout gevolgd door het opnieuw uitvoeren van het installatieprogramma:

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

Maak een snapshot van de server voordat u begint, omdat een migratie over een grote ClickHouse-dataset uren kan duren. Een fout halverwege laat de database achter tussen twee schema's in. De voornaamste oorzaak van de meeste mislukte self-hosted Sentry-upgrades: de server is een jaar lang op één versie blijven staan, waardoor de sprong meerdere harde stops tegelijk overbrugt en een van de overgeslagen migraties cruciaal bleek te zijn.

Nog één ding om te weten voordat u begint. Sentry self-hosted valt onder de Functional Source License (FSL), die door Sentry zelf is geïntroduceerd. Het is 'fair source' in plaats van OSI-goedgekeurde open source: u mag het voor uzelf draaien, maar u mag het niet verkopen als een concurrerende dienst. Elke release wordt twee jaar na uitgave omgezet naar Apache 2.0.

GlitchTip: het antwoord voor 512 MB

GlitchTip is MIT-gelicentieerd en ontvangt events van de open-source SDK's van Sentry. Een geïnstrumenteerde applicatie migreert door één waarde aan te passen: de DSN (data source name, de URL waarnaar uw SDK events verstuurt). Het vereist PostgreSQL 14 of hoger. Valkey of Redis 7 of hoger is optioneel; dit versnelt grotere instanties.

De installatie bestaat uit Docker en één compose-bestand:

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

Bewerk de environment-sectie voordat u begint. De waarden die u moet instellen zijn het secret, het domein en het mail-pad:

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

Het voorbeeld koppelt DATABASE_URL al aan zijn eigen postgres-service. Wijzig deze regel niet, tenzij u verwijst naar een database die u elders beheert. GLITCHTIP_DOMAIN moet het schema bevatten. Zonder https:// aan het begin worden de links in waarschuwingsmails onjuist opgebouwd en landen ze op een URL die niet reageert.

Start de applicatie en monitor de eerste opstartfase:

docker compose up -d
docker compose logs -f web

De image-tags in het voorbeeld van oktober 2026 zijn postgres:18, valkey/valkey:9 en glitchtip/glitchtip:6. Houd deze vastgepind. Een compose-bestand met latest haalt bij de volgende docker compose pull een nieuwe database-engine op en schakelt hiernaar over zodra docker compose up -d de container opnieuw aanmaakt. Een major-versiesprong van Postgres in een bestaande datamap is de manier waarop een werkende error tracker stopt met opstarten.

Om het bereik van 256 MB tot 512 MB te halen, geven de opmerkingen in het voorbeeldbestand aan wat u kunt uitschakelen, te beginnen met Valkey en de optionele log- en uptime-functies. Draaien zonder Valkey betekent dat GlitchTip de database gebruikt voor cache- en wachtrijtaken; dit is trager, maar nog steeds correct. De 'all-in-one'-modus voert de worker uit binnen het webproces, waardoor u één applicatiecontainer beheert in plaats van twee.

Plaats een proxy voor de applicatie. De documentatie van GlitchTip vereist een proxy of load balancer die verzoeken buffert en chunked Transfer-Encoding afhandelt; nginx wordt als werkend voorbeeld gegeven. Zonder buffering houdt een trage client een applicatieworker bezet gedurende de volledige upload. Hierdoor kunnen enkele trage verzenders al uw workers bezetten en krijgen gezonde clients een timeout.

Upgrades zijn eenvoudig:

docker compose pull
docker compose stop
docker compose up -d

Database-migraties worden automatisch uitgevoerd bij het opstarten. Maak desondanks eerst een dump, want een automatische migratie blijft een migratie.

Bugsink: één container en een licentie die u moet lezen

Bugsink is de lichtste van de drie. Het spreekt het Sentry SDK-protocol en draait zonder message queue en zonder externe service, afgezien van een database. SQLite is de standaard, waarbij MySQL en PostgreSQL worden ondersteund wanneer u uit de capaciteit groeit.

Een tijdelijke instantie om de interface te bekijken voordat u zich vastlegt:

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

Open http://localhost:8000/ en meld u aan met het adres en wachtwoord dat u in CREATE_SUPERUSER heeft opgegeven. Die container bewaart niets wanneer deze stopt. Gebruik voor een echte instantie het compose-voorbeeld van het project, dat bugsink/bugsink:2 koppelt aan postgres:17-alpine en DATABASE_URL, BASE_URL en BEHIND_HTTPS_PROXY instelt. Genereer het geheim op de juiste wijze:

openssl rand -base64 50

BASE_URL moet overeenkomen met de URL die uw gebruikers en SDK's daadwerkelijk gebruiken, inclusief het schema. Laat dit op http://localhost:8000 staan op een server die u bereikt via https://errors.example.com, anders wijst elke link in een notificatie-e-mail naar een host die niet oplost voor de persoon die deze leest. Stel BEHIND_HTTPS_PROXY in op true wanneer Nginx of Caddy TLS (transport layer security) ervoor afhandelt, omdat Bugsink anders http://-URL's bouwt achter uw https://-proxy en browsers de gemengde inhoud blokkeren.

De leverancier publiceert eigen doorvoercijfers: 18 events per seconde van elk 50 KB, wat neerkomt op 1,5 miljoen events per dag op een VPS met 2 vCPU's en 4 GB RAM. Beschouw dit als een indicatie van de schaal van de tool in plaats van een garantie voor uw werklast. Het geeft wel aan dat het plafond ver boven wat een kleine applicatie produceert ligt.

Dan de licentie, en dit is het gedeelte dat u moet lezen voordat het in uw stack terechtkomt. Bugsink is uitgebracht onder de PolyForm Shield License 1.0.0. Dit is 'source available', geen open source: u mag het draaien en aanpassen, maar u mag het niet gebruiken om iets te bouwen dat concurreert met Bugsink. Voor een interne foutvolger is die beperking nooit aan de orde. Als uw bedrijf ontwikkelaarstools verkoopt, laat dan eerst iemand de licentietekst lezen.

Foutopsporing en LLM-observability zijn nog steeds twee aparte tools

Zoek naar één tool die zowel foutopsporing (error tracking) als observability voor Large Language Models (LLM) combineert, en u zult producten vinden die beide claimen te doen. De datastructuren verschillen echter, wat de reden is dat deze samenvoeging uitblijft. Een error tracker ontvangt een exception met een stack trace, berekent daar een vingerafdruk van en brengt duizenden voorvallen terug tot één issue met een teller. Een LLM-tracingtool ontvangt een span met daarin een prompt, een antwoord, een aantal tokens en de latentie. Deze tool moet elk van deze gegevens bewaren, omdat twee aanroepen met identieke invoer nog steeds afzonderlijke gebeurtenissen zijn die het bekijken waard zijn.

Gebruik daarom beide. Stuur exceptions naar de error tracker en stuur modelaanroepen naar een plek die daarvoor is gebouwd: self-hosted Langfuse voor agent-tracing behandelt die kant, en self-hosted AI observability benadert dezelfde taak vanuit een andere hoek. Uw applicatie produceert al beide soorten fouten. Een modelaanroep die zelfverzekerde onzin teruggeeft, genereert namelijk geen enkele exception, waardoor een error tracker dit nooit aan u zal tonen.

Schijfgroei is het probleem dat u later inhaalt

Elke fouttracker is een database met een hoge schrijfbelasting en een onbegrensde invoer. Uw applicatie bepaalt hoeveel er wordt geschreven, en één nieuwe bug in een veelgebruikt codepad kan 's nachts een miljoen events genereren.

GlitchTip publiceert een cijfer waar u rekening mee kunt houden: een instantie die een miljoen events per maand verwerkt, heeft mogelijk 30 GB aan schijfruimte nodig. Dat dekt één maand aan ingest tegen dat tarief, en uw retentieperiode bepaalt hoeveel maanden u tegelijkertijd opslaat.

Bugsink benadert dit vanuit de andere kant. In plaats van een vast quotum past het een retentie-algoritme toe op basis van het aantal events en de ouderdom van events, en het stelt de limieten direct bloot: MAX_RETENTION_EVENT_COUNT voor de gehele installatie, MAX_RETENTION_PER_PROJECT_EVENT_COUNT per project, en MAX_EVENT_AGE_DAYS als een absolute grens. Het instellen van een eventbudget voor de gehele installatie is de eerlijke manier om een schijf te dimensioneren, omdat dat budget de schijf is.

Monitor de werkelijke cijfers op de server:

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

docker system df -v toont de groottes per volume, zodat u kunt zien welke service groeit. Een volume dat per week enkele gigabytes toeneemt zonder verandering in verkeer, betekent meestal dat de retentieperiode nog steeds aan het vullen is, of meer bevat dan de partitie aankan bij uw event-tarief. De retentie ongewijzigd laten betekent niet dat er niets verloopt: de standaard .env van Sentry stelt SENTRY_EVENT_RETENTION_DAYS=90 in, en de standaardwaarde van GLITCHTIP_RETENTION_DAYS in GlitchTip is 90. Verlaag de periode om aan te sluiten bij de schijf in plaats van te wachten tot de partitie volloopt.

Geheugen is hetzelfde probleem in een ander jasje. Een stack zonder limieten neemt alles wat de kernel aanbiedt, en wanneer de machine leeg raakt, beëindigt de OOM killer het proces met de hoogste badness score. De kernel berekent deze score hoofdzakelijk op basis van hoeveel geheugen elk proces gebruikt, gecorrigeerd door de oom_score_adj. Dat kan heel goed uw webserver zijn in plaats van de tracker die het probleem veroorzaakte. Geef elke service een plafond: geheugenlimieten in Docker Compose toont de syntaxis en wat een container doet wanneer deze zijn limiet bereikt. Een container die wordt beëindigd op zijn eigen limiet is een geïsoleerd falen. Een container die door de kernel wordt beëindigd, neemt een buurproces met zich mee.

Welke stack past bij welke VPS

• 1 GB, of 2 GB met ruimte over: GlitchTip in all-in-one modus met Valkey uitgeschakeld, of Bugsink op SQLite. Beide draaien hier comfortabel op voor een handvol applicaties.
• 4 GB: Bugsink met PostgreSQL, of GlitchTip met Valkey ingeschakeld en een aparte worker-service. Dit is de grootte waarbij u stopt met finetunen en het simpelweg draait.
• 8 GB: nog steeds te weinig voor de officiële Sentry-stack. Besteed dit aan een langere retentieperiode en een grotere schijf voor de lichtgewicht optie die u heeft gekozen.
• 16 GB minimaal, 32 GB aanbevolen: de officiële Sentry self-hosted stack, en alleen wanneer u een Sentry-functie nodig heeft die de lichtere projecten niet ondersteunen. Controleer eerst de specifieke functie in de documentatie van elk project, aangezien de compatibele projecten de meest gangbare functies dekken.

Wat u ook draait, de error tracker kan zijn eigen uitval niet rapporteren. Stel een controle in vanaf een andere machine: Uptime Kuma die vanaf een andere machine monitort zal u waarschuwen dat de tracker offline is; precies het moment waarop uw applicatie fouten begint te genereren die niemand meer registreert.

Wanneer een gehost abonnement de goedkopere oplossing is

Het zelf hosten van een fouttracker loont wanneer regels voor datalocatie dit vereisen, of wanneer uw event-volume zo hoog is dat prijzen per event ongunstig worden. Buiten deze gevallen moet u de rekensom eerlijk maken. Het gedocumenteerde minimum voor Sentry is een server met 16 GB RAM, 4 cores en een snelle schijf; een VPS van dat formaat is geen goedkope VPS. Tel daar het operationele werk bij op: elke harde stop in de juiste volgorde doorlopen en voor elke migratie een snapshot maken, een paar keer per jaar.

GlitchTip en Bugsink veranderen die rekensom volledig, omdat 512 MB tot 4 GB een goedkope server is en de upgrade een docker compose pull gevolgd door een herstart vereist. Daarom eindigen de meeste mensen die deze vraag stellen bij een van de compatibele projecten in plaats van bij de officiële stack. Zij wilden foutopsporing, geen gedistribueerde datapijplijn om te onderhouden.

Als u nog aan het bepalen bent wat er überhaupt op de server thuishoort, plaatst de bredere lijst van wat het waard is om zelf te hosten foutopsporing naast de andere services die om hetzelfde RAM-geheugen strijden.

FAQ

Kan ik Sentry zelf hosten op een 2 GB VPS?

Nee. De documentatie voor Sentry self-hosted vereist minimaal 4 CPU-cores, 16 GB RAM plus 16 GB swap, en 20 GB vrije schijfruimte. De stack draait tegelijkertijd Postgres, ClickHouse, Kafka, Redis en diverse worker-processen. Op een kleine server beëindigt de kernel daarom containers voordat de installatie is voltooid. Controleer dit met dmesg -T | grep -i 'out of memory', dat een regel toont met de naam van het beëindigde proces. Gebruik voor een 2 GB VPS GlitchTip, dat 512 MB vereist, of Bugsink, dat als een enkele container op SQLite draait.

Moet ik mijn applicatiecode aanpassen om over te stappen van Sentry naar GlitchTip of Bugsink?

Nee. Beide accepteren events van de open-source SDK's van Sentry. U behoudt de SDK die u al heeft geïnstalleerd en wijzigt slechts één waarde: de DSN, de URL waarnaar de SDK events verstuurt. Plaats deze in een omgevingsvariabele als deze nog hardcoded is, verwijs naar de nieuwe host, genereer vervolgens een test-exception en controleer of deze aankomt. Als er niets verschijnt, controleer dan of de project-identifier in de DSN overeenkomt met een project dat op de nieuwe server bestaat, en of uw firewall toestaat dat de applicatie die host en poort bereikt.

Hoeveel schijfruimte heeft zelf-gehoste error tracking nodig?

Dat hangt af van uw event-volume en uw retentieperiode, niet van de tool zelf. GlitchTip adviseert 30 GB voor een instantie die één miljoen events per maand verwerkt. Bugsink laat u het budget direct instellen met MAX_RETENTION_EVENT_COUNT en MAX_EVENT_AGE_DAYS, waardoor u zelf het plafond kiest en de schijfbehoefte daaruit volgt. Controleer de retentie op de eerste dag: Sentry en GlitchTip worden beide geleverd met een venster van 90 dagen, wat meer ruimte in beslag kan nemen dan uw schijf toelaat bij uw huidige event-frequentie. Een tracker die meer bewaart dan de schijf aankan, groeit totdat df -h 100% aangeeft; op dat moment stopt de verwerking en verliest u de errors die u juist wilde inzien.

Waarom mislukt het upgraden van zelf-gehoste Sentry steeds?

Omdat de upgrade een verplichte tussenstap heeft overgeslagen. Sentry self-hosted definieert specifieke versies met database-migraties die u moet doorlopen. Sinds oktober 2026 zijn dit 9.1.2, 21.5.0, 21.6.3, 23.6.2, 23.11.0, 24.8.0, 25.5.1, 26.5.0 en 26.7.0. Direct overstappen van een oude release naar de nieuwste slaat deze migraties over, waardoor het schema en de code niet langer overeenkomen en de upgrade halverwege stopt. Doorloop elke verplichte tussenstap in de juiste volgorde en voer bij elke stap ./install.sh uit. Maak een snapshot van de server voordat u begint en lees de gedocumenteerde lijst met releases die u moet vermijden, waaronder 23.7.0, 25.9.0 en 25.12.0.