Monitoreo: Parte 6 — Errores de la aplicación: Sentry y GlitchTip

Las métricas del servidor y los logs no lo muestran todo. Si el error ocurrió en el navegador del usuario o en una rama rara del código, el servidor puede no registrar nada y el usuario simplemente cerrar la página. Para esos casos existen sistemas de seguimiento de errores de aplicaciones: reciben la excepción directamente desde el código junto con el stack trace, la versión del release y el contexto de la petición, y agrupan errores iguales en una sola tarea.

La más conocida es Sentry. Su alternativa abierta, compatible con las mismas librerías de cliente, es GlitchTip.

Qué aporta un sistema de seguimiento de errores

• Stack trace con la ubicación exacta en el código, incluso para JavaScript minificado, si se han subido los source maps.
• Agrupación. Mil excepciones idénticas — una tarea con contador, no mil correos.
• Contexto: navegador, sistema operativo, versión del release, URL de la página, secuencia de eventos antes del fallo (breadcrumbs).
• Vinculación con releases: se ve en qué versión apareció el error y si se arregló en la siguiente.
• Alertas sobre errores nuevos y sobre incrementos bruscos de errores antiguos.

No sustituye a métricas y logs: Prometheus o Zabbix responderán si el servidor está vivo y si hay recursos suficientes, y Sentry — qué se ha roto exactamente en el código. Panorama de métricas y alertas — en la primera parte del ciclo.

Sentry: nube o servidor propio

Sentry en la nube (sentry.io). A septiembre de 2026 el plan gratuito Developer está pensado para un solo usuario e incluye 5 000 errores y 5 millones de spans de tracing al mes. El plan Team para equipos cuesta desde $26 al mes con facturación anual. No es posible pagar un servicio extranjero con tarjeta rusa: Visa y Mastercard no funcionan fuera de Rusia desde marzo de 2022.

Sentry en su propio servidor. El código fuente de Sentry se distribuye bajo la licencia FSL-1.1-Apache-2.0 (Functional Source License). Se puede usar y modificar para tareas internas, está prohibido construir un servicio competidor sobre él; dos años después del lanzamiento, cada versión pasa automáticamente a Apache 2.0. No es una licencia abierta en el sentido estricto, pero para uso interno las restricciones son prácticamente nulas.

Una distribución lista para servidor propio está en el repositorio getsentry/self-hosted. Requisitos según la documentación: 4 núcleos, 16 GB de RAM más 16 GB de swap (se recomiendan 32 GB), desde 20 GB en disco, Docker y Docker Compose en versiones recientes. Internamente usan varias bases de datos y un broker de mensajes, por lo que la velocidad del disco es importante. Para un proyecto pequeño es pesado.

GlitchTip: alternativa abierta y ligera

GlitchTip es un sistema de seguimiento de errores de código abierto bajo licencia MIT. Acepta eventos de las librerías cliente de Sentry, por lo que en el código sólo cambia la dirección DSN. GlitchTip tiene una versión en la nube con plan gratuito hasta 1 000 eventos al mes, pero su principal ventaja es la facilidad de desplegarlo en su propio servidor: varios contenedores (aplicación web, tareas en background, PostgreSQL, Redis) en lugar de decenas.

Las capacidades de GlitchTip son menores: no tiene parte de las herramientas de análisis de rendimiento y reproducción de sesiones que ofrece Sentry. Para la tarea de «enterarse de los errores y ver el stack trace» normalmente es suficiente.

Configuración del SDK

El procedimiento es el mismo para Sentry y GlitchTip: cree un proyecto, copie el DSN —la dirección a la que la librería envía los eventos— e inicialice el SDK lo antes posible al arrancar la aplicación.

JavaScript en el navegador. El tracing entra en el paquete principal, ya no es necesario el paquete separado @sentry/tracing:

npm install @sentry/browser --save

import * as Sentry from "@sentry/browser";

Sentry.init({
  dsn: "https://<key>@o<orgId>.ingest.sentry.io/<projectId>",
  release: "my-app@1.4.2",
  integrations: [Sentry.browserTracingIntegration()],
  tracesSampleRate: 0.1,
});

Python (Django, Flask, FastAPI se integran automáticamente si están instalados):

pip install sentry-sdk

import sentry_sdk

sentry_sdk.init(
    dsn="https://<key>@o<orgId>.ingest.sentry.io/<projectId>",
    release="my-app@1.4.2",
    traces_sample_rate=0.1,
)

El valor tracesSampleRate: 1.0 de los ejemplos de la documentación significa registrar cada petición. Para carga de producción suele bastar 5–10 %, de lo contrario la cuota de tracing se agota en pocos días.

Comprobar la conexión es sencillo: lance en el código una excepción de prueba y verifique que el evento aparece en la interfaz.

Source maps y releases

El código frontend en producción está minificado, y sin source maps el stack trace apunta a la línea 1 del archivo main.8f3a.js. La forma más sencilla de configurar la subida de source maps es el asistente:

npx @sentry/wizard@latest -i sourcemaps

Añadirá a la build la subida de mapas mediante Sentry CLI. La relación entre mapas y archivos se establece mediante identificadores de depuración (Debug IDs), por lo que no es necesario modificar los archivos compilados a mano. El número de release en release debe coincidir con el que conoce la build — así en la interfaz se ve en qué versión apareció el error. Es recomendable subir los mapas y crear el release en el pipeline de CI, no desde una máquina de desarrollo.

Alertas

Alertar por cada error rápidamente se convierte en ruido. Un conjunto práctico de reglas:

• sobre un error nuevo, que no había ocurrido antes;
• sobre un incremento brusco en la frecuencia de un error conocido;
• sobre una regresión — un error marcado como corregido que vuelve a aparecer.

Canales: correo, mensajeros, webhooks. Los principios son los mismos que para alertas de infraestructura: notificar sólo sobre lo que requiere acción.

Datos personales en los eventos

Un evento de error puede llevar consigo datos personales fácilmente: un email en los parámetros de la petición, la IP, el contenido de un formulario. Para una empresa rusa esto es una cuestión no sólo de seguridad, sino de ley: desde el 1 de julio de 2025 el registro primario de datos personales de ciudadanos de Rusia debe realizarse en bases situadas en el territorio de Rusia (más detalles — en el artículo sobre Protección de datos personales: qué exige la Ley 152-FZ a las pequeñas empresas). Enviar eventos con tales datos a una nube extranjera entra en conflicto con este requisito.

Qué hacer:

• no habilitar el envío de datos personales por defecto (send_default_pii en Python y la configuración análoga en JavaScript dejarla desactivada);
• limpiar campos sensibles antes de enviar con el handler beforeSend / before_send;
• activar la limpieza de datos en el lado del servidor en la configuración del proyecto;
• si los datos en los eventos son inevitables — alojar GlitchTip o Sentry en su servidor en Rusia.

Errores típicos

• Registrar el 100 % de las trazas en producción — la cuota se agota y el beneficio de datos extra es nulo.
• No subir source maps — el stack trace del frontend es ilegible.
• No enviar el número de release — no queda claro si el error está corregido.
• DSN con permisos de escritura en un repositorio público de código del servidor. El DSN del frontend es público por definición, pero en el código del servidor es mejor pasarlo mediante variables de entorno.
• Notificar por cada evento — en una semana dejan de leerlas.
• Datos personales enviados a una nube extranjera junto con el stack trace.