Sin monitorización, tu app está en producción a ciegas

Tu equipo ha trabajado semanas en una funcionalidad nueva. La habéis testeado, ha pasado el pipeline de CI/CD y está en producción desde esta mañana. Todo parece ir bien. Hasta que un usuario escribe al soporte diciendo que la app va lenta. Sin monitorización, ese es tu sistema de alertas: los propios usuarios.

La monitorización de tu app en producción no es un lujo que puedes posponer para cuando el proyecto sea más grande. Es lo que separa a un equipo que reacciona de un equipo que se entera. Sin monitorización, tu estrategia de detección de problemas es "esperar a que alguien se queje". Y cuando alguien se queja, el problema lleva horas o días ahí.

No necesitas una sala de control con pantallas gigantes. Necesitas las señales correctas, los umbrales adecuados y un sistema que te avise cuando algo se sale de lo normal.

Qué significa monitorizar (sin el ruido enterprise)

Monitorizar una aplicación en producción es observar su comportamiento de forma continua y automatizada. El objetivo: detectar problemas antes de que los noten tus usuarios. No es Big Data, no es observabilidad nivel NASA y no requiere un equipo de SRE dedicado.

En la práctica, monitorizar se reduce a tres preguntas que tu sistema debería poder responder en cualquier momento. ¿La app está funcionando? ¿Está funcionando bien? ¿Algo ha cambiado respecto a ayer?

Si puedes responder a esas tres preguntas sin conectarte a un servidor ni abrir los logs a mano, tu monitorización es funcional. Si no puedes, tienes un punto ciego que tarde o temprano te va a costar usuarios, dinero o ambos.

Las cuatro métricas que importan de verdad

Hay decenas de métricas que puedes monitorizar. Uso de CPU, memoria, disco, red, conexiones a base de datos, queries por segundo, tamaño de cola, latencia de DNS. La lista es interminable y ahí está el problema: si vigilas todo, no vigilas nada.

Para un equipo que gestiona un proyecto en producción con recursos limitados, hay cuatro métricas que cubren el 90% de lo que necesitas saber.

Disponibilidad (uptime). ¿Tu app responde? No si responde rápido o bien, simplemente si responde. Un check cada minuto que hace una petición HTTP a tu endpoint principal y verifica que devuelve un 200. Si deja de responder, te enteras en 60 segundos, no en 60 minutos. Para un backend Django desplegado en AWS o en un VPS, esto es tan sencillo como un healthcheck endpoint que verifica que la app y la base de datos están vivos.

Tiempo de respuesta (latencia). ¿Tu app responde en un tiempo razonable? El tiempo medio es útil pero engañoso. Si el 95% de las peticiones tardan 200ms y el 5% tarda 8 segundos, el promedio parece aceptable. Pero ese 5% de usuarios tiene una experiencia terrible. Monitoriza el percentil 95 (p95): el tiempo que tarda el 95% de las peticiones. Si el p95 se dispara, algo va mal aunque el promedio no se mueva.

Tasa de errores. ¿Qué porcentaje de peticiones devuelve un error? Un 0.1% de errores 500 en un día normal puede ser aceptable. Un 2% es una señal clara de que algo se ha roto. Lo importante no es el número absoluto sino el cambio: si ayer tenías un 0.1% y hoy tienes un 1.5%, algo ha pasado entre medias. Probablemente el último despliegue.

Saturación. ¿Tus recursos están cerca del límite? CPU al 90%, memoria al 95%, disco lleno, conexiones a base de datos agotadas. Estas métricas no te dicen que algo ha fallado, te dicen que algo va a fallar. Son las únicas que te dan margen para actuar antes del incidente, no después.

Estas cuatro métricas no son invención nuestra. Google las formalizó como las Four Golden Signals en su libro de SRE. Se han convertido en el estándar de facto para monitorización de servicios.

Logs, métricas y trazas: qué es cada cosa

Si estás empezando con la monitorización, estos tres conceptos se mezclan fácilmente. Pero son herramientas diferentes para problemas diferentes.

Logs son registros de eventos individuales. "El usuario X intentó hacer login y falló", "La petición a /api/orders tardó 3.2 segundos", "Error al conectar con la pasarela de pago". Son el nivel más detallado y el más útil para diagnosticar un problema concreto. Django genera logs por defecto, pero configurarlos bien (formato estructurado, niveles adecuados, rotación de archivos) marca la diferencia entre logs útiles y ruido.

Métricas son valores numéricos agregados en el tiempo. "Peticiones por segundo", "uso de memoria", "errores por minuto". No te dicen qué pasó exactamente, pero te dicen cuándo algo cambió. Son el sistema de alarma: las métricas te despiertan a las 3 de la mañana, los logs te dicen por qué.

Trazas siguen una petición de principio a fin a través de tu sistema. El usuario hace clic en "comprar". La petición pasa por el servidor web, llega a Django, consulta la base de datos y llama a la pasarela de pago. Una traza te muestra dónde se atascó el proceso. Para un monolito Django, las trazas son menos críticas que para una arquitectura de microservicios. Pero si tu app habla con servicios externos (pagos, email, APIs de terceros), saber dónde se pierde el tiempo es valioso.

Para empezar, los logs bien configurados y cuatro métricas básicas son suficientes. Las trazas pueden venir después, cuando la complejidad de tu sistema lo justifique.

Herramientas sin overkill

Hay herramientas de monitorización para todos los bolsillos y niveles de complejidad. El error más común es elegir la herramienta enterprise cuando tu proyecto necesita algo pragmático.

Para uptime y alertas básicas: UptimeRobot o Better Stack (antes Uptime) tienen planes gratuitos que monitorizan endpoints HTTP y te avisan por email, Slack o SMS si tu app deja de responder. Se configuran en cinco minutos y cubren la necesidad más básica: saber que tu app está viva.

Para métricas de servidor y aplicación: Si tu infraestructura está en AWS, CloudWatch viene incluido y te da métricas de CPU, memoria y disco sin instalar nada. Si usas un VPS (Hetzner o similar), Prometheus con Grafana es la combinación open source de referencia. Requiere más configuración inicial, pero es gratuita y escala bien. Para algo intermedio, Datadog y New Relic tienen planes gratuitos limitados que son suficientes para proyectos pequeños.

Para logs: En un proyecto Django, la configuración de logging de Python ya te da una base sólida. Manda los logs a un servicio centralizado (Papertrail, Logtail o el propio CloudWatch Logs) para poder buscar y filtrar sin conectarte al servidor. Revisar logs por SSH funciona para un servidor. Cuando tienes dos o tres, necesitas un sitio central.

Para errores de aplicación: Sentry es el estándar para captura de excepciones. Se integra con Django y Flutter en minutos y te muestra cada error con su stack trace, el usuario afectado y el contexto de la petición. El plan gratuito cubre de sobra un proyecto en fase de crecimiento. Si un error salta en producción, lo ves en Sentry antes de que el usuario escriba al soporte.

La regla: empieza con lo mínimo que te dé visibilidad. Un healthcheck, Sentry para errores y métricas básicas del servidor. Puedes iterar después.

Alertas: el arte de no saturarse

La monitorización sin alertas es un dashboard que nadie mira. Pero las alertas mal configuradas son peores que no tener alertas: generan fatiga, el equipo empieza a ignorarlas y cuando llega una alerta real, nadie reacciona.

Alerta solo lo que requiere acción. Si una alerta salta y la respuesta del equipo es "ya lo vemos mañana", esa alerta no debería existir. Cada alerta debe tener una acción clara asociada: reiniciar un servicio, investigar un despliegue reciente, escalar recursos.

Distingue entre urgente e informativo. La app no responde es urgente: Slack, SMS, lo que haga falta para que alguien lo vea en minutos. El uso de CPU ha subido un 15% respecto a ayer es informativo: un email o un mensaje en un canal de monitorización que alguien revisará en horario laboral. Mezclar ambos niveles en el mismo canal es la forma más rápida de que el equipo ignore todo.

Usa umbrales con contexto. Un tiempo de respuesta de 500ms puede ser normal para una petición que genera un informe PDF y un desastre para un endpoint que devuelve un JSON de 10 campos. Los umbrales deben reflejar lo que es normal para cada servicio, no un número arbitrario aplicado a todo.

Menos es más. Un equipo pequeño debería tener entre cinco y diez alertas activas, no cincuenta. Cada alerta nueva que añades diluye la atención de las existentes. Según el informe DORA, los equipos de alto rendimiento tienen menos alertas pero más relevantes. Responden más rápido precisamente porque no están saturados de ruido.

Qué monitorizar según el tipo de proyecto

No todos los proyectos necesitan la misma monitorización. Lo que vigilas depende de lo que puede fallar y del impacto que tiene ese fallo.

E-commerce o app con pagos. El flujo de compra es sagrado. Monitoriza la tasa de éxito de transacciones, la latencia de la pasarela de pago y cualquier error en el checkout. Un 1% de fallos en el pago puede significar miles de euros perdidos al mes. Aquí un test end-to-end que simula una compra cada cinco minutos vale su peso en oro.

App con autenticación y datos de usuario. Monitoriza el flujo de login (tasa de éxito, latencia), los errores de permisos y cualquier anomalía en el acceso a datos sensibles. Un pico de errores 403 puede ser un bug o puede ser algo peor.

API o backend que sirve a un frontend o app móvil. Monitoriza la latencia por endpoint, la tasa de errores por versión de cliente y la compatibilidad con versiones anteriores. Si despliegas una nueva versión del backend y la app Flutter en producción empieza a fallar, necesitas saberlo antes de que lo sepa el usuario.

CMS o plataforma de contenido. Monitoriza los tiempos de carga de las páginas públicas, el rendimiento del panel de administración y el estado de las tareas programadas (importaciones, envíos de email, generación de contenido). Un CMS con Wagtail puede funcionar perfectamente para los editores y tener las páginas públicas lentas por una query mal optimizada que solo aparece con volumen real de contenido.

El error de monitorizar después

La mayoría de equipos montan la monitorización después del primer incidente grave. Un viernes por la noche la app se cae, nadie se entera hasta el lunes, los usuarios se quejan y alguien dice: "hay que poner monitorización". Es un patrón tan común como evitable.

La monitorización debería llegar justo después del primer despliegue automatizado. Si ya tienes un pipeline de CI/CD que despliega a producción, el siguiente paso natural es saber si lo que has desplegado funciona. No la semana que viene. No cuando el proyecto sea más grande. Ahora.

Montar una monitorización básica lleva menos de medio día: un healthcheck con UptimeRobot, Sentry para errores y las métricas de servidor que tu proveedor ya te ofrece (CloudWatch en AWS, las métricas nativas de Hetzner o las de tu panel de VPS). Con eso, la próxima vez que algo falle, te enterarás tú primero.

Y esa es la diferencia entre un equipo profesional y uno que funciona a base de suerte: no que nada falle, sino que cuando falla, lo sabes antes que nadie.