Feature: Alerting de PROD — avisos cuando algo va mal por dentro

Lo que cambia

PROD podrá avisar por email al equipo infra cuando la app se degrade por dentro. Hasta ahora la única alarma era UptimeRobot, que solo mira: “¿responde la web?” desde fuera.

Una app lenta o devolviendo errores 500 pero que sigue contestando a /health no disparaba nada. Ahora sí:

• Caída (up == 0) — PROD no responde.
• Lentitud (p95_latency > 2s) — 95% de requests tardan más de 2s.
• Tasa alta de errores 5xx — más de 50 en 1m.
• Errores de DB — intentos fallidos contra Postgres.
• Memoria sostenida alta (>3GB, 15m) — posible leak.

Cada alarma llega a logcrearack@esfericlabs.com con:

• Nombre de la alerta (CreaRackDown, HighLatency, etc.).
• Descripción legible del problema.
• Timestamp.
• Link a VictoriaMetrics (si está disponible).

Por qué

Primer hito del Plan Hardening post-Máster (detectado en la sesión de auditoría).

El Máster destapó que la observabilidad de PROD era un punto ciego:

1. Las 5 reglas de alerta existían, pero ningún componente las ejecutaba.
2. Encima dependían de métricas que en PROD ni se recogían (solo push de targets clientes, no salud app).
3. La única vigilancia real era externa (UptimeRobot sobre /health).

Esto genera un riesgo grave: degradaciones internas sin notificación, impactando a clientes sin que el equipo lo sepa hasta que lo reportan.

Cómo se activa

3 piezas nuevas en la stack:

1. Scrape de /metrics en PROD

La VM de VictoriaMetrics ahora pull de http://web:8000/metrics cada 15s. Sin esto, no hay métricas de salud (CPU, memoria, latencia, errores Django).

2. vmalert (evaluador)

Ejecuta las 5 reglas en observability/victoriametrics/alerts.yml cada 30s contra las métricas. Cuando una condición se cumple (ej. up == 0), la dispara.

3. Alertmanager (notificador)

Recibe las alertas de vmalert. Las agrupa (para no spam si hay múltiples), aplica un delay de 30s (para evitar falsos positivos), y envía email a logcrearack@esfericlabs.com vía Resend SMTP (smtp.resend.com:587, STARTTLS, auth PLAIN).

• Remitente: CreaRack Pro <noreply@crearack.com> (dominio verificado en Resend).
• Asunto: [CreaRack PROD] ACTIVE · CreaRackDown (ejemplo).
• Reintentos: si una alerta sigue activa, reenvía cada 4h (para no abrumar).

Impacto al usuario

Ninguno en el producto — es vigilancia interna. El usuario no ve/hace nada diferente.

Impacto operacional (para el equipo):

• Tiempo de detección de degradaciones → de “reportado por cliente” a “segundos”.
• Debugging más rápido con alerta que con dump post-facto.

Despliegue en STAGE/PROD

Pendiente: montar la API key de Resend en Dokploy.

1. Crear fichero files/smtp_password en cada Dokploy (STAGE y PROD) con la clave en una línea.
2. Montar como volumen en alertmanager (/etc/alertmanager/smtp_password).
3. Confirmar dominio verificado + destinatario válido.

Una vez hecho, el stack arranca y cualquier alerta sale por email al instante.

Configuración local (dev)

En compose.observability.yml, vmalert y alertmanager también están activos. Para testear:

# Simular caída: detener el web
docker compose down web

# Pocos segundos después, vmalert dispara CreaRackDown
# Alertmanager lo recibe (visible en http://localhost:9093)
# No enviará email (no hay key Resend), pero logs muestran la conexión SMTP

Reglas de alerta

Definidas en observability/victoriametrics/alerts.yml:

Cambio en este PR: umbral HighMemoryUsage 1GB → 3GB (PROD es 16GB, Daphne bajo carga legitimamente usa >1GB).

Véase también

• [[decision—20260529—plan-hardening-post-master-hito-a]]
• [[entity—observability—service—vmalert]]
• [[entity—observability—service—alertmanager]]
• [[concept—saas—observability]]
• [[runbook—observability—alerting-setup]]