Higiene de alertas en la monitorización de hosts: tasa en lugar de umbral, unidades fallidas y ventanas de duración

Qué es

El libro de SRE de Google afirma que "paging a human is a quite expensive use of an employee's time" (avisar a una persona es un uso bastante costoso de su tiempo) y que una buena estrategia de alertas necesita "good signal and very low noise" (buena señal y muy poco ruido): cada aviso que al final no requiere ninguna acción enseña al ingeniero de guardia a confiar menos en los avisos. El capítulo del SRE workbook sobre alertas basadas en SLO describe las alertas multiventana, que solo se disparan cuando la tasa de consumo es alta tanto en una ventana larga (para que un pico breve no genere un aviso) como en una corta (para que la alerta se resuelva poco después de la recuperación).

Si se aplican a un único host en lugar de al SLO de un servicio, estas dos ideas permiten decidir cuáles de las señales tratadas en otros artículos de esta serie deben ir al sistema de guardia y cuáles a una cola de tickets:

• Espacio en disco: un porcentaje fijo (por ejemplo, "avisar al 90 % de ocupación") genera el mismo aviso tanto si la partición lleva seis meses estable en el 91 % como si ha pasado del 60 % al 91 % en la última hora. La tasa de llenado, es decir, el tiempo estimado hasta llenarse al ritmo de crecimiento actual, es la señal que realmente anticipa una caída inminente: un 91 % lento y estable merece un ticket; una partición que va a llenarse en menos de una hora merece un aviso.
• Unidades de systemd fallidas / servicios de Windows detenidos: una unidad que ha fallado en este momento y que debería estar en ejecución se acerca al caso de "ya está roto" que el libro de SRE considera digno de un aviso; una unidad que falló una vez y que su propia lógica de reintentos ya reinició merece un ticket, no un aviso.
• Sincronización del reloj: un host cuyo reloj se ha desviado lo suficiente como para romper la validación TLS o la correlación de logs justifica un aviso; un tiempo de espera agotado puntual en una consulta NTP que se resuelve en el siguiente sondeo, no.
• Estado SMART/NVMe: una autoprueba fallida o un byte de advertencia crítica distinto de cero justifica un aviso, dado el poco margen que queda antes de perder datos; un único sector reasignado en una unidad por lo demás sana es un ticket para hacer seguimiento.

Por qué importa

Alertar sobre el valor bruto instantáneo de una métrica, sin exigir duración ni tendencia, es lo que produce las oscilaciones y el ruido contra los que advierte el libro de SRE: un valor que ronda el umbral dispara y resuelve la alerta una y otra vez, y la fatiga de alertas resultante es el mismo modo de fallo, ya se trate de un porcentaje de disco o de una tasa de errores HTTP.

Cómo aplicarlo

• Para cada alerta de host, comprueba si la regla reacciona a una tasa o tendencia o a un nivel bruto, y si exige que la condición se mantenga durante una ventana en lugar de bastar con una única muestra.
• Envía como aviso las condiciones de "ya está roto y hay que actuar ahora" (un disco que se llenará dentro del turno de guardia, una unidad necesaria caída, un reloj sin sincronizar); envía a un ticket o a un dashboard las condiciones que "conviene revisar pronto" (lentas, estables o ya recuperadas).
• Reevalúa cualquier alerta que genere avisos más de unas pocas veces sin que haya una corrección real asociada: el caso de estudio de Bigtable del libro de SRE describe cómo se desactivaron alertas por correo que se habían vuelto demasiado numerosas para poder diagnosticarlas.

Trampas

• Copiar un umbral de disco basado en porcentaje de un host a otro con una tasa de crecimiento muy distinta, donde la misma cifra representa un margen de tiempo diferente.
• Tratar un aviso y un ticket como la misma gravedad con distintos canales de entrega, en lugar de como clases distintas de urgencia.