ADR-0005 · Criterios de alertado

• Estado: aceptado
• Decisores: Hugo Quintero
• Fecha de la decisión: 2026-09-04

Contexto y problema

Al reactivar y ampliar las alertas (probes, Postgres, contenedores, Redis, stack) se tomaron decisiones que condicionan reglas futuras. Registrarlas en un solo lugar para no re-discutirlas.

Decisiones

1. Severidad por target, no por regla, en probes. Cada target de los jobs blackbox_* lleva servicio y severity en prometheus.yml; las reglas de blackbox_alertas no fijan severity. Agregar un endpoint es agregar un target con sus labels.
2. Umbrales a partir de historia, no de valores por defecto. Antes de fijar un umbral, consultar 7 días de datos (max_over_time, quantile_over_time). Ejemplos: ProbeCaido con for: 3m por los reinicios de 1-2 min de medusa_backend; latencia a 5 s con www en p95 de 2,6 s.
3. Un test por alerta. Toda regla nueva lleva un caso en tests/alertas_test.yml (promtool test rules). Es la forma de "probar la alerta" sin intervenir producción; la prueba en vivo es opcional.
4. Sin alerta de vencimiento de certificados. Los sitios están detrás del edge de Cloudflare, que renueva los certificados.
5. Sin Watchdog por ahora. No hay receptor de latidos fuera de devops-vm; un latido por correo sería ruido. Riesgo aceptado: la caída simultánea de Prometheus y Alertmanager, de la VM o del SMTP no avisa. Revisar cuando exista un receptor externo.
6. Sin alerta por clientes bloqueados en Redis. Los workers de Sidekiq (Chatwoot) y BullMQ (Medusa) esperan trabajo con BRPOP/BZPOPMIN y figuran bloqueados de forma permanente. Medir colas trabadas del lado de la aplicación.
7. Contenedores críticos con absent(). cAdvisor deja de exportar un contenedor detenido, por eso ContenedorCriticoAusente usa absent() por nombre en vez de un valor. Mantener la lista en rules/contenedores_alertas.yml.
8. wp-server-1 sin inversión. VM en retiro: MySQLDown permanente documentado y no corregido; targets con severity: warning. Retirar sus targets al apagarla.

Consecuencias

• Reglas más simples y homogéneas; el ruido se controla desde los labels de los targets y desde los for.
• Dos riesgos aceptados y visibles (5 y 8) en lugar de alertas silenciosas.
• Obligación de mantener tests/alertas_test.yml en cada cambio de reglas.