Monitorear una aplicación en producción significa observar en tiempo real si tu sistema funciona bien o está a punto de fallar.
Cuando nadie avisa, el problema ya es grave
Imagina que trabajas en el equipo de tecnología de Liverpool. Son las 11 de la noche del Buen Fin. Tu aplicación de pagos empieza a fallar. Los clientes no pueden completar sus compras. Nadie en tu equipo se da cuenta porque están dormidos. Al día siguiente, Liverpool perdió millones de pesos en ventas y tú tienes que explicar qué pasó.
Eso es exactamente lo que el monitoreo evita. Con las herramientas correctas, tu sistema te avisa antes de que el problema llegue a los usuarios. Tú actúas en minutos, no al día siguiente.
El sistema MALA: Métricas, Alertas, Logs y Acciones
En DevOps existe un marco de trabajo que puedes aplicar desde hoy. Se llama el sistema MALA: Métricas, Alertas, Logs y Acciones. Cada pieza tiene un rol específico.
- Métricas: números que describen el estado de tu app (uso de CPU, tiempo de respuesta, errores por minuto).
- Alertas: reglas que disparan una notificación cuando una métrica supera un límite peligroso.
- Logs: registros de texto que explican qué hizo tu aplicación y qué salió mal.
- Acciones: pasos que tú o tu sistema ejecutan automáticamente para corregir el problema.
Cuando los cuatro elementos trabajan juntos, tienes visibilidad total de tu aplicación.
Las métricas que siempre debes medir
No todas las métricas son igual de útiles. Enfócate en las cuatro métricas doradas que usa la industria:
1. Latencia: ¿Cuánto tarda tu app en responder? Si tu API de pagos tarda más de 2 segundos, los usuarios abandonan la compra.
2. Tráfico: ¿Cuántas solicitudes por segundo recibe tu sistema? Si Bimbo lanza una promoción y el tráfico sube 10 veces, necesitas saberlo al instante.
3. Errores: ¿Qué porcentaje de solicitudes falla? Un 5% de errores en una app con 10,000 usuarios son 500 personas con problemas ahora mismo.
4. Saturación: ¿Qué tan lleno está tu sistema? Si tu servidor usa el 95% de su CPU, el colapso es inminente.
Estas cuatro métricas te dan una fotografía completa de la salud de tu aplicación en cualquier momento.
Cómo usar Prometheus y Grafana en la práctica
Las herramientas más populares en el ecosistema DevOps para monitoreo son Prometheus y Grafana. Prometheus recolecta métricas. Grafana las visualiza en tableros.
Prometheus funciona con un modelo de "scraping": cada ciertos segundos visita tu aplicación y le pregunta cómo está. Tu app responde con datos como este:
# Ejemplo de métricas expuestas por tu app
http_requests_total{method="GET", status="200"} 4523
http_requests_total{method="GET", status="500"} 38
http_response_duration_seconds{quantile="0.95"} 0.87
Prometheus guarda esos números. Grafana los toma y los convierte en gráficas que tu equipo puede ver desde cualquier navegador.
Para conectar tu aplicación a Prometheus, expones un endpoint /metrics. Si usas Python con Flask, se ve así:
from flask import Flask
from prometheus_client import Counter, Histogram, generate_latest
app = Flask(__name__)
peticiones = Counter('http_peticiones_total', 'Total de peticiones HTTP', ['metodo', 'estado'])
duracion = Histogram('http_duracion_segundos', 'Duracion de respuesta en segundos')
@app.route('/metrics')
def metrics():
return generate_latest()
@app.route('/producto/<int:id>')
@duracion.time()
def obtener_producto(id):
peticiones.labels(metodo='GET', estado='200').inc()
return {"producto": id, "precio": "$1,299"}
Con este código, Prometheus puede leer tus métricas cada 15 segundos y guardar el historial completo.
Cómo configurar alertas que realmente funcionen
Tener métricas sin alertas es como tener un detector de incendios sin alarma. Ves el fuego, pero nadie te avisó a tiempo.
En Prometheus, las alertas se definen con reglas en un archivo YAML:
groups:
- name: alertas_produccion
rules:
- alert: AltaTasaDeErrores
expr: rate(http_peticiones_total{estado="500"}[5m]) > 0.05
for: 2m
labels:
severidad: critica
annotations:
resumen: "Más del 5% de errores en los últimos 5 minutos"
descripcion: "Revisar logs del servicio de pagos de inmediato"
- alert: LatenciaAlta
expr: http_duracion_segundos{quantile="0.95"} > 2.0
for: 3m
labels:
severidad: advertencia
annotations:
resumen: "El 95% de las respuestas tardan más de 2 segundos"
Esta regla revisa cada 5 minutos si más del 5% de las solicitudes terminan en error. Si eso ocurre durante 2 minutos seguidos, manda una alerta. El for: 2m es clave: evita falsas alarmas por picos de un segundo.
Las alertas se pueden enviar a Slack, correo electrónico, PagerDuty o WhatsApp con un componente llamado Alertmanager. Tu equipo puede recibir el aviso directo en el canal de Slack del proyecto.
Los logs son tu caja negra
Cuando una alerta dispara, lo primero que necesitas es saber por qué falló tu app. Ahí entran los logs.
Un log bien escrito tiene tres partes: timestamp, nivel de severidad y mensaje claro.
import logging
logging.basicConfig(
level=logging.INFO,
format='%(asctime)s [%(levelname)s] %(message)s'
)
logger = logging.getLogger(__name__)
def procesar_pago(usuario_id, monto):
logger.info(f"Iniciando pago para usuario {usuario_id}, monto: ${monto:,}")
try:
# lógica de pago aquí
logger.info(f"Pago exitoso para usuario {usuario_id}")
except Exception as e:
logger.error(f"Error en pago del usuario {usuario_id}: {e}")
Con herramientas como Loki (de Grafana) o Elasticsearch, puedes centralizar todos los logs de todos tus servicios en un solo lugar. Así no tienes que conectarte a 10 servidores diferentes para encontrar el error.
Errores comunes al monitorear en producción
Muchos equipos cometen estos errores cuando implementan monitoreo por primera vez:
Error 1: Alertar por todo. Si tienes 200 alertas activas, nadie les hace caso. Prioriza solo lo que afecta al usuario final. Empieza con las cuatro métricas doradas y agrega más cuando las domines.
Error 2: Logs sin contexto. Un log que dice "Error: null" no sirve de nada a las 2 de la mañana. Incluye siempre el ID del usuario, el monto, el endpoint y el mensaje de excepción completo.
Error 3: No probar las alertas. Una alerta que nunca se ha disparado puede estar rota. Cada semana simula un fallo en un ambiente de pruebas para confirmar que la alerta llega correctamente al equipo.
Error 4: Monitorear solo el servidor. Tu app puede estar caída aunque el servidor esté verde. Mide también el tiempo de respuesta desde el punto de vista del usuario con pruebas sintéticas: scripts que simulan una compra real cada 5 minutos.
Un ejemplo real: monitoreo en una tienda en línea
Supón que eres parte del equipo DevOps de FEMSA Digital. Tienen una app de pedidos que procesa $2,500,000 diarios en transacciones.
Su tablero de Grafana muestra en tiempo real:
- Peticiones por segundo: 340
- Tasa de error actual: 0.3%
- Latencia P95: 420ms
- CPU del servidor: 61%
Todo está verde. Pero a las 6:15 PM, la latencia sube a 3.2 segundos. La alerta de LatenciaAlta dispara en Slack antes de que cualquier cliente se queje. El equipo revisa los logs y encuentra que una consulta a la base de datos sin índice está bloqueando todo. Lo corrigen en 8 minutos. El daño: cero usuarios con errores, porque la alerta llegó primero.
Eso es el valor real del monitoreo: no eliminar los problemas, sino resolverlos antes de que duelan.
El monitoreo es una conversación continua con tu sistema
No configuras el monitoreo una vez y lo olvidas. Cada semana revisas si tus alertas siguen siendo relevantes. Cada sprint agregas métricas nuevas cuando despliegas funcionalidades nuevas. El monitoreo crece junto con tu aplicación.
El mejor momento para configurar el monitoreo es antes del primer despliegue a producción; el segundo mejor momento es hoy.