Introducción: El Despliegue No es el Final, es el Comienzo
Un pipeline CI/CD perfecto no sirve de nada si no sabemos qué sucede después del despliegue. El monitoreo y las alertas cierran el ciclo DevOps.
En este último artículo de la serie DevOps para Desarrolladores Frontend, exploraremos las tres categorías del monitoreo frontend: error tracking, performance monitoring y análisis del comportamiento del usuario.
Qué Aprenderás en Este Artículo
- Las tres categorías del monitoreo frontend
- Cómo integrar Sentry en una aplicación Angular
- Cómo implementar el Real User Monitoring (RUM)
- Cómo configurar el synthetic monitoring (uptime check)
- Cómo crear un Error Handler personalizado en Angular
- Cómo subir source maps para debugging en producción
- Estrategias de alertas eficaces
- Cómo configurar dashboards de monitoreo
1. Las Tres Categorías del Monitoreo Frontend
Categorías de Monitoreo
| Categoría | Qué Monitorea | Herramientas Típicas | Prioridad |
|---|---|---|---|
| Error Tracking | Excepciones JavaScript, errores HTTP, crashes | Sentry, Bugsnag, Rollbar | Crítica |
| Performance Monitoring | Core Web Vitals, tiempos de carga | web-vitals, SpeedCurve, Datadog RUM | Alta |
| User Behavior | Navegación, interacciones, funnels | Google Analytics, Mixpanel | Media |
2. Error Tracking con Sentry
Sentry es la plataforma de error tracking más utilizada en el mundo frontend.
Atención al Sample Rate
El tracesSampleRate determina cuántas transacciones se envían a Sentry.
Un valor de 1.0 es útil en desarrollo pero demasiado costoso en producción.
3. Error Handler Personalizado en Angular
4. Real User Monitoring (RUM)
El Real User Monitoring mide el rendimiento tal como lo perciben los usuarios reales.
La librería web-vitals de Google es el estándar para recopilar Core Web Vitals.
5. Synthetic Monitoring (Uptime Check)
Servicios de Synthetic Monitoring
- UptimeRobot: Plan gratuito con 50 monitores, chequeos cada 5 minutos
- Pingdom: Monitoreo avanzado con análisis RUM integrado
- Checkly: Browser checks con Playwright
- Better Uptime: Gestión de incidentes con páginas de estado públicas
6. Subida de Source Maps para Debugging
Nunca Servir Source Maps en Producción
Las source maps contienen el código fuente completo. Servirlas públicamente permitiría leer la lógica de negocio.
7. Estrategias de Alertas
Niveles de Alerta Recomendados
| Nivel | Trigger | Canal | Respuesta |
|---|---|---|---|
| Crítico (P0) | Sitio completamente caído, errores > 50% | SMS + Slack + PagerDuty | Inmediata (15 min) |
| Alto (P1) | Funcionalidad crítica rota, error rate > 10% | Slack + Email | En 1 hora |
| Medio (P2) | Rendimiento degradado, errores > 5% | Slack | En 4 horas |
| Bajo (P3) | Warnings, tendencia negativa | Informe semanal | Próximo sprint |
8. Dashboard de Monitoreo
9. Comparación de Herramientas de Monitoreo
Herramientas de Monitoreo a Comparar
| Herramienta | Tipo | Plan Gratuito | Punto Fuerte | Ideal Para |
|---|---|---|---|---|
| Sentry | Error tracking + Performance | 5K eventos/mes | Error grouping, source maps | Todos los proyectos |
| Datadog RUM | Full-stack monitoring | Limitado | Correlación frontend-backend | Enterprise |
| LogRocket | Session replay | 1K sesiones/mes | Video replay de sesiones | UX debugging |
10. Implementación Completa: Checklist
Checklist de Monitoreo para el Go-Live
- Sentry configurado y funcionando con error handler personalizado
- Source maps subidas a Sentry (y eliminadas del despliegue)
- Web Vitals tracking activo con envío a Google Analytics
- Uptime monitoring configurado (chequeos cada 5 minutos)
- Alertas configuradas para errores críticos (Slack, email)
- Dashboard creado con las métricas esenciales
- Compatibilidad SSR verificada (isPlatformBrowser)
- Sample rate optimizado para el volumen de tráfico
Conclusión
Con este artículo concluimos la serie DevOps para Desarrolladores Frontend. El monitoreo en producción cierra el loop del DevOps: los datos recogidos de los usuarios reales alimentan las decisiones de desarrollo.