Alternativas ao Sentry self-hosted: RAM e custo real

Qual é o custo do rastreamento de erros self-hosted antes de armazenar um único evento

O rastreamento de erros self-hosted tem um número que determina toda a escolha: o requisito mínimo de RAM. A documentação oficial do Sentry para instalações self-hosted exige 4 núcleos de CPU, 16 GB de RAM, mais 16 GB de swap, e 20 GB de espaço livre em disco antes de a aplicação enviar um único evento. O GlitchTip documenta 512 MB. Todas as opções apresentadas aceitam eventos dos mesmos SDKs do Sentry. Portanto, esta não é uma decisão sobre como instrumentar o código. É uma decisão sobre o tamanho do servidor que está disposto a pagar e manter em execução.

Números de recursos publicados, lado a lado

Estes são os números que cada projeto publica sobre si próprio, em outubro de 2026. Não representam o mesmo tipo de medição, por isso leia a nota de cada linha antes de os comparar.

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

Os 16 GB do Sentry são um mínimo documentado, e a mesma página recomenda 32 GB. Os 0.5 GB do GlitchTip são uma recomendação, e o projeto indica 256 MB como mínimo funcional, ou 128 MB mais swap com uma configuração cuidadosa. Os 4 GB do Bugsink não correspondem a nenhuma dessas categorias: são os recursos do servidor que o fornecedor utilizou no seu próprio benchmark de throughput. Um valor publicado é um ponto de partida, não uma garantia sobre o volume de eventos.

Sentry self-hosted: o produto completo e a fatura completa

A stack oficial é getsentry/self-hosted, um projeto Docker Compose que executa os mesmos componentes que o Sentry executa em produção. A documentação do próprio projeto descreve-a como "completa em funcionalidades e empacotada para implementações de baixo volume e provas de conceito". Essa frase é o resumo honesto. Obtém todas as funcionalidades e todos os componentes necessários para as executar.

Instale a partir de uma release identificada, e não a partir de 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

Depois, inicie-a:

docker compose up --wait

O Sentry escuta em http://127.0.0.1:9000 por predefinição. São necessários Docker Engine 19.03.6 ou posterior e Docker Compose 2.32.2 ou posterior, e o instalador verifica ambos: uma versão antiga do Compose interrompe ./install.sh com uma linha que começa por FAIL: Expected minimum e indica a versão encontrada, e o script termina com um erro.

Veja o que iniciou efetivamente:

docker compose ps
free -h

docker compose ps apresenta todos os serviços da stack, e a lista é longa: Postgres, ClickHouse, Kafka, Redis, Relay, Snuba, Symbolicator e vários processos de trabalho e cron. Conte-os uma vez, porque esse número corresponde à sua carga de manutenção. Cada entrada é um processo que pode falhar, encher um disco ou falhar durante uma migração.

Se um serviço permanecer no estado Restarting, verifique a memória antes de qualquer outra coisa:

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

Uma linha como Out of memory: Killed process 3412 (java) significa que o OOM killer do kernel (out of memory killer) terminou um contentor porque o servidor ficou sem RAM. Por isso, o serviço nunca fica saudável e a stack nunca termina de arrancar. Este é o resultado habitual de executar a stack completa abaixo do mínimo documentado. A documentação também chama a atenção para a velocidade do disco: iowait acima de 10% provavelmente significa que a máquina não consegue acompanhar o pipeline de ingestão. Leia esse valor na coluna wa de top ou em iostat -x 5, se tiver sysstat instalado.

As atualizações são a parte que as pessoas subestimam

O Sentry self-hosted lança releases mensais segundo o CalVer, um esquema de versões baseado no calendário, com uma release principal no dia 15 de cada mês. Não pode passar diretamente de uma versão antiga para a mais recente. O projeto define versões de paragem obrigatória, e é necessário fazer checkout de cada uma pela ordem correta para aplicar as respetivas migrações da base de dados. Em outubro de 2026, as versões de paragem obrigatória publicadas são 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. A documentação também lista releases a evitar devido a problemas de migração, incluindo 23.7.0, 25.9.0, 25.12.0 e o intervalo de 26.3.0 a 26.4.0.

Uma atualização consiste em fazer checkout e voltar a executar o instalador:

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

Crie um snapshot do servidor antes de começar, porque uma migração sobre um conjunto de dados ClickHouse grande pode demorar horas, e uma falha a meio deixa a base de dados entre dois schemas. A causa direta da maioria das atualizações falhadas do Sentry self-hosted é esta: o servidor permaneceu um ano na mesma versão, pelo que a atualização atravessa várias versões de paragem obrigatória de uma só vez e uma das migrações a evitar era precisamente a necessária.

Há mais um aspeto a conhecer antes de assumir este compromisso. O Sentry self-hosted está sujeito à Functional Source License (FSL), introduzida pelo próprio Sentry. É source-available, mas não é open source aprovado pela OSI: pode executá-lo para uso próprio, mas não pode vendê-lo como um serviço concorrente. Cada release é convertida para Apache 2.0 dois anos depois de ser lançada.

GlitchTip: a resposta para 512 MB

O GlitchTip é licenciado sob a MIT e recebe eventos dos SDKs de código aberto do Sentry. Assim, uma aplicação instrumentada pode ser migrada alterando um único valor: o DSN (data source name, o URL para o qual o SDK envia os eventos). Requer PostgreSQL 14 ou posterior. Valkey ou Redis 7 ou posterior é opcional e torna as instâncias maiores mais rápidas.

A instalação consiste no Docker e num único ficheiro compose:

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

Edite a secção de ambiente antes de iniciar qualquer componente. Os valores que deve definir são o segredo, o domínio e o caminho de correio:

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

O exemplo já liga DATABASE_URL ao seu próprio serviço postgres. Deixe essa linha inalterada, exceto se estiver a utilizar uma base de dados gerida noutro local. GLITCHTIP_DOMAIN deve incluir o esquema. Sem https:// no início, os links nas mensagens de alerta são construídos incorretamente e apontam para um URL que não responde.

Inicie o serviço e monitorize o primeiro arranque:

docker compose up -d
docker compose logs -f web

As tags das imagens no exemplo, em outubro de 2026, são postgres:18, valkey/valkey:9 e glitchtip/glitchtip:6. Mantenha-as fixas. Um ficheiro compose que contenha latest irá obter um novo motor de base de dados no próximo docker compose pull e mudará para ele na próxima vez que docker compose up -d recriar o contentor. Uma atualização da versão principal do Postgres sobre um diretório de dados existente é uma causa comum para um sistema de monitorização de erros deixar de iniciar.

Para chegar ao intervalo de 256 MB a 512 MB, os próprios comentários do ficheiro de exemplo indicam o que deve desativar, começando pelo Valkey e pelas funcionalidades opcionais de logs e monitorização de disponibilidade. Sem Valkey, o GlitchTip utiliza a base de dados para as operações de cache e fila. É mais lento, mas continua correto. O modo all in one executa o worker dentro do processo web. Assim, mantém um único contentor da aplicação em vez de dois.

Coloque um proxy à frente do serviço. A documentação do GlitchTip recomenda um proxy ou balanceador de carga que faça buffer dos pedidos e trate Transfer-Encoding em modo chunked. O exemplo apresentado utiliza nginx. Sem buffering, um cliente lento mantém um worker da aplicação ocupado durante todo o upload. Assim, alguns emissores lentos podem ocupar todos os workers disponíveis e os clientes em condições normais começam a atingir o tempo limite.

As atualizações são simples:

docker compose pull
docker compose stop
docker compose up -d

As migrações da base de dados são executadas automaticamente no arranque. Ainda assim, faça primeiro um dump, porque uma migração automática continua a ser uma migração.

Bugsink: um único contentor e uma licença que deve ler

Bugsink é a opção mais leve das três. Fala o protocolo do Sentry SDK e funciona sem fila de mensagens e sem serviços externos além de uma base de dados. SQLite é a opção predefinida. MySQL e PostgreSQL são suportados quando esta opção deixar de ser suficiente.

Para testar a interface antes de se comprometer, pode iniciar uma instância temporária:

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

Abra http://localhost:8000/ e inicie sessão com o endereço e a palavra-passe que passou em CREATE_SUPERUSER. Este contentor não mantém dados quando para. Para uma instância real, use o exemplo de compose do projeto. Este combina bugsink/bugsink:2 com postgres:17-alpine e define DATABASE_URL, BASE_URL e BEHIND_HTTPS_PROXY. Gere o segredo corretamente:

openssl rand -base64 50

BASE_URL tem de corresponder ao URL que os seus utilizadores e SDKs usam efetivamente, incluindo o esquema. Se o deixar como http://localhost:8000 num sistema acedido através de https://errors.example.com, todas as ligações nas mensagens de notificação apontarão para um host que não é resolvido pela pessoa que as lê. Defina BEHIND_HTTPS_PROXY como true quando nginx ou Caddy terminarem o TLS (segurança da camada de transporte) à frente do Bugsink. Caso contrário, o Bugsink cria URLs http:// atrás do seu proxy https://, e os browsers bloqueiam o conteúdo misto.

O fornecedor publica os seus próprios valores de capacidade: 18 eventos por segundo com 50 KB cada, o que corresponde a 1.5 milhões de eventos por dia, num VPS com 2 vCPU e 4 GB. Considere estes valores uma indicação da dimensão da ferramenta, não uma garantia para a sua carga de trabalho. Ainda assim, mostram que o limite máximo fica muito acima do que uma aplicação pequena produz.

Agora, a licença. Esta é a parte que deve ler antes de adicionar o Bugsink à sua stack. O Bugsink é distribuído ao abrigo da PolyForm Shield License 1.0.0. O código está disponível para consulta, mas não é open source: pode executá-lo e modificá-lo, mas não pode usá-lo para criar algo que concorra com o Bugsink. Para um sistema interno de acompanhamento de erros, esta restrição nunca se aplica. Se a sua empresa comercializa ferramentas para programadores, peça primeiro a alguém para ler o texto da licença.

O rastreio de erros e a observabilidade de LLM continuam a ser duas ferramentas

Procure uma ferramenta que faça simultaneamente rastreio de erros e observabilidade de modelos de linguagem de grande escala (LLM) e encontrará produtos que afirmam fazer ambas as coisas. As estruturas dos dados são diferentes, por isso a integração continua a não acontecer. Um sistema de rastreio de erros recebe uma exceção com um stack trace, calcula uma impressão digital a partir dela e agrupa milhares de ocorrências num único problema com um contador. Uma ferramenta de rastreio de LLM recebe um span com um prompt, uma resposta, uma contagem de tokens e uma latência. Tem de manter cada ocorrência, porque duas chamadas com entradas idênticas continuam a ser eventos distintos que vale a pena analisar.

Por isso, execute ambas. Envie as exceções para o sistema de rastreio de erros e envie as chamadas aos modelos para uma ferramenta concebida para esse fim: Langfuse self-hosted para rastreio de agentes cobre esse lado, enquanto as abordagens de observabilidade de IA self-hosted executam a mesma tarefa a partir de outra perspetiva. A sua aplicação já produz os dois tipos de falha. Uma chamada ao modelo que devolve disparates apresentados com confiança não gera qualquer exceção, por isso um sistema de rastreio de erros nunca lha mostrará.

O crescimento do disco é a falha que aparece mais tarde

Todo sistema de acompanhamento de erros é uma base de dados com muitas operações de escrita e uma entrada sem limite superior. A sua aplicação decide quanto escreve, e um novo bug num caminho de código muito utilizado pode produzir um milhão de eventos durante a noite.

O GlitchTip publica um valor útil para o planeamento: uma instância que processa um milhão de eventos por mês pode precisar de 30 GB de disco. Esse valor cobre um mês de ingestão a essa taxa, e o período de retenção determina quantos meses ficam armazenados em simultâneo.

O Bugsink aborda o problema pelo lado oposto. Em vez de aplicar uma quota fixa, usa um algoritmo de retenção baseado na quantidade e na idade dos eventos. Também expõe diretamente os limites: MAX_RETENTION_EVENT_COUNT para toda a instalação, MAX_RETENTION_PER_PROJECT_EVENT_COUNT por projeto e MAX_EVENT_AGE_DAYS como corte absoluto. Definir um orçamento de eventos para toda a instalação é a forma correta de dimensionar o disco, porque esse orçamento corresponde ao disco.

Monitorize os valores reais no servidor:

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

docker system df -v mostra os tamanhos por volume, para identificar qual serviço está a crescer. Um volume que ganha vários gigabytes por semana sem alterações no tráfego normalmente indica que o período de retenção continua a acumular dados ou que retém mais dados do que a partição consegue suportar à taxa atual de eventos. Não deixar a retenção sem alterações não significa que nada expire: o .env fornecido pelo Sentry define SENTRY_EVENT_RETENTION_DAYS=90, e o valor predefinido do GLITCHTIP_RETENTION_DAYS do GlitchTip é 90. Reduza o período de retenção para o ajustar ao disco, em vez de esperar que a partição fique cheia.

A memória apresenta o mesmo problema com outra forma. Uma stack sem limites usa toda a memória disponibilizada pelo kernel. Quando a máquina fica sem memória, o OOM killer termina o processo com a maior pontuação de badness. O kernel calcula essa pontuação principalmente com base na quantidade de memória usada por cada processo e ajusta-a pelo seu oom_score_adj. Esse processo pode ser o seu servidor Web, e não o tracker que causou o problema. Defina um limite para cada serviço: limites de memória no Docker Compose mostra a sintaxe e o comportamento de um contentor quando atinge o limite. Um contentor terminado pelo próprio limite representa uma falha contida. Um contentor terminado pelo kernel pode derrubar um serviço vizinho.

Qual stack é adequado para cada VPS

• 1 GB, ou 2 GB com margem: GlitchTip no modo all in one com Valkey desativado, ou Bugsink com SQLite. Ambos funcionam confortavelmente neste tamanho para algumas aplicações.
• 4 GB: Bugsink com PostgreSQL, ou GlitchTip com Valkey ativado e um serviço worker separado. A partir deste tamanho, deixa de ser necessário ajustar tudo e pode simplesmente executar o serviço.
• 8 GB: continua abaixo dos requisitos do stack oficial do Sentry. Use a memória adicional para aumentar o período de retenção e o disco para a opção leve que escolheu.
• 16 GB no mínimo, 32 GB recomendado: o stack oficial self-hosted do Sentry, e apenas quando precisar de uma funcionalidade do Sentry que os projetos mais leves não implementam. Confirme primeiro a funcionalidade específica na documentação de cada projeto, porque os projetos compatíveis cobrem as funcionalidades comuns.

Independentemente do que executar, o sistema de rastreamento de erros não consegue comunicar a própria falha. Configure uma verificação a partir de outra máquina: Uptime Kuma a monitorizar a partir de outro servidor informará que o rastreador está indisponível. Esse é precisamente o momento em que a sua aplicação começa a gerar erros que ninguém está a registar.

Quando um plano alojado é a opção mais barata

A alojamento próprio de um sistema de monitorização de erros compensa quando as regras de residência dos dados o exigem ou quando o volume de eventos é suficientemente elevado para que o preço por evento pese no orçamento. Fora desses casos, faça as contas de forma rigorosa. O mínimo documentado pelo Sentry é um servidor com 16 GB, 4 cores e armazenamento rápido, e um VPS desse tamanho não é barato. Depois, acrescente o trabalho operacional: ultrapassar cada bloqueio na ordem correta e criar um snapshot antes de cada migração, algumas vezes por ano.

O GlitchTip e o Bugsink alteram completamente essas contas, porque 512 MB a 4 GB correspondem a um servidor económico e a atualização consiste num docker compose pull seguido de um restart. É por isso que a maioria das pessoas que fazem esta pergunta acaba num dos projetos compatíveis, e não na stack oficial. Queriam monitorização de erros, não um pipeline de dados distribuído que exigisse manutenção constante.

Se ainda está a decidir o que deve realmente ficar no servidor, a lista mais abrangente do que vale a pena alojar por conta própria coloca a monitorização de erros ao lado dos outros serviços que competem pela mesma RAM.

FAQ

Posso hospedar o Sentry num VPS com 2 GB?

Não. A documentação do Sentry self-hosted indica um mínimo de 4 CPU cores, 16 GB de RAM, mais 16 GB de swap, e 20 GB de espaço livre em disco. A stack executa Postgres, ClickHouse, Kafka, Redis e vários processos de worker ao mesmo tempo. Num servidor pequeno, o kernel termina os containers antes de a instalação acabar. Confirme com dmesg -T | grep -i 'out of memory', que imprime uma linha com o nome do processo terminado. Para um VPS com 2 GB, use o GlitchTip, que documenta 512 MB, ou o Bugsink, que executa como um único container sobre SQLite.

Tenho de alterar o código da aplicação para mudar do Sentry para o GlitchTip ou Bugsink?

Não. Ambos aceitam eventos dos SDKs open source do Sentry. Pode manter o SDK já instalado e alterar apenas um valor: o DSN, que é o URL para onde o SDK envia os eventos. Passe esse valor para uma variável de ambiente se ainda estiver hardcoded. Aponte-o para o novo host, provoque uma exceção de teste e monitorize a sua chegada. Se nada aparecer, confirme que o identificador do projeto no DSN corresponde a um projeto existente no novo servidor e que a firewall permite à aplicação aceder a esse host e porta.

Quanto espaço em disco requer o rastreamento de erros self-hosted?

Isso depende mais do volume de eventos e do período de retenção do que da ferramenta. O GlitchTip publica 30 GB para uma instância que processa um milhão de eventos por mês. O Bugsink permite definir diretamente o orçamento com MAX_RETENTION_EVENT_COUNT e MAX_EVENT_AGE_DAYS. Assim, escolhe o limite e o requisito de disco resulta desse valor. Verifique a retenção no primeiro dia: o Sentry e o GlitchTip são distribuídos com um período de 90 dias, que pode ocupar mais espaço do que o disco disponível à sua taxa de eventos. Um tracker que retém mais dados do que o disco comporta cresce até df -h indicar 100%. Nesse ponto, a ingestão para e perde os erros que mais precisava de consultar.

Porque é que a atualização do Sentry self-hosted continua a falhar?

Porque a atualização ignorou uma versão de passagem obrigatória. O Sentry self-hosted define versões específicas que incluem migrações da base de dados pelas quais tem de passar. Em outubro de 2026, essas versões são 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. Passar diretamente de uma release antiga para a mais recente ignora essas migrações. O schema e o código ficam incompatíveis e a atualização para a meio. Faça checkout de cada versão de passagem pela ordem correta e execute ./install.sh em cada uma. Crie um snapshot do servidor antes de começar e consulte a lista documentada de releases a evitar, que inclui 23.7.0, 25.9.0 e 25.12.0.