Decisión: Plan Hardening post-Máster — Hito A (Alerting de PROD)

Contexto

El Máster de CreaRack (sesión 94) destapó 6 GAPS de severidad ALTA en la arquitectura de PROD. Hito A ataca el GAP #3: observabilidad de PROD endeble.

Hasta esta decisión, la única alarma real era UptimeRobot externo (GET /health). Una app que se degrada por dentro (lentitud, errores 5xx, memoria alta, errores de DB) pero sigue respondiendo “ok” a la salud no disparaba nada.

Hallazgo clave

Se descubrió que las 5 reglas de alerta en observability/victoriametrics/alerts.yml dependen de métricas (up, django_http_*, process_*) que solo existen vía scrape de /metrics. En PROD, la VM de VictoriaMetrics corre sin scrape configurado:

• Solo recibe push de MetricsWriter (ping/SNMP/HTTP de targets de clientes).
• Ninguna métrica de salud de la app Django (CPU, memoria, errores, latencia).
• Por tanto, las reglas de alerta no tienen qué evaluar.

Decisión

Activar el alerting interno de PROD mediante 3 piezas:

1. Scrape de /metrics en la VM de VictoriaMetrics (compose.prod.yml).
2. Servicio vmalert: evalúa las 5 reglas contra las métricas cada 30s.
3. Servicio Alertmanager: entrega avisos por email a logcrearack@esfericlabs.com vía Resend SMTP.

Esto no es “descomentar vmalert” — cada pieza es necesaria.

Implementación

• ✅ compose.prod.yml — añadido scrape (scrape.yml), servicios vmalert y alertmanager.
• ✅ compose.observability.yml — reescrito bloque vmalert (estaba comentado con paths erróneos), añadido alertmanager para parity local.
• ✅ observability/alertmanager/alertmanager.yml (nuevo) — router SMTP a Resend, remitente verificado en crearack.com, destinatario infra.
• ✅ .gitignore — excluida la clave API de Resend (smtp_password).
• ✅ observability/victoriametrics/alerts.yml — ajustado umbral HighMemoryUsage: 1GB → 3GB (PROD es 16GB, Daphne bajo carga legítimamente usa >1GB).

Validación smoke (local E2E)

1. vmalert carga las 5 reglas desde /etc/alerts/alerts.yml.
2. Con up==0, dispara CreaRackDown inmediatamente.
3. El estado de la alerta llega a Alertmanager (state=active).
4. Alertmanager intenta conectar al SMTP de Resend, responde 535 (auth fallida por key dummy → cableado OK).

Solo falta la key real de Resend para que el email salga en STAGE/PROD.

Despliegue (acción operacional)

Antes de activar en STAGE y PROD:

1. Crear el fichero files/smtp_password en cada Dokploy (STAGE y PROD) con la clave de Resend en una línea.
2. Montar en el contenedor alertmanager como volumen read-only en /etc/alertmanager/smtp_password.
3. Confirmar que:
   • El dominio crearack.com está verificado en Resend.
   • El remitente noreply@crearack.com es válido.
   • El destinatario logcrearack@esfericlabs.com existe.

Sin esto, Alertmanager no enviará.

Roadmap del Plan Hardening (visión global)

Regla: cada hito cierra ENTERO en su sesión (código + tests + smoke STAGE + doc). Nada a medias. Edu aplica deploys/migraciones.

Véase también

• [[feature—observability—alerting-prod-s95]]
• [[entity—observability—service—vmalert]]
• [[entity—observability—service—alertmanager]]
• [[concept—saas—observability]]
• [[runbook—observability—alerting-setup]]