Alternative a Sentry self-hosted: RAM e costi a confronto

Qual è il costo dell'error tracking self-hosted prima di archiviare un singolo evento

L'error tracking self-hosted ha un parametro che determina l'intera scelta: la quantità minima di RAM. La documentazione ufficiale di Sentry per l'installazione self-hosted richiede 4 core CPU, 16 GB di RAM, 16 GB di swap e 20 GB di spazio libero su disco, prima ancora che l'applicazione invii un singolo evento. GlitchTip documenta un requisito di 512 MB. Tutte le soluzioni elencate qui accettano eventi dagli stessi SDK Sentry, quindi la scelta non riguarda il modo in cui strumentare il codice. Riguarda le dimensioni del server che si è disposti a pagare e a mantenere operativo.

Risorse pubblicate dai progetti, a confronto

Questi sono i valori che ogni progetto pubblica per il proprio utilizzo, aggiornati ad agosto 2026. Non rappresentano lo stesso tipo di misurazione, quindi leggi la nota in ogni riga prima di confrontarli.

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

I 16 GB di Sentry sono un minimo documentato; nella stessa pagina sono consigliati 32 GB. I 0.5 GB di GlitchTip sono una raccomandazione; il progetto indica 256 MB come minimo operativo, oppure 128 MB più swap con una configurazione accurata. Il valore di 4 GB di Bugsink non rientra in nessuna delle due categorie: corrisponde alla macchina usata dal fornitore per il proprio benchmark di throughput. Un valore pubblicato è un punto di partenza, non una garanzia rispetto al volume di eventi.

Sentry self-hosted: il prodotto completo e il relativo costo operativo

Lo stack ufficiale è getsentry/self-hosted, un progetto Docker Compose che esegue gli stessi componenti usati da Sentry in produzione. La documentazione del progetto lo descrive come "completo di tutte le funzionalità e pacchettizzato per deployment a basso volume e prove di concetto". Questa frase ne riassume correttamente la natura. Sono disponibili tutte le funzionalità, insieme a tutti i componenti necessari per eseguirle.

Installalo da una release contrassegnata, non da 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

Quindi avvialo:

docker compose up --wait

Per impostazione predefinita, Sentry è in ascolto su http://127.0.0.1:9000. Sono richiesti Docker Engine 19.03.6 o versione successiva e Docker Compose 2.32.2 o versione successiva. Una versione precedente di Compose non riesce a interpretare la sintassi del file, indipendentemente da Sentry.

Controlla che cosa hai effettivamente avviato:

docker compose ps
free -h

docker compose ps elenca tutti i servizi dello stack, e l'elenco è lungo: Postgres, ClickHouse, Kafka, Redis, Relay, Snuba, Symbolicator e diversi processi worker e cron. Conta i servizi almeno una volta, perché quel numero rappresenta il carico di manutenzione. Ogni voce corrisponde a un processo che può terminare in modo anomalo, riempire un disco o non completare una migrazione.

Se un servizio rimane nello stato Restarting, controlla prima di tutto la memoria:

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

Una riga come Out of memory: Killed process 3412 (java) indica che l'OOM killer del kernel (out of memory killer) ha terminato un container perché il server ha esaurito la RAM. Di conseguenza, il servizio non raggiunge mai lo stato healthy e lo stack non completa l'avvio. Questo è il risultato tipico dell'esecuzione dello stack completo al di sotto dei requisiti minimi documentati. La documentazione segnala anche la velocità del disco: un valore iowait superiore al 10% indica che la macchina non riesce a sostenere il ritmo della pipeline di ingestione. Leggilo dalla colonna wa in top oppure da iostat -x 5, se hai installato sysstat.

Gli aggiornamenti sono la parte che si tende a sottovalutare

Sentry self-hosted viene rilasciato ogni mese secondo CalVer, uno schema di versionamento basato sul calendario, con una release principale il giorno 15 di ogni mese. Non puoi passare direttamente da una versione precedente all'ultima disponibile. Il progetto definisce versioni intermedie obbligatorie e devi selezionarle una alla volta, nell'ordine corretto, per applicare le relative migrazioni del database. Ad agosto 2026 le versioni intermedie obbligatorie pubblicate sono 9.1.2, 21.5.0, 21.6.3, 23.6.2, 23.11.0, 24.8.0, 25.5.1, 26.5.0 e 26.7.0. La documentazione elenca anche le release da evitare a causa di problemi nelle migrazioni, tra cui 23.7.0, 25.9.0, 25.12.0 e l'intervallo da 26.3.0 a 26.4.0.

Un aggiornamento consiste nel selezionare una release e rieseguire l'installer:

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

Crea uno snapshot del server prima di iniziare, perché una migrazione su un dataset ClickHouse di grandi dimensioni può richiedere ore. Un errore durante l'operazione lascia il database in uno stato intermedio tra due schemi. La causa più comune degli aggiornamenti non riusciti di Sentry self-hosted è semplice: il server è rimasto per un anno sulla stessa versione, quindi il salto comprende diverse versioni intermedie obbligatorie e una delle migrazioni da evitare era proprio quella necessaria.

Prima di impegnarti, devi conoscere anche un altro aspetto. Sentry self-hosted è distribuito con la Functional Source License (FSL), introdotta dallo stesso progetto Sentry. È software con sorgente disponibile, ma non open source approvato dall'OSI: puoi eseguirlo per uso personale, ma non puoi venderlo come servizio concorrente. Ogni release passa alla licenza Apache 2.0 due anni dopo la pubblicazione.

GlitchTip: la soluzione da 512 MB

GlitchTip è distribuito con licenza MIT e riceve gli eventi dagli SDK open source di Sentry. Un'applicazione già strumentata può quindi essere trasferita modificando un solo valore: il DSN (data source name, l'URL a cui l'SDK invia gli eventi). Richiede PostgreSQL 14 o versioni successive. Valkey o Redis 7 o versioni successive sono opzionali, ma rendono più rapide le istanze più grandi.

L'installazione richiede Docker e un solo file compose:

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

Modifica la sezione environment prima di avviare qualsiasi componente. Devi impostare il secret, il dominio e il percorso per la posta:

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

L'esempio collega già DATABASE_URL al relativo servizio postgres, quindi lascia quella riga invariata a meno che tu non utilizzi un database gestito altrove. GLITCHTIP_DOMAIN deve includere lo schema. Se manca https:// all'inizio, i collegamenti nelle email di avviso vengono generati in modo errato e puntano a un URL che non risponde.

Avvia il servizio e monitora il primo avvio:

docker compose up -d
docker compose logs -f web

I tag delle immagini presenti nell'esempio ad agosto 2026 sono postgres:18, valkey/valkey:9 e glitchtip/glitchtip:6. Mantienili bloccati. Un file compose che contiene latest aggiornerà il motore del database al successivo docker compose pull, e un salto di versione principale di Postgres durante l'esecuzione di un'istanza è sufficiente per impedire l'avvio di un error tracker funzionante.

Per rientrare nell'intervallo da 256 MB a 512 MB, i commenti presenti nel file di esempio indicano cosa disattivare, a partire da Valkey e dalle funzioni opzionali di logging e uptime. Senza Valkey, GlitchTip utilizza il database anche per la cache e la gestione delle code. L'esecuzione è più lenta, ma resta corretta. La modalità all in one esegue il worker all'interno del processo web. In questo modo gestisci un solo container applicativo invece di due.

Configura un proxy davanti all'applicazione. La documentazione di GlitchTip richiede un proxy o un load balancer che esegua il buffering delle richieste e gestisca Transfer-Encoding in modalità chunked. L'esempio completo usa nginx. Senza buffering, un client lento mantiene occupato un worker dell'applicazione per l'intera durata dell'upload. Bastano quindi pochi mittenti lenti per occupare tutti i worker disponibili, causando timeout anche ai client che funzionano correttamente.

Gli aggiornamenti sono la parte più semplice:

docker compose pull
docker compose stop
docker compose up -d

Le migrazioni del database vengono eseguite automaticamente all'avvio. Esegui comunque prima un dump, perché una migrazione automatica resta pur sempre una migrazione.

Bugsink: un container e una licenza da leggere

Bugsink è il più leggero dei tre. Implementa il protocollo Sentry SDK e funziona senza coda di messaggi né servizi esterni, ad eccezione di un database. SQLite è l'impostazione predefinita; MySQL e PostgreSQL sono supportati quando l'installazione supera i limiti di SQLite.

Per una configurazione temporanea, utile a verificare l'interfaccia prima di procedere:

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

Apri http://localhost:8000/ e accedi usando l'indirizzo e la password specificati in CREATE_SUPERUSER. Questo container non conserva alcun dato quando viene arrestato. Per un'istanza reale, usa il file compose di esempio del progetto, che associa bugsink/bugsink:2 a postgres:17-alpine e imposta DATABASE_URL, BASE_URL e BEHIND_HTTPS_PROXY. Genera correttamente il secret:

openssl rand -base64 50

BASE_URL deve corrispondere all'URL utilizzato realmente dagli utenti e dagli SDK, incluso lo schema. Lascialo impostato su http://localhost:8000 su un server raggiungibile tramite https://errors.example.com e ogni link in un'email di notifica punterà a un host che non viene risolto dalla persona che legge il messaggio. Imposta BEHIND_HTTPS_PROXY su true quando nginx o Caddy terminano TLS (Transport Layer Security) davanti a Bugsink. In caso contrario, Bugsink genera URL http:// dietro il proxy https:// e i browser bloccano il contenuto misto.

Il fornitore pubblica i propri dati sul throughput: 18 eventi al secondo, con una dimensione di 50 KB ciascuno, equivalenti a 1.5 milioni di eventi al giorno su una VPS con 2 vCPU e 4 GB. Considerali un'indicazione delle dimensioni operative dello strumento, non una garanzia per il tuo carico di lavoro. Il dato mostra comunque che il limite massimo è molto superiore a ciò che produce una singola applicazione di piccole dimensioni.

Ora la licenza. È l'aspetto da leggere prima di introdurre Bugsink nel proprio stack. Bugsink è rilasciato con PolyForm Shield License 1.0.0. Il codice è disponibile, ma il progetto non è open source: puoi eseguirlo e modificarlo, ma non puoi usarlo per creare un prodotto concorrente di Bugsink. Per un sistema interno di raccolta degli errori, questa limitazione non si applica. Se la tua azienda vende strumenti per sviluppatori, fai leggere prima il testo della licenza.

Il tracciamento degli errori e l’osservabilità degli LLM sono ancora due strumenti distinti

Se cerchi uno strumento che gestisca insieme il tracciamento degli errori e l’osservabilità dei modelli linguistici di grandi dimensioni (LLM), troverai prodotti che dichiarano di offrire entrambe le funzioni. Le strutture dei dati sono diverse, ed è per questo che l’integrazione continua a non funzionare. Un error tracker riceve un’eccezione con uno stack trace, calcola un fingerprint e raggruppa migliaia di occorrenze in un unico problema con un contatore. Uno strumento di tracing per LLM riceve uno span contenente un prompt, una risposta, il numero di token e la latenza. Deve conservare ogni elemento, perché due chiamate con input identici sono comunque eventi distinti che vale la pena analizzare.

Usa quindi entrambi gli strumenti. Invia le eccezioni all’error tracker e invia le chiamate ai modelli a uno strumento progettato per gestirle: Langfuse self-hosted per il tracing degli agenti copre questo aspetto, mentre l’osservabilità self-hosted dell’AI affronta lo stesso problema da una prospettiva diversa. La tua applicazione genera già entrambi i tipi di errore. Una chiamata al modello che restituisce contenuti privi di senso con tono sicuro non genera alcuna eccezione, quindi un error tracker non te la mostrerà mai.

La crescita del disco è il problema che si manifesta in seguito

Ogni sistema di tracking degli errori è un database con molte operazioni di scrittura e un input non limitato. È l'applicazione a determinare la quantità di dati scritti e un nuovo bug in un percorso di esecuzione molto utilizzato può generare un milione di eventi in una notte.

GlitchTip pubblica un dato utile per la pianificazione: un'istanza che gestisce un milione di eventi al mese può richiedere 30 GB di spazio su disco. Questo valore copre un mese di acquisizione a quella frequenza. La finestra di conservazione determina quanti mesi vengono memorizzati contemporaneamente.

Bugsink affronta il problema dall'altro lato. Invece di applicare una quota fissa, usa un algoritmo di conservazione basato sul numero e sull'età degli eventi ed espone direttamente i limiti: MAX_RETENTION_EVENT_COUNT per l'intera installazione, MAX_RETENTION_PER_PROJECT_EVENT_COUNT per progetto e MAX_EVENT_AGE_DAYS come limite assoluto. Impostare un budget globale per gli eventi è il modo corretto per dimensionare il disco, perché quel budget determina lo spazio necessario.

Controlla i valori effettivi sul server:

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

docker system df -v mostra le dimensioni per volume, così puoi vedere quale servizio sta crescendo. Se un volume aumenta di diversi gigabyte alla settimana senza variazioni nel traffico, di solito significa che la conservazione non è mai stata configurata. In questo caso non viene eliminato nulla e l'unico limite è la partizione.

La memoria presenta lo stesso problema in una forma diversa. Uno stack senza limiti utilizza tutta la memoria resa disponibile dal kernel. Quando la macchina esaurisce la memoria, l'OOM killer seleziona il processo più grande, che potrebbe essere il web server anziché il sistema di tracking che ha causato il problema. Imposta un limite per ogni servizio: limiti di memoria in Docker Compose mostra la sintassi e il comportamento di un container quando raggiunge il proprio limite. Un container terminato dopo aver raggiunto il limite configurato produce un errore circoscritto. Un container terminato dal kernel può causare anche l'arresto di un servizio vicino.

Quale stack scegliere in base al VPS

• 1 GB o 2 GB con margine disponibile: GlitchTip in modalità all-in-one con Valkey disattivato oppure Bugsink su SQLite. Entrambe le soluzioni funzionano senza problemi con un numero limitato di applicazioni.
• 4 GB: Bugsink con PostgreSQL oppure GlitchTip con Valkey attivo e un servizio worker separato. A questa dimensione non è più necessario ottimizzare continuamente la configurazione: basta eseguire lo stack.
• 8 GB: sono ancora insufficienti per lo stack ufficiale di Sentry. Usate queste risorse per estendere il periodo di conservazione e aumentare lo spazio su disco, indipendentemente dall'opzione leggera scelta.
• 16 GB minimo, 32 GB consigliati: lo stack ufficiale self-hosted di Sentry, ma solo se vi serve una funzionalità di Sentry che i progetti più leggeri non implementano. Verificate prima la funzionalità specifica nella documentazione di ciascun progetto, perché i progetti compatibili coprono quelle più comuni.

In ogni caso, il sistema di tracciamento degli errori non può segnalare il proprio arresto. Configurate un controllo da un'altra macchina: Uptime Kuma che monitora da un altro host vi segnalerà quando il tracker è inattivo, cioè proprio nel momento in cui l'applicazione inizia a generare errori che nessuno sta registrando.

Quando una soluzione in hosting è la scelta più economica

Il self-hosting di un sistema di error tracking conviene quando le norme sulla localizzazione dei dati lo impongono oppure quando il volume degli eventi è abbastanza elevato da rendere oneroso il prezzo per evento. Negli altri casi, fate i calcoli in modo realistico. Il requisito minimo documentato da Sentry è un server con 16 GB di RAM, 4 core e storage veloce; un VPS di queste dimensioni non è economico. A questo va aggiunto il lavoro operativo: superare ogni blocco in ordine e creare uno snapshot prima di ogni migrazione, alcune volte all'anno.

GlitchTip e Bugsink cambiano completamente il calcolo, perché un server da 512 MB a 4 GB ha un costo contenuto e l'upgrade è un docker compose pull. Per questo, la maggior parte delle persone che pone questa domanda finisce per scegliere uno dei progetti compatibili invece dello stack ufficiale. Cercavano un sistema di error tracking, non una pipeline di dati distribuita da gestire continuamente.

Se state ancora valutando quali servizi installare effettivamente sul server, l'elenco più ampio di ciò che vale la pena gestire in self-hosting colloca l'error tracking accanto agli altri servizi che competono per la stessa RAM.

FAQ

Posso eseguire Sentry in self-hosting su un VPS da 2 GB?

No. La documentazione di Sentry self-hosted indica un minimo di 4 core CPU, 16 GB di RAM, 16 GB di swap aggiuntiva e 20 GB di spazio libero su disco. Lo stack esegue contemporaneamente Postgres, ClickHouse, Kafka, Redis e diversi processi worker. Su un server di piccole dimensioni, quindi, il kernel termina i container prima che l'installazione sia completata. Confermalo con dmesg -T | grep -i 'out of memory', che stampa una riga contenente il nome del processo terminato. Per un VPS da 2 GB usa GlitchTip, che documenta un requisito di 512 MB, oppure Bugsink, che viene eseguito come singolo container su SQLite.

Devo modificare il codice dell'applicazione per passare da Sentry a GlitchTip o Bugsink?

No. Entrambi accettano eventi dagli SDK open source di Sentry. Puoi quindi mantenere l'SDK già installato e modificare un solo valore: il DSN, cioè l'URL a cui l'SDK invia gli eventi. Se il DSN è ancora codificato direttamente nel codice, spostalo in una variabile d'ambiente. Impostalo sul nuovo host, quindi genera un'eccezione di test e monitora la ricezione dell'evento. Se non compare nulla, verifica che l'identificatore del progetto nel DSN corrisponda a un progetto esistente sul nuovo server e che il firewall consenta all'applicazione di raggiungere quell'host e quella porta.

Quanto spazio su disco richiede il monitoraggio degli errori in self-hosting?

Dipende dal volume degli eventi e dal periodo di conservazione, non dallo strumento. GlitchTip indica 30 GB per un'istanza che gestisce un milione di eventi al mese. Bugsink consente di impostare direttamente il limite con MAX_RETENTION_EVENT_COUNT e MAX_EVENT_AGE_DAYS. Puoi quindi scegliere il limite massimo e il requisito di spazio su disco dipenderà da quel valore. Configura la conservazione già dal primo giorno. Un sistema di monitoraggio senza una policy di conservazione continua a crescere finché df -h non raggiunge il 100%. A quel punto l'acquisizione degli eventi si interrompe e perdi proprio gli errori più importanti da analizzare.

Perché l'upgrade di Sentry self-hosted continua a non riuscire?

Perché l'upgrade ha saltato un passaggio obbligatorio. Sentry self-hosted definisce versioni specifiche che includono migrazioni del database obbligatorie. Ad agosto 2026 queste versioni sono 9.1.2, 21.5.0, 21.6.3, 23.6.2, 23.11.0, 24.8.0, 25.5.1, 26.5.0 e 26.7.0. Passare direttamente da una release precedente a quella più recente salta queste migrazioni. Di conseguenza, lo schema e il codice non sono più coerenti e l'upgrade si interrompe a metà. Esegui il checkout di ogni passaggio obbligatorio nell'ordine corretto e lancia ./install.sh a ciascun passaggio. Crea uno snapshot del server prima di iniziare e consulta l'elenco documentato delle release da evitare, che comprende 23.7.0, 25.9.0 e 25.12.0.