Sentry autoalojado: seguimiento de errores sin suscripción de $30+

Para un funcionamiento estable de Sentry self-hosted en 10-20 proyectos con un volumen de hasta 50,000 eventos al mes, se requiere un VPS con un mínimo de 8 GB de RAM, 4 vCPU y 80 GB de disco NVMe. Esto permite prescindir totalmente de la suscripción a Sentry.io, que cuesta desde $29 al mes, y obtener un control total sobre los datos.

Sentry es el estándar de la industria para el monitoreo de errores y el rendimiento de aplicaciones (APM). Sin embargo, la política de precios de la versión SaaS suele ser una barrera para los equipos en crecimiento: el plan de pago inicial comienza en $29, y el plan de negocios desde $249 al mes. La transición a sentry on premise permite no solo ahorrar presupuesto, sino también cumplir con los requisitos de seguridad (GDPR), ya que los traces de errores y los datos de los usuarios no salen de su infraestructura.

Requisitos de hardware: ¿por qué sentry self hosted requiere 8GB de RAM?

Desplegar su propio sentry no es simplemente ejecutar un contenedor. La arquitectura moderna de Sentry consta de más de 25 microservicios, incluidos componentes pesados como Kafka, ClickHouse y Snuba. Intentar ejecutar el sistema en un servidor con 4 GB de RAM provocará inevitablemente que el OOM Killer se active en las primeras horas de funcionamiento.

Características mínimas y recomendadas del VPS

Para un funcionamiento fluido, un vps para error tracking debe tener una reserva de recursos. A continuación se presentan los requisitos basados en benchmarks reales con una carga de 10-15 eventos por segundo (EPS).

Característica	Mínimo (Dev/Small)	Recomendado (Production)	High Load (100+ EPS)
CPU (vCores)	4 Cores (2.5 GHz+)	8 Cores	16+ Cores
RAM	8 GB	16 GB	32 GB+
Tipo de disco	NVMe SSD	NVMe SSD (RAID 1)	NVMe SSD (Enterprise)
Espacio en disco	80 GB	200 GB	500 GB+
SO	Ubuntu 22.04 LTS	Debian 12 / Ubuntu 24.04	Debian 12

Es importante entender que ClickHouse y Kafka son muy sensibles a la velocidad del subsistema de disco. El uso de HDD convencionales o discos de red lentos provocará grandes retrasos (lag) en el procesamiento de eventos. Si planea almacenar logs durante mucho tiempo, consulte el tema sobre migrar de AWS Lightsail a servidores dedicados para obtener el máximo de IOPS por el mismo precio.

Arquitectura de sentry on premise: ClickHouse, Postgres y Kafka

El sentry on premise moderno se ha alejado del modelo simple de "Postgres + Redis". Ahora es un complejo pipeline de procesamiento de datos. Comprender su estructura es crítico para el troubleshooting y la configuración de las políticas de retención.

Rol de los componentes en el stack

• PostgreSQL: Almacena metadatos: usuarios, configuraciones de proyectos, claves de API, estructura de equipos. Los errores en sí no se guardan aquí.
• Redis: Se utiliza como broker para tareas de Celery y almacenamiento en caché de datos intermedios.
• Kafka: Actúa como buffer. Todos los eventos entrantes llegan primero a Kafka, lo que permite que Sentry soporte picos de carga sin pérdida de datos.
• ClickHouse: El almacenamiento principal de todos los eventos y tiempos. Gracias a él, Sentry genera gráficos instantáneamente a partir de millones de registros.
• Snuba: Servicio intermedio que traduce las consultas de Sentry en consultas SQL para ClickHouse.
• Symbolicator: Procesa stack traces nativos (C++, Rust, Android) y los asocia con símbolos de depuración.

Esta división permite escalar el vps de error tracking horizontalmente, pero en un solo servidor requiere una limitación estricta de recursos para cada contenedor Docker. Si está construyendo un sistema de monitoreo integral, también podría interesarle implementar analítica self-hosted sin Google para una independencia total del stack.

Instalación paso a paso mediante sentry docker compose

El método oficial de despliegue es el repositorio getsentry/self-hosted. Es un conjunto de scripts que automatizan la configuración del entorno sentry docker, la creación de redes y volúmenes.

Paso 1: Preparación del sistema

Actualice los paquetes e instale las dependencias necesarias. Necesitará Docker y Docker Compose (plugin V2).

sudo apt update && sudo apt upgrade -y
sudo apt install -y git curl build-essential

# Instalación de Docker
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh

Paso 2: Clonación y configuración

Utilizaremos la última versión estable. No se recomienda usar la rama master para producción.

git clone https://github.com/getsentry/self-hosted.git
cd self-hosted

# Verificación de requisitos del sistema
# El script install.sh verificará la RAM, pero es mejor asegurarse de antemano

Paso 3: Ejecución del instalador

El script ./install.sh realizará las migraciones de la base de datos, configurará los tópicos de Kafka y creará el usuario administrador. El proceso tarda de 10 a 20 minutos dependiendo de la velocidad del disco y del procesador.

./install.sh

Durante la instalación, se le pedirá que cree una cuenta de administrador. Asegúrese de guardar estos datos. Una vez finalizado, inicie los contenedores:

docker compose up -d

Después del inicio, su propio sentry estará disponible en la dirección http://IP_DE_SU_SERVIDOR:9000. Para entornos de producción, se recomienda encarecidamente configurar un Reverse Proxy (Nginx o Traefik) con soporte SSL. La seguridad del acceso al panel de control es tan importante como la protección de contraseñas en el equipo mediante Vaultwarden self-hosted.

Migración de SaaS (Sentry.io) a su propio VPS

Muchos equipos comienzan con el plan gratuito o económico de Sentry.io, pero con el tiempo alcanzan los límites. Es posible transferir datos de la nube a sentry self hosted, pero con ciertos matices. No existe una importación directa de la base de datos con "un solo botón" debido a las diferencias en las versiones de la API y la arquitectura de ClickHouse en la nube.

Exportación mediante API y CLI

El método principal de migración es utilizar el comando integrado export. Sin embargo, solo transfiere la estructura (proyectos, equipos, claves), pero no los eventos históricos de errores.

1. Cree un Auth Token en el panel de Sentry.io con permisos org:read.
2. Use el contenedor Docker de Sentry para realizar la exportación:

   docker compose run --rm web export /home/sentry-export.json

3. Para la versión en la nube, tendrá que usar la API para descargar las configuraciones de los proyectos y recrearlas localmente mediante Terraform o scripts personalizados en Python.

Cambio de DSN: una etapa crítica

Después de levantar sentry on premise, los DSN (Data Source Name) cambiarán para todos los proyectos. Tendrá que actualizar las configuraciones en todos los microservicios y aplicaciones frontend. Si tiene muchos proyectos en Next.js, el proceso se puede automatizar siguiendo los principios de migración de Next.js a su propio VPS.

Consejo: No elimine inmediatamente su cuenta en Sentry.io. Déjela como fallback durante 2 semanas hasta que todos los clientes actualicen los DSN almacenados en caché en sus navegadores o aplicaciones.

Configuración de Retention: cómo no llenar el disco con logs

Por defecto, sentry docker almacena los eventos durante 90 días. Con un gran flujo de errores (por ejemplo, un bug de frontend en bucle en miles de usuarios), ClickHouse puede "comerse" rápidamente todo el espacio libre en el NVMe.

Cambio del periodo de retención de datos

Los ajustes de retención se definen en el archivo .env o directamente en la configuración de Snuba. Para cambiar el periodo de retención a 30 días (óptimo para la mayoría), edite las variables:

# En el archivo .env en el directorio self-hosted
SENTRY_EVENT_RETENTION_DAYS=30

Después del cambio, es necesario reiniciar los contenedores y esperar a que los workers limpien las particiones antiguas en ClickHouse.

Limpieza de datos no utilizados

A veces, los volúmenes de Docker comienzan a ocupar demasiado espacio debido a los logs de los propios contenedores. Use el comando para limpiar:

docker system prune -a --volumes --filter "label!=com.docker.compose.project=self-hosted"

También es útil configurar la rotación de logs de Docker en /etc/docker/daemon.json para que un solo contenedor no pueda crear un archivo de log de 50 GB.

Optimización del rendimiento y ajuste de ClickHouse

Si su vps de error tracking comienza a ralentizarse, lo primero que debe hacer es verificar el consumo de memoria de ClickHouse. Por defecto, intenta ocupar hasta el 50% de la RAM disponible. En un servidor de 8-16 GB, esto puede causar conflictos con Kafka.

En el archivo clickhouse/config.xml puede limitar el uso de recursos:

<max_server_memory_usage>4000000000</max_server_memory_usage>
<max_thread_pool_size>8</max_thread_pool_size>

Para los desarrolladores que utilizan activamente IA para corregir los bugs encontrados en Sentry, una excelente adición será la combinación de Continue.dev + Ollama, desplegada en el mismo servidor o en uno cercano. Esto permite analizar los traces de errores con una red neuronal local sin enviar código al exterior.

Monitoreo de colas de Kafka

Si los errores aparecen en la interfaz con un retraso de varios minutos, significa que Kafka no está procesando el flujo a tiempo. Puede verificar esto con el comando:

docker compose run --rm kafka kafka-consumer-groups --bootstrap-server kafka:9092 --describe --group snuba-consumers

Si el campo LAG aumenta, necesita incrementar el número de núcleos de CPU o bien optimizar la cantidad de eventos enviados desde el lado del cliente (sampling).

Conclusiones

Sentry self-hosted es una solución potente que se amortiza desde el primer mes cuando se tienen más de 3 proyectos activos, requiriendo solo un VPS de calidad con 8-16 GB de RAM. Para un funcionamiento estable, es crítico usar discos NVMe y configurar una política de retención de 14-30 días para evitar el desbordamiento del almacenamiento de ClickHouse. Se recomienda desplegar Sentry en un SO Ubuntu 22.04 limpio a través del instalador oficial, configurando previamente un Reverse Proxy para proteger los datos.