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 augustus 2026. Het zijn geen vergelijkbare meetwaarden, dus lees de toelichting 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 geeft 256 MB op als werkminimum, of 128 MB plus swap bij een zorgvuldige configuratie. De 4 GB van Bugsink is geen van beide: het is de specificatie van de server die de leverancier gebruikte voor de eigen doorvoerbenchmark. Een gepubliceerd cijfer is een uitgangspunt, geen garantie voor uw event-volume.

Sentry self-hosted: het volledige product en de bijbehorende last

De officiële stack is getsentry/self-hosted, een Docker Compose-project dat dezelfde componenten draait als Sentry in productie gebruikt. De eigen documentatie omschrijft het als "feature-complete en verpakt voor implementaties met een laag volume 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; een oudere versie van Compose faalt op de bestandssyntaxis in plaats van op iets dat Sentry doet.

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 bepaalt 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, controleer dan eerst 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 de service nooit gezond en voltooit de stack het opstartproces niet. Dit is het gebruikelijke resultaat wanneer de volledige stack wordt gedraaid onder de gedocumenteerde minimumvereisten. De documentatie waarschuwt ook voor schijfsnelheid: iowait boven 10% betekent dat de machine de ingest-pipeline niet kan bijhouden. Lees dit af in de kolom wa in top, of in 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 in volgorde uitchecken om de bijbehorende databasemigraties uit te voeren. Per augustus 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 installatiescript:

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 en een fout halverwege de database in een tussenliggende schema-status achterlaat. De meest voorkomende oorzaak van 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 was.

Nog één ding om te weten voordat u besluit: Sentry self-hosted valt onder de Functional Source License (FSL), die Sentry zelf heeft 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 publicatie 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 nieuwer. Valkey of Redis 7 of nieuwer 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 de 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, dus laat die regel ongewijzigd 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 service en bekijk de eerste opstartfase:

docker compose up -d
docker compose logs -f web

De image-tags in het voorbeeld zijn per augustus 2026 postgres:18, valkey/valkey:9 en glitchtip/glitchtip:6. Houd deze vastgepind. Een compose-bestand met latest zal uw database-engine upgraden bij de volgende docker compose pull. Een grote versie-upgrade van Postgres onder een draaiende instantie is de manier waarop een werkende error-tracker stopt met opstarten.

Om het bereik van 256 MB tot 512 MB te behalen, geven de opmerkingen in het voorbeeldbestand aan wat u kunt uitschakelen, beginnend bij 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 draait de worker 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 applicatie-worker bezet gedurende de volledige upload. Hierdoor kunnen enkele trage verzenders al uw workers bezetten en krijgen gezonde clients time-outs.

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 falen 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 gebeurtenissen genereren.

GlitchTip publiceert een cijfer waar u rekening mee moet houden: een instantie die één miljoen gebeurtenissen per maand verwerkt, heeft mogelijk 30 GB aan schijfruimte nodig. Dat dekt één maand aan gegevensinvoer bij dat volume, 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 en de ouderdom van gebeurtenissen, 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 absoluut maximum. Het instellen van een gebeurtenisbudget 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 het verkeer, betekent meestal dat er nooit retentie is geconfigureerd, waardoor er niets wordt verwijderd en de enige limiet de partitie zelf is.

Geheugen is hetzelfde probleem in een ander jasje. Een stack zonder limieten neemt alles wat de kernel aanbiedt, en wanneer de machine leeg raakt, kiest de OOM killer het grootste proces. Dat is vaak uw webserver 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 error tracker loont wanneer regels voor datalocatie dit vereisen, of wanneer uw event-volume zo hoog is dat prijzen per event nadelig uitpakken. Buiten deze gevallen moet u de rekensom eerlijk maken. De gedocumenteerde minimale vereiste 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: het in de juiste volgorde doorlopen van elke harde stop en het maken van een snapshot voor elke migratie, enkele keren per jaar.

GlitchTip en Bugsink veranderen die rekensom volledig, omdat 512 MB tot 4 GB een goedkope machine is en de upgrade een docker compose pull. 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 error tracking, 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 de moeite waard is om zelf te hosten error tracking naast de andere services die strijden om hetzelfde RAM-geheugen.

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. Verplaats deze naar een omgevingsvariabele als deze nog hardcoded is, wijs deze 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 foutopsporing 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. Bij Bugsink stelt u het budget direct in met MAX_RETENTION_EVENT_COUNT en MAX_EVENT_AGE_DAYS; u kiest het plafond en de schijfbehoefte volgt daaruit. Configureer de retentie op de eerste dag. Een tracker zonder retentiebeleid groeit totdat df -h 100% aangeeft; op dat moment stopt de verwerking en verliest u de foutmeldingen 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. Per augustus 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 upgraden 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.