Alternativas a Sentry para seguimiento de errores

Costes del seguimiento de errores autohospedado antes de almacenar un solo evento

El seguimiento de errores autohospedado depende de una cifra que determina toda la elección: el consumo base de RAM. La documentación oficial de Sentry para instalaciones autohospedadas requiere 4 núcleos de CPU, 16 GB de RAM, 16 GB de swap y 20 GB de espacio libre en disco antes de que su aplicación envíe un solo evento. GlitchTip documenta un requisito de 512 MB. Todas las opciones aquí aceptan eventos de los mismos SDK de Sentry, por lo que no es una decisión sobre cómo instrumentar su código. Es una decisión sobre qué tamaño de servidor está dispuesto a pagar y mantener activo.

Cifras de recursos publicadas, comparativa

Estas son las cifras que cada proyecto publica sobre sí mismo, a fecha de agosto de 2026. No son el mismo tipo de medición, así que lea la nota de cada fila antes de compararlas.

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

Los 16 GB de Sentry son un mínimo documentado, y la misma página recomienda 32 GB. Los 0.5 GB de GlitchTip son una recomendación, y el proyecto indica 256 MB como mínimo funcional, o 128 MB más swap con una configuración cuidadosa. Los 4 GB de Bugsink no son ninguna de las anteriores: es el equipo que el proveedor utilizó para su propia prueba de rendimiento. Una cifra publicada es un punto de partida, no una promesa sobre su volumen de eventos.

Sentry autohospedado: el producto completo y su coste operativo

La pila oficial es getsentry/self-hosted, un proyecto de Docker Compose que ejecuta los mismos componentes que Sentry utiliza en producción. Su propia documentación lo describe como "funcionalmente completo y empaquetado para despliegues de bajo volumen y pruebas de concepto". Esa frase es el resumen honesto. Obtiene todas las funciones y todas las piezas móviles que hacen que dichas funciones operen.

Instale desde una versión etiquetada (release) en lugar de desde 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

A continuación, inícielo:

docker compose up --wait

Sentry escucha en http://127.0.0.1:9000 de forma predeterminada. Se requiere Docker Engine 19.03.6 o posterior y Docker Compose 2.32.2 o posterior; una versión anterior de Compose fallará debido a la sintaxis del archivo, no por algo relacionado con Sentry.

Observe lo que realmente ha iniciado:

docker compose ps
free -h

docker compose ps enumera todos los servicios de la pila, y la lista es extensa: Postgres, ClickHouse, Kafka, Redis, Relay, Snuba, Symbolicator y varios procesos de tipo worker y cron. Cuéntelos una vez, porque esa cifra representa su carga de mantenimiento. Cada entrada es un proceso que puede bloquearse, llenar un disco o fallar durante una migración.

Si un servicio permanece en estado Restarting, revise la memoria antes que cualquier otra cosa:

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

Una línea como Out of memory: Killed process 3412 (java) significa que el OOM killer (out of memory killer) del kernel eliminó un contenedor porque el servidor se quedó sin RAM, por lo que ese servicio nunca alcanza un estado saludable y la pila nunca termina de arrancar. Este es el resultado habitual de ejecutar la pila completa por debajo de su mínimo documentado. La documentación también señala la velocidad del disco: un iowait superior al 10% significa que la máquina no puede seguir el ritmo de la canalización de ingesta. Consúltelo en la columna wa de top, o desde iostat -x 5 si tiene instalado sysstat.

Las actualizaciones son la parte que la gente subestima

Sentry autohospedado se lanza mensualmente bajo CalVer, un esquema de versiones basado en calendario, con una versión principal el día 15 de cada mes. No puede saltar de una versión antigua directamente a la última. El proyecto define versiones de parada obligatoria (hard stops), y debe realizar el checkout de cada una en orden para aplicar sus migraciones de base de datos. A fecha de agosto de 2026, las paradas obligatorias publicadas son 9.1.2, 21.5.0, 21.6.3, 23.6.2, 23.11.0, 24.8.0, 25.5.1, 26.5.0 y 26.7.0. La documentación también enumera versiones que deben omitirse debido a problemas de migración, incluyendo 23.7.0, 25.9.0, 25.12.0 y el rango de 26.3.0 a 26.4.0.

Una actualización consiste en un checkout seguido de una nueva ejecución del instalador:

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

Realice una instantánea (snapshot) del servidor antes de comenzar, ya que una migración sobre un conjunto de datos grande en ClickHouse puede durar horas y un fallo a mitad del proceso deja la base de datos entre dos esquemas. La causa principal de la mayoría de las actualizaciones fallidas de Sentry autohospedado es que el servidor permaneció en una versión durante un año, por lo que el salto atraviesa varias paradas obligatorias a la vez y una de las migraciones omitidas era la que resultaba crítica.

Una cosa más que debe saber antes de comprometerse. Sentry autohospedado se rige por la Functional Source License (FSL), que Sentry introdujo. Es software de código abierto "justo" (fair source) en lugar de código abierto aprobado por la OSI: puede ejecutarlo para usted mismo, pero no puede venderlo como un servicio de la competencia. Cada versión se convierte a Apache 2.0 dos años después de su lanzamiento.

GlitchTip: la respuesta de 512 MB

GlitchTip tiene licencia MIT y recibe eventos de los SDK de código abierto de Sentry, por lo que una aplicación instrumentada se migra cambiando un solo valor: el DSN (data source name, la URL a la que su SDK envía los eventos). Requiere PostgreSQL 14 o posterior. Valkey o Redis 7 o posterior es opcional, y hace que las instancias grandes sean más rápidas.

La instalación es Docker más un archivo compose:

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

Edite la sección de entorno antes de iniciar nada. Los valores que debe establecer son el secreto, el dominio y la ruta de correo:

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

El ejemplo ya conecta DATABASE_URL a su propio servicio postgres, así que deje esa línea como está a menos que apunte a una base de datos que ejecute en otro lugar. GLITCHTIP_DOMAIN debe incluir el esquema. Sin https:// al principio, los enlaces en los correos electrónicos de alerta se generan incorrectamente y dirigen a una URL que no responde.

Inícielo y observe el primer arranque:

docker compose up -d
docker compose logs -f web

Las etiquetas de imagen en el ejemplo a fecha de agosto de 2026 son postgres:18, valkey/valkey:9 y glitchtip/glitchtip:6. Manténgalas fijas. Un archivo compose que indique latest actualizará su motor de base de datos en el siguiente docker compose pull, y un salto de versión mayor de Postgres en una instancia en ejecución es la forma en que un rastreador de errores funcional deja de arrancar.

Para alcanzar el rango de 256 MB a 512 MB, los comentarios del propio archivo de ejemplo le indican qué desactivar, empezando por Valkey y las funciones opcionales de registro y tiempo de actividad. Ejecutar sin Valkey significa que GlitchTip utiliza su base de datos para el trabajo de caché y colas, lo cual es más lento pero sigue siendo correcto. El modo "todo en uno" ejecuta el trabajador dentro del proceso web, por lo que mantiene un contenedor de aplicación en lugar de dos.

Coloque un proxy delante. La documentación de GlitchTip solicita un proxy o balanceador de carga que almacene las peticiones en búfer y gestione Transfer-Encoding fragmentado, y ofrece nginx como ejemplo funcional. Sin almacenamiento en búfer, un cliente lento mantiene abierto un trabajador de la aplicación durante toda la carga, por lo que unos pocos remitentes lentos pueden ocupar todos sus trabajadores y los clientes sanos comienzan a agotar el tiempo de espera.

Las actualizaciones son la parte sencilla:

docker compose pull
docker compose stop
docker compose up -d

Las migraciones de base de datos se ejecutan automáticamente al iniciar. Realice una copia de seguridad primero de todos modos, porque una migración automática sigue siendo una migración.

Bugsink: un contenedor y una licencia que debe leer

Bugsink es el más ligero de los tres. Utiliza el protocolo del SDK de Sentry y se ejecuta sin colas de mensajes ni servicios externos más allá de una base de datos. SQLite es el valor predeterminado, aunque admite MySQL y PostgreSQL si el volumen de datos supera su capacidad.

Una instancia de prueba, para ver la interfaz antes de comprometerse:

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 sesión con la dirección y la contraseña que indicó en CREATE_SUPERUSER. Ese contenedor no conserva nada al detenerse. Para una instancia real, utilice el ejemplo de compose del proyecto, que combina bugsink/bugsink:2 con postgres:17-alpine y configura DATABASE_URL, BASE_URL y BEHIND_HTTPS_PROXY. Genere el secreto correctamente:

openssl rand -base64 50

BASE_URL debe coincidir con la URL que sus usuarios y SDK realmente utilizan, incluido el esquema. Si lo deja en http://localhost:8000 en un servidor al que accede mediante https://errors.example.com, cada enlace en un correo electrónico de notificación apuntará a un host que no resuelve para la persona que lo lee. Establezca BEHIND_HTTPS_PROXY en true cuando Nginx o Caddy terminen TLS (transport layer security) frente a él; de lo contrario, Bugsink generará URLs http:// detrás de su proxy https:// y los navegadores bloquearán el contenido mixto.

El proveedor publica sus propias cifras de rendimiento: 18 eventos por segundo de 50 KB cada uno, lo que equivale a 1,5 millones de eventos por día en un VPS de 2 vCPU y 4 GB. Considere esto como una referencia de la capacidad de la herramienta, no como una garantía para su carga de trabajo específica. Indica que el límite está muy por encima de lo que produce una aplicación pequeña.

Ahora la licencia, y esta es la parte que debe leer antes de integrarla en su pila tecnológica. Bugsink se distribuye bajo la licencia PolyForm Shield License 1.0.0. Es software con código disponible, no código abierto: puede ejecutarlo y modificarlo, pero no puede utilizarlo para crear algo que compita con Bugsink. Para un rastreador de errores interno, esta restricción nunca supone un problema. Si su empresa vende herramientas para desarrolladores, haga que alguien lea el texto de la licencia primero.

El seguimiento de errores y la observabilidad de LLM siguen siendo dos herramientas distintas

Si busca una herramienta que combine el seguimiento de errores y la observabilidad de modelos de lenguaje (LLM), encontrará productos que afirman hacer ambas cosas. Los formatos de datos son diferentes, razón por la cual la integración no termina de ocurrir. Un rastreador de errores recibe una excepción con un seguimiento de pila (stack trace), calcula una huella digital a partir de ella y agrupa miles de ocurrencias en un solo problema con un contador. Una herramienta de rastreo de LLM recibe un intervalo (span) que contiene un prompt, una respuesta, un recuento de tokens y una latencia, y debe conservar cada uno de ellos, ya que dos llamadas con entradas idénticas siguen siendo eventos separados que vale la pena analizar.

Por lo tanto, utilice ambas. Envíe las excepciones al rastreador de errores y envíe las llamadas al modelo a un sistema diseñado para ello: Langfuse autohospedado para el rastreo de agentes cubre ese aspecto, y observabilidad de IA autohospedada aborda la misma tarea desde un ángulo diferente. Su aplicación ya genera ambos tipos de fallos. Una llamada al modelo que devuelve información sin sentido pero con confianza no genera ninguna excepción, por lo que un rastreador de errores nunca se la mostrará.

El crecimiento del disco es el fallo que le encontrará más tarde

Todo rastreador de errores es una base de datos con una carga de escritura intensa y una entrada sin límites. Su aplicación decide cuánto escribe, y un nuevo error en una ruta de código crítica puede generar un millón de eventos durante la noche.

GlitchTip publica una cifra útil para la planificación: una instancia que gestione un millón de eventos al mes puede requerir 30 GB de disco. Esto cubre un mes de ingesta a esa tasa, y su ventana de retención decide cuántos meses almacenará simultáneamente.

Bugsink aborda esto desde el extremo opuesto. En lugar de una cuota fija, aplica un algoritmo de retención basado en el número y la antigüedad de los eventos, y expone los límites directamente: MAX_RETENTION_EVENT_COUNT para toda la instalación, MAX_RETENTION_PER_PROJECT_EVENT_COUNT por proyecto y MAX_EVENT_AGE_DAYS como un corte absoluto. Establecer un presupuesto de eventos para toda la instalación es la forma honesta de dimensionar un disco, porque ese presupuesto es el disco.

Monitoree los números reales en el servidor:

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

docker system df -v muestra los tamaños por volumen, para que pueda ver qué servicio es el que está creciendo. Un volumen que aumenta varios gigabytes por semana sin cambios en el tráfico suele significar que la retención nunca se configuró, por lo que no se elimina nada y el único límite es la partición.

La memoria es el mismo problema con otro nombre. Una pila sin límites tomará todo lo que el kernel le ofrezca, y cuando la máquina se queda sin recursos, el OOM killer elige el proceso más grande, que bien podría ser su servidor web en lugar del rastreador que causó el problema. Asigne a cada servicio un techo: límites de memoria en Docker Compose muestra la sintaxis y lo que hace un contenedor cuando alcanza su límite. Un contenedor eliminado por su propio límite es un fallo contenido. Un contenedor eliminado por el kernel arrastra a un vecino con él.

Qué stack elegir para cada VPS

• 1 GB, o 2 GB con margen: GlitchTip en modo todo en uno con Valkey desactivado, o Bugsink con SQLite. Ambos funcionan bien aquí para un pequeño número de aplicaciones.
• 4 GB: Bugsink con PostgreSQL, o GlitchTip con Valkey activado y un servicio de worker independiente. Este es el tamaño donde se deja de optimizar y simplemente se ejecuta.
• 8 GB: todavía insuficiente para el stack oficial de Sentry. Invierta este recurso en una ventana de retención más larga y un disco más grande para la opción ligera que haya elegido.
• 16 GB mínimo, 32 GB recomendado: el stack oficial de Sentry autohospedado, y solo cuando necesite una función de Sentry que los proyectos más ligeros no implementan. Compruebe primero la función específica en la documentación de cada proyecto, ya que los proyectos compatibles cubren las más comunes.

Independientemente de lo que ejecute, el rastreador de errores no puede informar sobre su propia caída. Configure una comprobación desde una máquina diferente: Uptime Kuma supervisando desde otro equipo le avisará si el rastreador no responde, que es precisamente el momento en el que su aplicación empieza a generar errores que nadie está registrando.

Cuándo un plan alojado es la opción más económica

Alojar uno mismo un rastreador de errores resulta rentable cuando las normas de residencia de datos lo exigen, o cuando el volumen de eventos es tan alto que el precio por evento resulta perjudicial. Fuera de esos casos, haga los cálculos con honestidad. El requisito mínimo documentado de Sentry es un servidor de 16 GB con 4 núcleos y disco rápido; un VPS de ese tamaño no es un VPS barato. A esto debe sumar el trabajo operativo: completar cada paso crítico en orden y realizar una instantánea antes de cada migración, varias veces al año.

GlitchTip y Bugsink cambian ese cálculo por completo, ya que un equipo de 512 MB a 4 GB es una opción económica y la actualización es un docker compose pull. Por eso, la mayoría de las personas que se plantean esta cuestión terminan utilizando uno de los proyectos compatibles en lugar de la pila oficial. Buscaban un rastreador de errores, no una canalización de datos distribuida que requiera supervisión constante.

Si todavía está decidiendo qué servicios alojar en su servidor, la lista más amplia de servicios que vale la pena alojar uno mismo sitúa el rastreo de errores junto a otros servicios que compiten por la misma memoria RAM.

FAQ

¿Puedo alojar Sentry por mi cuenta en un VPS de 2 GB?

No. La documentación de Sentry para instalaciones propias establece un mínimo de 4 núcleos de CPU, 16 GB de RAM más 16 GB de swap y 20 GB de espacio libre en disco. La pila ejecuta Postgres, ClickHouse, Kafka, Redis y varios procesos de trabajo simultáneamente, por lo que en una máquina pequeña el kernel finaliza los contenedores antes de que termine la instalación. Confírmelo con dmesg -T | grep -i 'out of memory', que imprime una línea indicando el proceso finalizado. Para un VPS de 2 GB, utilice GlitchTip, que documenta un requisito de 512 MB, o Bugsink, que se ejecuta como un único contenedor sobre SQLite.

¿Debo cambiar el código de mi aplicación para pasar de Sentry a GlitchTip o Bugsink?

No. Ambos aceptan eventos de los SDK de código abierto de Sentry, por lo que puede mantener el SDK que ya instaló y cambiar un solo valor: el DSN, la URL a la que el SDK envía los eventos. Muévalo a una variable de entorno si todavía está codificado en el código, apúntelo al nuevo host, genere una excepción de prueba y observe cómo llega. Si no aparece nada, compruebe que el identificador de proyecto en el DSN coincida con un proyecto existente en el nuevo servidor y que su firewall permita que la aplicación alcance ese host y puerto.

¿Cuánto disco necesita un sistema de seguimiento de errores autohospedado?

Eso depende del volumen de eventos y del periodo de retención, más que de la herramienta. GlitchTip publica un requisito de 30 GB para una instancia que gestione un millón de eventos al mes. Bugsink le permite establecer el presupuesto directamente con MAX_RETENTION_EVENT_COUNT y MAX_EVENT_AGE_DAYS, por lo que usted elige el límite y el requisito de disco se deriva de ello. Configure la retención el primer día. Un rastreador sin política de retención crece hasta que df -h marca 100%, momento en el que la ingesta se detiene y usted pierde los errores que más le interesaba ver.

¿Por qué falla constantemente la actualización de Sentry autohospedado?

Porque la actualización omitió un punto de parada obligatorio. Sentry autohospedado define versiones específicas que incluyen migraciones de base de datos por las que debe pasar obligatoriamente; a fecha de agosto de 2026, estas son 9.1.2, 21.5.0, 21.6.3, 23.6.2, 23.11.0, 24.8.0, 25.5.1, 26.5.0 y 26.7.0. Saltar directamente de una versión antigua a la más reciente omite estas migraciones, por lo que el esquema y el código no coinciden y la actualización se detiene a mitad del proceso. Realice la actualización pasando por cada punto de parada en orden y ejecute ./install.sh en cada uno de ellos, cree una instantánea del servidor antes de comenzar y lea la lista documentada de versiones a evitar, que incluye 23.7.0, 25.9.0 y 25.12.0.