Sistema de alarmas de PROD (vmalert + Alertmanager)

Runbook del alerting de producción: arquitectura, reglas, secret, proxies NetBird y operación. Hito A del Plan Hardening (s95, 29-05-2026). PRs #49/#50/#51.

Arquitectura

web /metrics → (scrape) → VictoriaMetrics → (query) → vmalert → (fire) → Alertmanager → (SMTP) → Resend → logcrearack@esfericlabs.com

• VictoriaMetrics hace scrape de web:8000/metrics (django-prometheus) cada 60s vía --promscrape.config (observability/victoriametrics/scrape.yml). Antes solo recibía push (ping/snmp/http de targets de clientes); sin scrape no había métricas de salud de la app.
• vmalert evalúa observability/victoriametrics/alerts.yml cada 30s y dispara a Alertmanager.
• Alertmanager entrega por email vía Resend SMTP (smtp.resend.com:587, STARTTLS, remitente CreaRack Pro <noreply@crearack.com>). Config observability/alertmanager/alertmanager.yml.

Reglas activas (5)

Por qué se excluye el 501 (v1.81.2, 22-08-2026): CreaRack responde 501 a propósito a las sondas WebDAV (OPTIONS/PROPFIND) de los reproductores SpinetiX contra /publish/<token>/ — fuerza el fallback spx-listing.xml (signage/views_publish.publish_root). Es protocolo correcto, no un error, pero contaba como 5xx en la métrica y un player sondeando en horas de poco tráfico disparaba la alarma. Los 5xx reales (500/502/503/504) siguen contando igual.

Piezas y footguns

• Scrape + ALLOWED_HOSTS: el scrape entra con Host: web:8000. config/settings/production.py incluye web en ALLOWED_HOSTS; sin él Django responde 400 → up=0 → falsa alarma CreaRackDown.
• Secret Resend: la API key NO está en git. Vive en files/smtp_password de cada Dokploy (bind ../files/smtp_password, smtp_auth_password_file). Permisos 644 (Alertmanager corre como nobody; con 600 da permission denied). STAGE y PROD tienen Dokploy independiente; STAGE usa dummy (no envía email).
• Panel por NetBird: --web.external-url=http://crearack-prod.netbird.cloud:9093. El panel se expone a la VPN con socat sobre wt0.
• Footgun socat: los proxies socat apuntan a la IP interna del contenedor, que cambia en cada recreate/deploy. scripts/netbird-proxies.sh (idempotente) los relanza re-resolviendo IPs. Ejecutar tras cada deploy.
• ⚠️ Footgun bind de FICHERO (22-08-2026): alerts.yml se monta en vmalert a nivel de fichero (Source: .../code/observability/victoriametrics/alerts.yml → /etc/alerts/alerts.yml, ro). El checkout de un deploy reemplaza el inode → el contenedor (que puede llevar semanas Up, Dokploy no lo recrea si su imagen no cambia) sigue viendo el contenido viejo, y un SIGHUP recarga… lo viejo. Tras cualquier cambio en alerts.yml: docker restart crearack-pro-zcmvsl-vmalert-1 (corte de segundos en la evaluación, sin impacto en la app) y verificar la regla en memoria vía curl http://<ip-vmalert>:8880/api/v1/rules. Descubierto al desplegar v1.81.2: la exclusión del 501 no entraba ni con SIGHUP.

Operar

• Ver/silenciar alarmas: http://crearack-prod.netbird.cloud:9093 (con NetBird conectado).
• Tras un deploy (recrea contenedores → rompe proxies): bash <app>/code/scripts/netbird-proxies.sh en el servidor.
• Tras cambiar alerts.yml: además, docker restart del contenedor vmalert + verificar la regla en memoria (ver footgun bind de fichero).
• Rotar el secret Resend: actualizar files/smtp_password (key nueva, chmod 644) + docker compose -p <proj> -f compose.prod.yml up -d --force-recreate alertmanager.
• Probar el email: POST una alerta de prueba a /api/v2/alerts del Alertmanager → confirmar que alertmanager_notifications_total{integration="email"} sube y failed_total no.

Troubleshooting

Hito A · Plan Hardening post-Máster · s95 (29-05-2026). Última actualización: 22-08-2026 (v1.81.2, exclusión del 501 + footgun bind de fichero).

Véase también

• [[entity—observability—service—vmalert]]
• [[entity—observability—service—alertmanager]]
• [[feature—observability—alerting-prod-s95]]