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.

Valores de recursos publicados, lado a lado

Estes são os números que cada projeto publica sobre si próprio, em agosto de 2026. Não são 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 operacional, ou 128 MB mais swap com uma configuração cuidadosa. Os 4 GB do Bugsink não correspondem a nenhum desses casos: são os recursos da máquina que o fornecedor utilizou no seu próprio benchmark de throughput. Um valor publicado é um ponto de partida, não uma garantia para o seu 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 usa 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 por tag, 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

Por predefinição, o Sentry escuta em http://127.0.0.1:9000. É necessário usar Docker Engine 19.03.6 ou posterior e Docker Compose 2.32.2 ou posterior. Uma versão mais antiga do Compose falha na sintaxe do ficheiro, e não em algo específico do Sentry.

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 workers 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 sistema ficou sem RAM. Por isso, esse serviço nunca fica saudável e a stack nunca termina o arranque. Este é o resultado habitual de executar a stack completa com o mínimo documentado. A documentação também assinala a velocidade do disco: iowait acima de 10% significa que a máquina não consegue acompanhar o pipeline de ingestão. Consulte 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çado mensalmente 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 saltar diretamente de uma versão antiga para a versão mais recente. O projeto define versões de paragem obrigatória, e deve fazer checkout de cada uma pela ordem correta para aplicar as respetivas migrações da base de dados. Em agosto 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 que devem ser ignoradas devido a problemas nas migrações, 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 executar novamente 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 dataset grande do ClickHouse pode demorar horas. Uma falha a meio do processo deixa a base de dados entre dois esquemas. A causa habitual da maioria das atualizações falhadas do Sentry self-hosted é simples: o sistema permaneceu durante 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 ignoradas era necessária.

Há mais um aspeto a conhecer antes de se comprometer. O Sentry self-hosted está sujeito à Functional Source License (FSL), introduzida pelo próprio Sentry. É source-available, mas não é open source aprovada 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 ao abrigo da MIT e recebe eventos dos SDKs open source do Sentry. Assim, uma aplicação instrumentada pode ser transferida 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 requer o Docker e um ú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 serviço. Os valores que tem de 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 apontar para uma base de dados que execute noutro local. GLITCHTIP_DOMAIN tem de incluir o esquema. Sem https:// no início, os links nas mensagens de alerta são gerados 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 agosto de 2026, são postgres:18, valkey/valkey:9 e glitchtip/glitchtip:6. Mantenha-as fixas. Um ficheiro compose que indique latest atualizará o motor da base de dados no próximo docker compose pull. Uma atualização da versão principal do Postgres numa instância em execução pode impedir o arranque de um rastreador de erros que estava funcional.

Para atingir a faixa 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 a cache e o processamento das filas. Esta configuração é mais lenta, mas continua correta. 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 buffering dos pedidos e trate Transfer-Encoding em blocos. O exemplo apresentado usa nginx. Sem buffering, um cliente lento mantém um worker da aplicação ocupado durante todo o upload. Assim, alguns remetentes lentos podem ocupar todos os workers disponíveis e os clientes saudáveis começam a atingir o tempo limite.

As atualizações são a parte simples:

docker compose pull
docker compose stop
docker compose up -d

As migrações da base de dados são executadas automaticamente no arranque. Faça um dump antes, ainda assim, 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 entrada sem limite definido. A sua aplicação determina quanto escreve, e um novo bug num caminho de código muito utilizado pode gerar 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 nessa taxa. A janela 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 no número 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 disponível.

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 poder identificar qual é o serviço que está a crescer. Um volume que ganha vários gigabytes por semana sem qualquer alteração no tráfego normalmente indica que a retenção nunca foi configurada. Nesse caso, nada é eliminado e a única limitação é a partição.

A memória apresenta o mesmo problema com outra configuração. Uma stack sem limites consome toda a memória disponibilizada pelo kernel. Quando a máquina fica sem memória, o OOM killer escolhe o processo maior. Esse processo pode ser o servidor Web, e não o tracker que causou o problema. Defina um limite máximo para cada serviço: limites de memória no Docker Compose mostra a sintaxe e o comportamento de um contentor quando atinge o seu limite. Um contentor terminado pelo seu próprio limite causa uma falha contida. Um contentor terminado pelo kernel pode causar a falha de outro serviço.

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 auto-hospedagem de um sistema de monitorização de erros compensa quando as regras de residência dos dados a 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 com honestidade. O requisito mínimo documentado do Sentry é um servidor com 16 GB, 4 cores e armazenamento rápido, e uma VPS desse tamanho não é uma VPS barata. Depois, há o trabalho operacional: ultrapassar cada bloqueio rígido pela 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 uma máquina barata e a atualização é uma docker compose pull. É por isso que a maioria das pessoas que faz esta pergunta acaba num dos projetos compatíveis, em vez de usar a stack oficial. Queriam monitorização de erros, não um pipeline de dados distribuído para manter.

Se ainda está a decidir o que deve ficar no servidor, a lista mais abrangente do que vale a pena alojar coloca a monitorização de erros junto 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 núcleos de CPU, 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 worker em simultâneo. Num servidor pequeno, o kernel termina os containers antes de a instalação acabar. Confirme isso 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 o Bugsink?

Não. Ambos aceitam eventos dos SDKs open source do Sentry. Por isso, mantenha o SDK que já instalou e altere apenas um valor: o DSN, que é o URL para o qual o SDK envia os eventos. Passe esse valor para uma variável de ambiente se ainda estiver definido diretamente no código. 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 que a aplicação alcance esse host e essa porta.

De quanto espaço em disco precisa o acompanhamento 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 o limite diretamente com MAX_RETENTION_EVENT_COUNT e MAX_EVENT_AGE_DAYS. Assim, escolhe o limite e o requisito de espaço em disco resulta desse valor. Configure a retenção no primeiro dia. Um sistema de acompanhamento sem política de retenção cresce até df -h indicar 100%. Nesse momento, a ingestão para e perde os erros que mais precisava de consultar.

Por que motivo a atualização do Sentry self-hosted continua a falhar?

Porque a atualização ignorou uma etapa 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 agosto 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 esquema e o código deixam de corresponder e a atualização para a meio. Faça checkout de cada etapa obrigatória 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.