El equipo SRE medio recibe más de 500 alertas por semana. De ellas, menos del 5% requieren intervención humana. El resto es ruido — picos transitorios, avisos informativos y notificaciones duplicadas que enseñan a los ingenieros a ignorar las alertas por completo.
Esto no es un problema tecnológico. Prometheus, Grafana y los stacks de monitorización modernos pueden detectar cualquier cosa. El problema es que la mayoría de los equipos alertan sobre todo en lugar de alertar sobre lo que importa.
Un buen sistema de alertas en Kubernetes se basa en tres principios: alertar solo sobre síntomas que afectan a los usuarios, enrutar las notificaciones al canal adecuado con la urgencia adecuada y refinar continuamente el sistema en función de lo que realmente requirió una acción.
Así es como se implementan estos principios en toda tu infraestructura Kubernetes.
El problema de la fatiga de alertas
La fatiga de alertas es el mayor riesgo para la fiabilidad operativa. Cuando los ingenieros reciben cientos de alertas al día, desarrollan mecanismos de defensa: silenciar canales, ignorar notificaciones y dar por hecho que las alertas son falsos positivos. Cuando ocurre un incidente real, recibe el mismo trato — se ignora hasta que un cliente informa del problema.
La causa raíz suele ser uno de estos tres patrones.
Alertar sobre causas en lugar de síntomas. Una alerta de "uso de CPU por encima del 80%" se dispara constantemente pero rara vez indica un problema real. Kubernetes gestiona bien un uso alto de CPU — lo que importa es si la latencia o la tasa de errores han aumentado como consecuencia.
Sin diferenciación por severidad. Las caídas críticas y los avisos informativos llegan por el mismo canal y con la misma urgencia. Cuando todo es urgente, nada es urgente.
Falta de deduplicación. Un solo pod que falla genera alertas desde el propio pod, el controlador del deployment, el nodo y el stack de monitorización — cuatro notificaciones para un solo problema.
Cómo construir una estrategia de alertas que funcione
Paso 1: define qué merece una alerta
No toda anomalía en una métrica necesita una respuesta humana. Estructura tus alertas en tres niveles.
Nivel 1 — Avisar a la guardia (despertar a alguien): Impacto en los usuarios ahora mismo. Tasa de errores por encima del umbral del SLO. Caída total del servicio. Riesgo de pérdida de datos. Indicios de una brecha de seguridad. Van a PagerDuty u OpsGenie y avisan al ingeniero de guardia.
Nivel 2 — Notificar (siguiente día laborable): Impacto potencial si no se aborda pronto. Uso de disco por encima del 85%. Certificado que caduca en 7 días. Número de reinicios de pods en aumento. Deployment atascado en el rollout. Van a un canal de Slack o al email — urgentes, pero no inmediatas.
Nivel 3 — Registrar (para investigación): Señales informativas útiles para depurar. Picos temporales de CPU. Reinicios aislados de pods. Aumentos breves de la latencia de red. Van a dashboards y logs, no a personas.
La mayoría de los equipos empiezan con todo en el Nivel 1. La disciplina consiste en ir bajando cosas de nivel.
Paso 2: alerta sobre síntomas, no sobre causas
La regla de oro de las alertas SRE: alerta sobre lo que experimentan los usuarios, no sobre lo que crees que podría causar problemas.
En lugar de: "CPU del nodo por encima del 90%" Alerta sobre: "La latencia P99 de las peticiones supera 500ms durante 5 minutos"
En lugar de: "Uso de memoria del pod por encima del 80%" Alerta sobre: "Eventos OOMKill detectados en el namespace de producción"
En lugar de: "Uso de disco por encima del 75%" Alerta sobre: "Agotamiento previsto del disco en menos de 4 horas al ritmo de escritura actual"
Las alertas basadas en síntomas reducen el ruido un 80% porque solo se disparan cuando los usuarios se ven realmente afectados. Un nodo al 95% de CPU está bien si la latencia es normal. Un nodo al 40% de CPU con picos de latencia es un problema real.
Paso 3: implementa un enrutamiento inteligente
Cada tipo de alerta necesita un canal distinto. Una caída crítica no debería llegar al mismo canal de Slack que un recordatorio de renovación de certificado.
Configura las reglas de enrutamiento en función de la severidad y de quién es responsable de cada servicio:
Canales de Slack: Crea canales dedicados por equipo o por área de servicio. Enruta las alertas de Nivel 2 al canal del equipo responsable. Incluye suficiente contexto en el mensaje para que el ingeniero decida si actuar ahora o más tarde.
Notificaciones por email: Úsalas para alertas de Nivel 2 que no necesitan visibilidad inmediata pero que deben tener seguimiento. Los emails de resumen semanal con las tendencias del Nivel 3 ayudan a los equipos a identificar problemas que se van cociendo a fuego lento.
Webhooks: Intégralos con sistemas de tickets (Jira, Linear) para crear tickets automáticamente para las alertas de Nivel 2. Así nada se pierde por el camino, sin añadir presión de notificaciones.
PagerDuty/OpsGenie: Reservados exclusivamente para el Nivel 1. Si una alerta no merece despertar a alguien a las 3 de la madrugada, no tiene cabida en el sistema de guardias.
Plataformas como SRExpert ofrecen enrutamiento de alertas multicanal con throttling inteligente integrado. Defines reglas de alerta a partir de métricas de Prometheus y eventos de Kubernetes, estableces niveles de severidad y enrutas a Slack, Email, PagerDuty o webhooks personalizados. La plataforma se encarga de la deduplicación y del seguimiento de la entrega, así que sabes que cada alerta se entregó y se confirmó — se acabó el "no vi la alerta" en los postmortems.
Paso 4: añade throttling inteligente y deduplicación
Un solo incidente puede desencadenar decenas de alertas relacionadas. Sin deduplicación, el ingeniero de guardia recibe 50 notificaciones por un solo problema y pierde el tiempo clasificándolas en lugar de arreglarlo.
Agrupación de alertas: Agrupa las alertas por namespace, servicio o dominio de fallo. Si fallan 10 pods del mismo deployment, envía una alerta con el recuento — no 10 alertas individuales.
Limita las alertas repetidas: Si la misma alerta se dispara continuamente, envía la notificación inicial, un recordatorio a los 15 minutos si no se ha confirmado, y después suprímela hasta que la condición cambie. No envíes la misma alerta cada 60 segundos durante horas.
Correlación: Cuando se disparan varias alertas de servicios relacionados en una ventana de 2 minutos, correlaciónalas en un único incidente. Una alerta de base de datos más una alerta de API más una alerta de frontend son un incidente, no tres.
Inhibición: Si se dispara una alerta a nivel de nodo, suprime las alertas a nivel de pod de ese nodo. El problema del nodo es la causa raíz — las alertas de los pods individuales son solo síntomas.
Paso 5: monitoriza tu sistema de alertas
Tu propio sistema de alertas necesita monitorización. Los health checks de los canales garantizan que los webhooks de Slack, los relays de email y las integraciones con PagerDuty funcionan de verdad. Una alerta perfectamente configurada que no puede llegar al ingeniero de guardia es peor que no tener ninguna alerta.
Sigue estas meta-métricas de tu sistema de alertas:
Tasa de entrega de alertas: ¿Qué porcentaje de alertas se entrega correctamente en su canal configurado? Los fallos de webhooks, los rebotes de email y los rate limits de las API pueden hacer que se pierdan alertas en silencio.
Tiempo de confirmación: ¿Cuánto tiempo pasa entre la entrega de la alerta y su confirmación por una persona? Si las alertas de Nivel 1 tardan de media 30 minutos en confirmarse, tu enrutamiento o tu política de escalado necesitan ajustes.
Tasa de falsos positivos: ¿Qué porcentaje de alertas de Nivel 1 no requiere ninguna acción? Si más del 20% son falsos positivos, hay que ajustar los umbrales de tus alertas.
Ratio alertas/incidente: ¿Cuántas alertas hacen falta para identificar un incidente real? Un ratio superior a 10:1 indica un exceso de ruido.
SRExpert incluye health checks de canales y seguimiento de la entrega para cada canal de notificación configurado. Si un webhook de Slack empieza a fallar o un relay de email se cae, recibes una notificación sobre el fallo de la notificación — así tu sistema de alertas nunca se degrada en silencio.
Reglas de alerta prácticas para Kubernetes
Estas son reglas de alerta probadas en producción que equilibran la calidad de la señal con la cobertura.
Salud de las cargas de trabajo
Tasa de errores alta: Alerta cuando la tasa de errores 5xx supere el 1% del total de peticiones durante 5 minutos. Detecta la degradación real del servicio e ignora los errores transitorios.
Pod en CrashLoopBackOff: Alerta cuando un pod se haya reiniciado más de 5 veces en 15 minutos. CrashLoopBackOff es casi siempre un problema real — configuración incorrecta, dependencias que faltan o agotamiento de recursos.
Rollout de deployment atascado: Alerta cuando un deployment no haya completado su rollout en 10 minutos. Los rollouts atascados indican fallos al descargar imágenes, fallos de health check o contención de recursos.
HPA al máximo: Alerta cuando el Horizontal Pod Autoscaler lleve 30 minutos en el máximo de réplicas. Significa que el servicio no puede soportar la carga actual con los límites de escalado configurados.
Salud de la infraestructura
Nodo no listo: Alerta de inmediato cuando un nodo pase a NotReady. Afecta a todos los pods programados en ese nodo.
Volumen persistente cerca de su capacidad: Alerta cuando el uso del PV supere el 85%. A diferencia del almacenamiento efímero, los volúmenes persistentes no se pueden ampliar automáticamente en la mayoría de las configuraciones.
Latencia de etcd: Alerta cuando la duración de commit de etcd supere los 100ms. Una latencia alta de etcd afecta a todo el plano de control.
Eventos de seguridad
Contenedor privilegiado detectado: Alerta cuando un nuevo pod se ejecute con un security context privilegiado en un namespace de producción. Esto nunca debería ocurrir en un clúster bien protegido.
Creación inesperada de namespaces: Alerta cuando se cree un namespace fuera de tu pipeline GitOps. La creación manual de namespaces suele indicar un acceso no autorizado u operaciones en la sombra.
Mejora continua: el proceso de revisión de alertas
Las alertas nunca están "terminadas". Programa una revisión mensual de alertas con tu equipo SRE.
Revisa todas las alertas de Nivel 1 del último mes. Para cada una, pregúntate: ¿requirió una acción humana? Si no, pásala al Nivel 2 o ajusta el umbral. ¿Era accionable — sabía el ingeniero qué hacer? Si no, añade un enlace a un runbook. ¿Llegó a tiempo — se disparó antes de que los usuarios informaran del problema? Si no, ajusta la ventana de detección.
Revisa las alertas de Nivel 2 que se ignoraron. Si una alerta de Nivel 2 se ignora sistemáticamente durante semanas, o no es importante (elimínala) o el enrutamiento está mal (llévala a un canal más visible).
Revisa los incidentes que no tuvieron alertas. Son los huecos más peligrosos. Si ocurrió un incidente sin la alerta correspondiente, tienes un punto ciego de detección que necesita una nueva regla de alerta.
Este ciclo mensual reduce el ruido de forma continua, cierra los huecos de detección y garantiza que tu sistema de alertas evolucione con tu infraestructura.
Conclusión
Unas buenas alertas en Kubernetes no consisten en detectar más — consisten en detectar mejor. Cada alerta de tu sistema debería o bien despertar a alguien, o bien desencadenar una acción al día laborable siguiente, o bien alimentar un dashboard. Si no encaja en ninguna de estas categorías, no debería existir.
Construye tus alertas en torno a síntomas que afectan a los usuarios, no a métricas de infraestructura. Enruta las alertas al canal adecuado con la severidad adecuada. Deduplica y aplica throttling para evitar la fatiga. Monitoriza tu monitorización para garantizar su fiabilidad. Y revisa continuamente para mantener el sistema afinado.
El objetivo es un sistema de alertas en el que cada notificación sea esperada, comprendida y accionable. Cuando tu ingeniero de guardia vea una alerta, su primer pensamiento debería ser "sé lo que tengo que hacer" — no "otra vez lo mismo".
Deja de ahogarte en el ruido de las alertas. SRExpert ofrece enrutamiento inteligente de alertas con deduplicación inteligente, entrega multicanal (Slack, Email, PagerDuty, Webhooks) y monitorización de la salud de los canales. Empieza a explorar ahora o habla con nuestro equipo SRE para optimizar tu estrategia de alertas.